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 消息队列应该也会做多备的策略？比如队列消息的服务挂了，那些消息全部不见，这样不是也会存在问题么？
是的，大部分生产系统中的消息队列要配置成集群，确保可用性和数据可靠性，这个后面的课程我们会讲。
- 参考
《消息队列高手课》
