MQ实战-削峰填谷

对于突然到来的大量请求，您可以配置流控规则，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量突刺造成系统负载过高。

1、场景

请求的到来，往往是没有规律的。

例如，某应用的处理能力是每秒 10 个请求。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把请求突刺均摊到一段时间内，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求，从而起到“削峰填谷”的效果。

 

上图中，红色的部分代表超出消息处理能力的部分。观察得出，消息突刺往往都是瞬时的、不规律的，其后一段时间系统往往都会有空闲资源。把红色的那部分消息平摊到后面空闲时去处理，这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息。通过配置流控规则，可以达到消息匀速处理的效果。

 

2、分析问答

  1、问：站点与服务，服务与服务上下游之间，一般如何通讯？

        答：有两种常见的方式

       一种是“直接调用”，通过RPC框架，上游直接调用下游：

     

       还有一种，在某些业务场景之下（具体哪些业务场景，见《到底什么时候该使用MQ？》），可以采用“MQ推送”，上游将消息发给MQ，MQ将消息推送给下游。

        

    这两种都有问题：不管采用“直接调用”还是“MQ推送”，都有一个缺点，下游消息接收方无法控制到达自己的流量，如果调用方不限速，很有可能把下游压垮。

---

   2、问：以上两种为什么会有流量冲击？

        答：不管采用“直接调用”还是“MQ推送”，都有一个缺点，下游消息接收方无法控制到达自己的流量，如果调用方不限速，很有可能把下游压垮。

      举个栗子，秒杀业务：

      上游发起高并发的下单操作。

      下游完成秒杀业务逻辑（库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻）。

       上游下单业务简单，每秒发起了10000个请求，下游秒杀业务复杂，每秒只能处理2000个请求，很有可能上游不限速的下单，导致下游系统被压垮，引发雪崩。 

---

     3、问：MQ怎么改能缓冲流量？

         答：由MQ-server推模式，升级为MQ-client拉模式。

       

       MQ-client根据自己的处理能力，每隔一定时间，或者每次拉取若干条消息，实施流控，达到保护自身的效果。并且这是MQ提供的通用功能，无需上下游修改代码。

kafka代码实例：

   

    4、问：如果上游发送流量过大，MQ提供拉模式确实可以起到下游自我保护的作用，会不会导致消息在MQ中堆积？

         答：下游MQ-client拉取消息，消息接收方能够批量获取消息，需要下游消息接收方进行优化，方能够提升整体吞吐量，例如：批量写。

  3、结论

      1）MQ-client提供拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用（MQ需要做的）

      2）要想提升整体吞吐量，需要下游优化，例如批量处理等方式（消息接收方需要做的）