认识 MQ

1. 为什么要用MQ

1.1 流量削峰

有一个订单系统，最多能处理一万次订单，这个处理能力应付正常时段的下单是没问题的，正常时段我们下单一秒后就能返回结果

但是在高峰期，如果有两万次下单操作，系统是处理不了的。那么以前的解决方法只能限制订单超过一万后，不允许用户下单

如果我们使用消息队列做为缓冲，那么就可以取消这个限制。把一秒内发送过来的订单分散成一段段的时间来处理。这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好

1.2 应用解耦

现在的电商应用中，存在很多的系统，比如：有订单系统、库存系统、物流系统、支付系统。用户创建订单后，则会相应的去调用库存系统、物流系统、支付系统等其他相关的系统。那么如果任何一个子系统出了故障，都会造成下单操作异常，这就是应用的耦合问题

但是如果使用基于消息队列的方式，系统间调用的问题会减少很多。比如物流系统因为发生故障，需要时间来修复。那么在这段修复的时间里，物流系统要处理的数据就会被缓存在消息队列中，用户的下单操作也可以正常完成。当物流系统恢复后，继续处理订单信息即可，其中用户并不会感受不到物流系统发生了故障，提升系统的可用性和用户操作的体验性

1.3 异步处理

有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完

以前处理这种情况有两种办法：A 过一段时间去调用 B 的查询 api 查询；或者 A 提供一个 回调(callback) api，B 执行完之后调用 api 通知 A 服务
这两种方式其实都不好，首先是第一种方式，A 服务要循环多次的去调用 B 服务的查询 api ，一次就能得到回复还好，但是要是 B 服务要处理很久，那么 A 服务一边完成自己的工作，还要一边去看看 B 服务是否处理完成。第二种方式的话，A 服务要专门提供一个回调 api，然后 B 服务还要去调用。总体来说的话，两种方式都会极大的浪费资源和时间

使用消息总线，就可以很方便解决这个问题， A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供 回调(callback) api。同样 B 服务也不用做回调操作，A 服务还能及时的得到异步处理成功的消息

2. MQ 的分类

2.1 ActiveMQ

是 Apache 软件基金会的一个开源项目，是一个基于消息的通信中间件

优点：

• 单机吞吐量万级
• 时效性 ms 级
• 可用性高
• 基于主从架构实现高可用性
• 消息可靠性，较低的概率丢失数据

缺点：进入 5.X 版本后，官方社区对其维护变少，其相关的社区也并不活跃，所以在高吞吐量场景下，比较少使用它

2.2 Kafka

由 Apache 开发的一个开源流处理平台，由 Scala 和 Java 编写，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据
适合产生大量数据的互联网服务的数据收集业务

优点：

• 吞吐量高，单机写入 TPS(每秒处理的消息数) 约在百万条/秒
• 时效性 ms 级
• 可用性高
• 成熟的日志体系（“Kafka为大数据而生”，这句话就是因为它的这一特性）

缺点：

• 实时性取决于轮询间隔时间
• 消费失败不支持重试
• 支持消息顺序， 但是一台代理宕机后，就会产生消息乱序
• 可能消息重复消费，那么对数据准确性会造成轻微的影响。但是在它那强大的日志体系下，这点影响可以忽略

详解：https://blog.youkuaiyun.com/wanzijy/article/details/127717026

2.3 RocketMQ

阿里巴巴的开源产品，用 Java 语言实现
适合可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。该中间件在阿里双 11 已经经历了多次考验

优点：

• 单机吞吐量十万级
• 可用性高
• 消息可以做到 0 丢失（“RocketMQ为金融互联网而生”，这句话就是因为它的这一特性）
• 支持 10 亿级别的消息堆积，且不会因为堆积导致性能下降

缺点：支持的客户端语言不多，目前是 Java 和 C++

2.4 RabbitMQ

由 Rabbit 科技有限公司开发，是一个在 AMQP(高级消息队列协议) 基础上完成的，可复用的企业消息系统
适合数据量没有那么大，中小型公司优先选择

优点：

• 吞吐量万级
• 时效性微秒级
• 性能好，延时很低
• 社区活跃度高
• 支持多种语言

缺点：实现机制比较重。使用 Erlang 语言进行开发，较难定制和读懂源码

这篇文章仅对4种常见的 MQ 进行简单的介绍，后续会更新每一种 MQ 的详细介绍