MQ削峰限流

MQ的作用

1）解耦：在项目启动之初是很难预测未来会遇到什么困难的，消息中间件在处理过程中插入了一个隐含的，基于数据的接口层，两边都实现这个接口，这样就允许独立的修改或者扩展两边的处理过程，只要两边遵守相同的接口约束即可。
2）冗余（存储）：在某些情况下处理数据的过程中会失败，消息中间件允许把数据持久化知道他们完全被处理
扩展性：消息中间件解耦了应用的过程，所以提供消息入队和处理的效率是很容易的，只需要增加处理流程就可以了。
3）削峰：在访问量剧增的情况下，但是应用仍然需要发挥作用，但是这样的突发流量并不常见。而使用消息中间件采用队列的形式可以减少突发访问压力，不会因为突发的超时负荷要求而崩溃
4）可恢复性：当系统一部分组件失效时，不会影响到整个系统。消息中间件降低了进程间的耦合性，当一个处理消息的进程挂掉后，加入消息中间件的消息仍然可以在系统恢复后重新处理
5）顺序保证：在大多数场景下，处理数据的顺序也很重要，大部分消息中间件支持一定的顺序性
6）缓冲：消息中间件通过一个缓冲层来帮助任务最高效率的执行
7）异步通信：通过把把消息发送给消息中间件，消息中间件并不立即处。

本文只讨论削峰填谷的应用场景：

举个业务场景的栗子，秒杀业务：
上游发起下单操作
下游完成秒杀业务逻辑（库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻）
上游下单业务简单，每秒发起了10000个请求，下游秒杀业务复杂，每秒只能处理2000个请求，很有可能上游不限速的下单，导致下游系统被压垮，引发雪崩。
为了避免雪崩，常见的优化方案有两种：
1）业务上游队列缓冲，限速发送
2）业务下游队列缓冲，限速执行


不管哪种方案，都会引入业务的复杂性，有“缓冲流量”需求的系统都需要加入类似的机制（具体怎么保证消息可达，见《消息总线能否实现消息必达？》），正所谓“通用痛点统一解决”，需要一个通用的机制解决这个问题。

问：如何缓冲流量？
答：明明中间有了MQ，并且MQ有消息落地的机制，为何不能利用MQ来做缓冲呢？显然是可以的。
 

问：MQ怎么改能缓冲流量？
答：由MQ-server推模式，升级为MQ-client拉模式。
MQ-client根据自己的处理能力，每隔一定时间，或者每次拉取若干条消息，实施流控，达到保护自身的效果。并且这是MQ提供的通用功能，无需上下游修改代码。

问：如果上游发送流量过大，MQ提供拉模式确实可以起到下游自我保护的作用，会不会导致消息在MQ中堆积？
答：下游MQ-client拉取消息，消息接收方能够批量获取消息，需要下游消息接收方进行优化，方能够提升整体吞吐量，例如：批量写。

结论
1）MQ-client提供拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用（MQ需要做的）
2）要想提升整体吞吐量，需要下游优化，例如批量处理等方式（消息接收方需要做的）  

原文：https://blog.csdn.net/u011676417/article/details/70168194  
原文：https://www.jianshu.com/p/adf0b7de6753