消息生态系统全景图

在这里插入图片描述

为什么需要消息队列？

异步处理

大多数程序员在面试中，应该都问过或被问过一个经典却没有标准答案的问题：如何设计一个秒杀系统？
- 这个问题可以有一百个版本的合理答案，但大多数答案中都离不开消息队列。
- 秒杀系统需要解决的核心问题是，如何利用有限的服务器资源，尽可能多地处理短时间内的海量请求。
处理一个秒杀请求包含了很多步骤，例如：
- 风险控制；
- 库存锁定；
- 生成订单；
- 短信通知；
- 更新统计数据。
如果没有任何优化，正常的处理流程是：App 将请求发送给网关，依次调用上述 5 个流程，然后将结果返回给 APP。
对于这 5 个步骤来说，能否决定秒杀成功，实际上只有风险控制和库存锁定这 2 个步骤。
- 只要用户的秒杀请求通过风险控制，并在服务端完成库存锁定，就可以给用户返回秒杀结果了，对于后续的生成订单、短信通知和更新统计数据等步骤，并不一定要在秒杀请求中处理完成。
- 所以当服务端完成前面 2 个步骤，确定本次请求的秒杀结果后，就可以马上给用户返回响应，然后把请求的数据放入消息队列中，由消息队列异步地进行后续的操作。
- 处理⼀个秒杀请求，从 5 个步骤减少为 2 个步骤，这样不仅响应速度更快，并且在秒杀期间，我们可以把大量的服务器资源用来处理秒杀请求。
- 秒杀结束后再把资源用于处理后面的步骤，充分利用有限的服务器资源处理更多的秒杀请求。
可以看到，在这个场景中，消息队列被用于实现服务的异步处理。

流量控制

我们已经使用消息队列实现了部分秒杀系统工作的异步处理，但我们还面临一个问题：如何避免过多的请求压垮我们的秒杀系统？
- 我们的设计思路是，使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。
- 加入消息队列后，整个秒杀流程变为：
  - 网关在收到请求后，将请求放入请求消息队列；
  - 后端服务从请求消息队列中获取 APP 请求，完成后续秒杀处理过程，然后返回结果。
- 秒杀开始后，当短时间内大量的秒杀请求到达网关时，不会直接冲击到后端的秒杀服务，而是先堆积在消息队列中，后端服务按照自己的最大处理能力，从消息队列中消费请求进行处理。
  - 对于超时的请求可以直接丢弃，APP 将超时无响应的请求处理为秒杀失败即可。
  - 运维人员还可以随时增加秒杀服务的实例数量进行水平扩容，而不用对系统的其他部分做任何更改。
- 这种设计的优点是：能根据下游的处理能力自动调节流量，达到“削峰填谷”的作用。
- 但这样做同样是有代价的：
  - 增加了系统调用链环节，导致总体的响应时延变长。
  - 上下游系统都要将同步调用改为异步消息，增加了系统的复杂度。
如果我们能预估出秒杀服务的处理能力，就可以用消息队列实现⼀个令牌桶，更简单地进行流量控制。
- 网关在收到请求后，将请求放入请求消息队列；
- 后端服务从请求消息队列中获取 APP 请求，完成后续秒杀处理过程，然后返回结果。
- 令牌桶控制流量的原理是：单位时间内只发放固定数量的令牌到令牌桶中，规定服务在处理请求之前必须先从令牌桶中拿出一个令牌，如果令牌桶中没有令牌，则拒绝请求。这样就保证单位时间内，能处理的请求不超过发放令牌的数量，起到了流量控制的作用。

服务解耦

消息队列的另外⼀个作用，就是实现系统应用之间的解耦。
所有的电商都选择用消息队列来解决系统耦合过于紧密的问题。
- 引入消息队列后，订单服务在订单变化时发送一条消息到消息队列的一个主题 Order 中，所有下游系统都订阅主题 Order，这样每个下游系统都可以获得一份实时完整的订单数据。
- 无论增加、减少下游系统或是下游系统需求如何变化，订单服务都无需做任何更改，实现了订单服务与下游服务的解耦。

该如何选择消息队列？

选择消息队列产品的基本标准

首先，必须是开源的产品，这个非常重要。
- 开源意味着，如果有⼀天你使用的消息队列遇到了一个影响你系统业务的 Bug，你至少还有机会通过修改源代码来迅速修复或规避这个 Bug，解决你的系统火烧眉毛的问题，而不是束手无策地等待开发者不一定什么时候发布的下一个版本来解决。
其次，这个产品必须是近年来比较流行并且有一定社区活跃度的产品。
- 流行的好处是，只要你的使用场景不太冷门，你遇到 Bug 的概率会非常低，因为大部分你可能遇到的 Bug，其他人早就遇到并且修复了。
- 还有一个优势就是，流行的产品与周边生态系统会有一个比较好的集成和兼容。
最后，作为一款及格的消息队列产品，必须具备的几个特性包括：
- 消息的可靠传递：确保不丢消息；
- Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；
- 性能：具备足够好的性能，能满足绝大多数场景的性能要求。

可供选择的消息队列产品

RabbitMQ
- RabbitMQ 是使用一种比较小众的编程语言：Erlang 语言编写的，它最早是为电信行业系统之间的可靠通信设计的，也是少数几个支持 AMQP 协议的消息队列之一。
- RabbitMQ 是⼀个相当轻量级的消息队列，非常容易部署和使用
- RabbitMQ 一个比较有特色的功能是支持非常灵活的路由配置，和其他消息队列不同的是，它在生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块，你可以理解为交换机。
- RabbitMQ 的几个问题。
  - RabbitMQ 对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。
  - RabbitMQ 的性能比较差，它大概每秒钟可以处理几万到十几万条消息。
  - RabbitMQ 使用的编程语言 Erlang，这个编程语言不仅是非常小众的语言，更麻烦的是，这个语言的学习曲线非常陡峭。
RocketMQ
- RocketMQ 有着不错的性能，稳定性和可靠性，具备⼀个现代的消息队列应该有的几乎全部功能和特性，并且它还在持续的成长中。
- RocketMQ 有非常活跃的中文社区，大多数问题你都可以找到中文的答案，也许会成为你选择它的⼀个原因。
- 另外，RocketMQ 使用 Java 语言开发，它的贡献者大多数都是中国人，源代码相对也比较容易读懂，你很容易对 RocketMQ 进行扩展或者二次开发。
- RocketMQ 对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，如果你的应用场景很在意响应时延，那应该选择使用 RocketMQ。
- RocketMQ 的性能比 RabbitMQ 要高⼀个数量级，每秒钟大概能处理几十万条消息。
- RocketMQ 的一个劣势是，作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊⼀筹。
Kafka
- Kafka 与周边生态系统的兼容性是最好的没有之⼀，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。
- Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。
- Kafka 的性能，尤其是异步收发的性能，是三者中最好的，但与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。
- Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，在它的 Broker 中，很多地方都会使用这种“先攒一波再一起处理”的设计。
- 当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。

消息队列的选择

如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。
如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。
如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。