本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！
- 🚀 魔都架构师 | 全网30W技术追随者
- 🔧 大厂分布式系统/数据中台实战专家
- 🏆 主导交易系统百万级流量调优 & 车联网平台架构
- 🧠 AIGC应用开发先行者 | 区块链落地实践者
- 🌍 以技术驱动创新，我们的征途是改变世界！
- 👉 实战干货：编程严选网
见名知义，消息队列主要就是用来发送和接收处理消息，但它的作用可不仅解决应用间通信问题。
1 MQ 的由来
在工厂我们随处可见各种传送带，很多道工序都替代了人工一次次极大耗费劳动力的往返运动，而把一套业务分成若干部分，各流程之间传输所需材料即可。用编程思想，我们可以认为是传送带的发明解决了上下游工序间的“通信”问题。
传送带的使用着实提高社会必要劳动生产时间，让人类工业社会效率显著提升。但就真的百利无一害了吗？ 我们会发现每道工序生产速度并不相同。有时上游的材料刚传送过来，工人可能正在处理上批材料，没有时间接收。不同工序的工人必须协调好什么时间往传送带上放置材料，若出现上下游工序速度不一致，上下游工人之间就得互相等待，确保不会出现传送带上的半成品材料挤压太多，无人接收！
为解决该问题，在每组工序下游配备个暂存仓库，这样上游工人就不用等下游工人有空，任何时间都可把加工完成的半成品丢到传送带，无法接收的就被暂存在仓库，下游工人可随时来取。 配备的仓库就起到了“通信”过程中“缓存”作用。
这就是现实版MQ。
2 消息队列适用场景
2.1 异步
跨系统的异步通信或应用内的同步变成异步。如秒杀系统，一个秒杀请求可能包含很多步骤：
- 风控
- 锁库存
- 生成订单
- 通知
- 更新统计数据
最低级的同步处理流程：App将请求发送给网关，依次调用上述流程，然后将结果返给APP。
决定秒杀成功与否的实际上只有风控和锁库存。只要用户请求通过风控，并在Server完成库存锁定，就可给用户返回秒杀结果，对于后续生成订单、短信通知和更新统计数据等，并不一定要在秒杀请求中处理完。
所以当服务端完成前2步，确定本次请求秒杀结果，即可给用户响应，然后把请求的数据放入MQ，由MQ异步执行后续操作。
五步变两，不仅响应更快，且在秒杀间，可把大量服务器资源用来处理秒杀请求。秒杀结束后再把资源用于处理后面步骤，榨干服务器资源。
优点
- 更快地返回结果
- 减少等待，自然实现了步骤之间的并发，提升系统总体的性能，集中力量办大事(同步部分)，碎片时间做小事(异步部分)
缺点
- 降低数据一致性，如要保持强一致性，需高代价补偿（如分布式事务、对账）
- 有数据丢失风险，如宕机重启，如要保证队列数据可用，需要额外机制保证(如双活容灾)
2.2 流控
2.2.1 咋避免过多请求压垮秒杀系统？
好程序有自我保护能力，即应该可在海量请求下，还能在自身能力范围尽可能多处理请求，拒绝处理不了的请求且保证自身运行正常，就像线程池一般顺畅。而不是像你我简单粗暴地直接拒绝请求并返回错误，这可不是啥好的用户体验。
思路就是使用MQ隔离网关和后端服务，达成流控和保护后端服务。
加入MQ，整个秒杀流程变为：
- 网关收到请求后，将请求放入请求MQ
- 后端服务从请求MQ获取APP请求，完成后续秒杀处理过程，然后返回结果
秒杀开始后，当短时内大量秒杀请求到达网关，不会直接冲击后端秒杀服务，而是先堆积在MQ，后端服务尽力从MQ消费请求并处理。
★若消息量特大，消息适合存redis or rabbitmq？毕竟只是个小仓库，货量大了咋办？
redis肯定不适合存消息，虽性能好，但那是和主流数据库比，大概几万tps；而现代消息队列都能很轻松做到几十万TPS性能。 消息量特大时，需考虑使用有消息堆积能力的MQ，因为一旦消费慢，大量消息就会堆积到MQ，这时不太适合用RabbitMQ，可考虑RocketMQ、Kafka和Pulsar。
”
对于超时请求可直接丢弃，APP将超时无响应请求处理为秒杀失败。运维人员还可随时增加秒杀服务的实例数量来水平扩容，无需对系统其他部分更改。
2.2.2 优点
能根据下游的处理能力自动调节流量，削峰填谷。
2.2.3 缺点
- 增加系统调用链环节，导致总体响应延时加长
- 上下游系统都要将同步调用改为异步消息，增加系统复杂度
有无简单点流控方式？若能预估秒杀服务的能力，就可用MQ实现个令牌桶，更简单流控。
2.2.4 令牌桶流控原理
单位时间内，只发放固定数量令牌到桶里，规定服务在处理请求前，须先从令牌桶中取个令牌。若令牌桶中无令牌，则拒绝请求。
这保证单位时间内，能处理请求不超过发放令牌数量，达成流控。
实现
也简单，无需破坏原调用链，只要网关在处理APP请求时加个获取令牌流程。
令牌桶可简单地用一个有固定容量的消息队列加一个“令牌发生器”来实现：令牌发生器按照预估的处理能力，匀速生产令牌并放入令牌队列（如果队列满了则丢弃令牌），网关在收到请求时去令牌队列消费一个令牌，获取到令牌则继续调用后端秒杀服务，如果获取不到令牌则直接返回秒杀失败。
★令牌桶可用MQ或Redis实现，也可写一个简单的令牌桶服务，原理一样。
”
以上常用的使用消息队列两种进行流量控制的设计方法，可根据各自的优缺点和不同的适用场景进行合理选择。
2.3 服务解耦
比如新订单创建时：
- 支付系统需要发起支付流程
- 风控系统需要审核订单的合法性
- 客服系统需要给用户发短信告知用户
- 经营分析系统需要更新统计数据； …
这些订单下游系统都需实时获得订单数据。随业务发展，订单下游不断变化，每个系统可能只需订单数据子集，订单服务团队不得不花精力，应对不断增变下游，不停修改订单系统与下游系统之间接口。任一下游系统接口变更，都需订单模块重上线，对核心的订单服务，这是不可接受的。
所有的电商都选择用MQ解决类似的系统高耦合问题。 订单服务在订单变化时发送一条消息到MQ的一个主题Order，所有下游系统都订阅该主题，这样每个下游系统都可获得一份实时完整订单数据。
无论增加、减少下游系统或是下游系统需求如何变化，订单服务无需更改，实现了订单服务与下游服务解耦。
优点
- 可在模块、服务、接口等不同粒度上实现解耦
- 订阅/消费模式也可在数据粒度上解耦
3 基于发布/订阅模型实现的事件驱动
- 原使用 ETL、HTTP 调用 API方式
- 现使用 MQ 定时任务去拉取数据
再如实现一个微服务系统间的观察者模式。
4 实现事务的最终一致性
比如使用 rabbitmq 和 rocketmq。
其他适用场景还有比如连接流计算任务和数据、将消息广播给大量接收者。
在单体应用里需要用队列解决的，在分布式系统中大都可用MQ解决。 MQ适用场景还是很多的，如秒杀、发邮件、发短信、高并发订单等。 注意
5 不适合 MQ 的场景
如银行转账、电信开户、第三方支付等。 关键还是要意识到消息队列的优劣点，然后分析场景是否适用。
FAQ
Q：是否可用共享内存、RDMA提高MQ性能？
A：若共享内存指PageCache，很多MQ会用，RDMA常见MQ都还没用。像Kafka消费时，直接用Zero Copy，数据直接从PageCache写到NIC的缓冲区，无需进入应用内存空间。
现代MQ瓶颈不在本机内存数据交换，主要还是受限于网卡带宽或磁盘IO。Kafka这些MQ，都能打满万兆网卡或磁盘读写速度。
Q：APP⇆网关--生产-->消息队列--消费-->秒杀服务问题。海量请求都放在MQ，其整体容量咋衡量？MQ不可能能存放无限消息，MQ满了应该也会有拒绝策略，类似线程池？
A：实际上，只要有足够磁盘容量，MQ确实可存放无限消息。像秒杀请求这种数据，峰值并发高，但总数据量不大，所以，堆积在MQ没问题。
Q：APP响应超时，即网关超时未返回。但消息还在任务队列，最终还会被秒杀服务处理，这样的话，返回给APP秒杀失败，但秒杀服务其实已消费消息？后续难道在网关做补偿？若连接已断开，将秒杀服务对此消息的处理做回滚操作？
A：都按秒杀失败处理。
Q：网关和秒杀服务通过MQ通信，那响应消息也通过队列返回？队列中有APP对应的地址如IP？这样的话，APP的海量连接都同时连接网关，会有问题？
A：响应一般用RPC实现。超时或返回秒杀结果前，网关和APP确实要保持连接，HTTP协议决定的。
网关能不能承受海量APP连接？网关作用就是用来抗海量连接！
