MQ，在许多应用程序场景中，是消息的订阅和发布，以及系统上游和下游的解耦。 MQ的另一个典型应用场景是缓冲流量，削峰和填谷。本文将简要介绍MQ如何实现缓冲流量，峰削波和谷值填充。通常，站点与服务之间的上下游之间如何通信？有两种常见的方法。一种是“直接调用”，通过RPC框架，上游直接调用下游。一种是“ MQ推送”，上游将消息发送到MQ，并且MQ推送消息到下游。使用这两种方法，是否可以缓存流量，是否可以减少峰顶和填充谷底？不能。不管是否“直接呼叫”或“ MQ推送”使用时，有一个缺点。下游消息接收器无法控制流向自身的流。如果呼叫者不限制速率，则很可能使下游不堪重负。例如，峰值业务：上游：启动订单操作。下游：完成峰值业务逻辑（库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣除，库存扣除，流量生成，余额解冻，库存解冻）。上游订购业务很简单，每秒启动10,000个请求，而下游高峰业务很复杂，每秒只能处理2,000个请求。上游订单很有可能以无限的速度下订单，从而导致下游系统不堪重负，并导致雪崩。如何避免被下游压碎？为了避免雪崩，有两种常见的优化方案：（1）上游队列缓冲和限速发送； （2）下游队列缓冲和限速执行；无论采用哪种方案，都会带来业务复杂性，例如“需要流量缓冲的系统都需要添加类似的机制。由于以统一的方式解决了所谓的“普遍痛点”，因此需要一种通用的机制来解决这个问题。可以通过MQ实现缓冲区流吗？是的，但是需要简单的修改。如何更改MQ以缓冲流量？ MQ服务器推入模式已升级为MQ客户端拉入模式。 MQ客户端根据自身的处理能力，每隔一定时间或每次提取若干条消息，实现流控制，达到自我保护的效果。这是MQ提供的常规功能，无需修改上游和下游的代码。如果上游发送流量太大，那么MQ提供的拉模式确实可以在下游自我保护中起作用，这会导致消息在MQ中累积吗？下游MQ客户端提取消息，消息接收者可以批量获取消息。需要优化下游消息接收器，以提高整体吞吐量，例如批量写入。结论（1）MQ客户端提供拉模式，定时或批量拉模式，可以拉平流量并保护下游自我保护（需要做MQ）； （2）为了提高整体吞吐量，需要进行下游优化，例如批处理和其他方法（消息接收者需要做什么）；应该将体系结构优化视为一个整体，并且一般服务和业务方需要一起进行优化和升级。编辑：hfy