消息队列 - 介绍
# 1. 什么是消息队列(MQ)
MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游「逻辑解耦 + 物理解耦」的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。
# 2. 为什么要用MQ
# 2.1 流量消峰
在实际应用中，系统的处理能力是有限的。以订单系统为例，假设系统在正常情况下最多能处理一万次订单/秒。这种处理能力在大多数时段足够应对用户的下单需求，用户几乎可以实时收到下单成功的反馈。然而，在促销或者高峰期，下单请求可能会远远超出这一处理能力，如遇到两万次订单/秒的情况，系统将不得不限制订单的接受，可能导致用户体验严重下降。
通过引入消息队列作为缓冲，系统可以把高峰期接收到的订单先暂存于队列中，然后按照系统的处理能力逐渐消化这些订单。 这意味着在高峰期，虽然用户下单后可能需要更长时间才能收到下单成功的反馈，但至少保证了订单能够被接收，从而避免了“拒绝服务”的情况，优化了用户体验。
# 2.2 应用解耦
在复杂的应用架构中，如电商平台，通常包含订单系统、库存系统、物流系统、支付系统等多个子系统。这些系统间的直接耦合调用不仅增加了系统间的依赖关系，而且任何一个系统的故障都可能影响到整个下单流程。
引入消息队列后，系统间的通信变为基于消息的异步处理。 当用户下单时，订单信息首先被发送到消息队列中，然后库存系统、物流系统、支付系统等可以从队列中按需取出订单信息进行处理。这种方式大大降低了系统间的直接依赖，即使某个子系统暂时出现故障，也不会立即影响到用户的下单操作。待故障恢复后，子系统可以继续处理积压在队列中的订单信息，从而提高了整个系统的可用性和鲁棒性。
# 2.3 异步处理
在分布式系统中，服务间的调用往往涉及复杂的业务逻辑，其中一些操作可能需要较长时间来完成。这种场景下，异步处理变得尤为重要。考虑到服务A调用服务B，其中服务B的处理时间较长，服务A又需要知道服务B何时完成处理，传统的解决方案包括：
- 轮询：服务A在调用服务B之后，隔一段时间主动调用B的查询API来查询处理结果。这种方式需要A不断发起查询请求，可能会导致资源浪费和响应延迟。
- 回调：服务A在调用服务B时提供一个回调API，服务B处理完成后调用这个API通知服务A。这种方式要求服务B知道如何回调，并且增加了系统的耦合度。
这两种方式都有其局限性，不够优雅且可能引入额外的复杂度。引入消息队列（MQ）后，可以更加优雅地解决上述问题，具体做法如下：
- 服务A调用服务B：在完成调用后，服务A不需要立即得到处理结果，而是向消息队列订阅一个特定的主题或队列，等待服务B的处理完成消息。
- 服务B处理完成：服务B在完成处理后，向消息队列发送一条包含处理结果的消息，并指定这条消息的目标是服务A订阅的主题或队列。
- 消息队列转发消息：消息队列收到服务B的消息后，自动将消息转发给订阅了相应主题或队列的服务A。
- 服务A接收处理结果：服务A通过监听消息队列中的消息，能够及时地得知服务B的处理结果，无需轮询查询或提供回调接口。
这种基于消息队列的异步处理模式有以下优势：
- 解耦服务间的直接依赖：服务A和服务B不需要直接通信，减少了耦合度，提高了系统的可维护性和扩展性。
- 提高响应效率：服务A不需要不断查询或等待回调，可以立即继续处理其他任务，提高了服务的响应效率和资源利用率。
- 简化开发和维护：避免了编写和维护查询API和回调接口的需要，简化了系统的开发和后期维护工作。
# 3. MQ的分类
# 3.1 ActiveMQ
优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较 低的概率丢失数据。
缺点：官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。
# 3.2 Kafka
大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn，Uber，Twitter，Netflix 等大公司所采纳。
优点: 性能卓越，单机写入 TPS 约在百万条/秒，最大的优点，就是吞吐量高。时效性 ms 级可用性非常高，kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用,消费者采用 Pull 方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次；有优秀的第三方Kafka Web 管理界面 Kafka-Manager；在日志领域比较成熟，被多家公司和多个开源项目使用；功能支持：功能 较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用。
缺点：Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息响应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢。
# 3.3 RocketMQ
RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。
优点：单机吞吐量十万级，可用性非常高，分布式架构，消息可以做到 0 丢失，MQ 功能较为完善，还是分布式的，扩展性好,支持 10 亿级别的消息堆积，不会因为堆积导致性能下降，源码是 java 我们可以自己阅读源码，定制自己公司的 MQ
缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++ 不成熟；社区活跃度一般,没有在 MQ 核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码。
# 3.4 RabbitMQ
2007 年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，当前最主流的消息中间件之一
优点：由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX 文档齐全；开源提供的管理界面非常棒，用起来很好用，社区活跃度高；更新频率相当高。
缺点：商业版需要收费，学习成本较高。
# 4. MQ的选择
1. Kafka
Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka 了。
2. RocketMQ
天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。
3. RabbitMQ
结合 erlang 语言本身的并发优势，性能好时效性微秒级，社区活跃度也比较高，管理界面用起来十分 方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的 RabbitMQ。