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