MQ消息队列（一）什么是消息队列

一、消息队列概述

1.什么是消息队列

        MQ全称为Message Queue，即消息队列. 它也是一个队列,遵循FIFO原则 。同时也是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ，Redis等

2.为什么要使用消息队列

        比如当我们需要调用三方接口时，我们没有办法预判三方接口的响应时效，假设三方服务挂掉了，可能导致我们的服务响应超时。

        举个栗子，不知道各位坐地铁有没有注意到过，在刷天府通用三方支付的时候，只要你刷了闸机就会打开，可能要过一会才会弹出支付消息。就是说你在扫过码之后，付款并没有完成就可以出站。

如图

        提高系统响应速度

    任务异步处理。 将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。 提高了应用程序的响应时间。

        提高系统稳定性

   系统挂了关系，操作内容放到消息队列。

        服务调用异步化

服务没有直接的调用关系，而是通过队列进行服务通信

        服务解耦

    应用程序解耦合，MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

        排序保证 FIFO

遵循队列先进先出的特点

        消除峰值

异步化提速(发消息)，提高系统稳定性(多系统调用)，服务解耦(5-10个服务)，排序保证，消除峰值

二、常见的消息队列及如何选择

1.常见的消息队列

        现在比较常见的消息队列产品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等，这些技术背景或者特点各位感兴趣自行百度。

 2.如何选择

        关于如何选择方案，还是要看具体的需求。在我们的设计中，MQ的功能与业务无关，因此优先考虑使用已有的中间件搭建。那么具本选择哪个中间件呢？先来梳理下我们对MQ的需求：

1.功能需求

        如前文所述，除了最基本生产消费模型，还需要MQ能支持REQUEST-REPLY模型，以提供对同步调用的支持。 此外，如果MQ能提供PUBLISH-SUBSCRIBE模型，则事件代理的实现可以更加简单。

2.性能需求

        考虑未来一到两年内产品的发展，消息队列的呑吐量预计不会超过 1W qps，但由单条消息延迟要求较高，希望尽量的短。

3.可用性需求

        因为是在线服务，因此需要较高的可用性，但充许有少量消息丢失。

4.易用性需求

        包括学习成本、初期的开发部署成本、日常的运维成本等。

3.横向对比

        ActiveMQ与RabbitMQ在很多方面都很相似，但ActiveMQ对非JAVA生态的支持不及rabbitMQ, 这期主题会专门用RabbitMQ来举例。

特性	ActiveMQ	RabbitMQ	Kafka	RocketMQ
PRODUCER-COMSUMER	支持	支持	支持	支持
PUBLISH-SUBSCRIBE	支持	支持	支持	支持
REQUEST-REPLY	支持	支持	-	支持
API完备性	高	高	高	低（静态配置）
多语言支持	支持，JAVA优先	语言无关	支持，JAVA优先	支持
单机呑吐量	万级	万级	十万级	单机万级
消息延迟	-	微秒级	毫秒级	-
可用性	高（主从）	高（主从）	非常高（分布式）	高
消息丢失	-	低	理论上不会丢失	-
消息重复	-	可控制	理论上会有重复	-
文档的完备性	高	高	高	中
提供快速入门	有	有	有	无
首次部署难度	-	低	中	高

 注： - 表示尚未查找到准确数据

摘自常用消息队列介绍和对比 - 腾讯云开发者社区-腾讯云

 4.技术选型建议

• 大数据场景，日志收集，实时性要求高，推荐Kafka
• 金融领域，不能接受消息丢失或重复，推荐使用RocketMQ
• 其他情况可以选择RabbitMQ

         本期先到这里，下面几期会介绍如何搭建RabbitMQ以及如何在我们的项目中使用。