高并发下如何快速使用MQ实现缓冲流量，削峰填谷

为什么使用原因是？
服务之间的传递常用的调用就是直接调用(RPC框架)和消息MQ推送两种，但是都有一个缺点，下游消息接收方无法控制到达自己的流量，如果调用方不限速，很有可能把下游压垮。
 

背景信息

在实际应用中，收到的请求是没有规律的。例如：某应用的处理请求的能力是每秒 10 个。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把骤增的请求平均到一段时间内，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求

上图中，红色的部分代表超出消息处理能力的部分。把红色部分的消息平均到之后的空闲时间去处理，这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息。通过配置流控规则，可以达到消息匀速处理的效果。


举个例子，秒杀业务：

上游发起下单操作

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

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

 

为了避免雪崩，常见的优化方案有两种：

1）业务上游队列缓冲，限速发送

2）业务下游队列缓冲，限速执行


1、业务下游队列缓冲，限速执行第一种方法

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

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

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

 

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

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

rocketMQ的拉取模式代码  https://blog.csdn.net/zhaohongfei_358/article/details/101457563

rabbitMQ拉取模式代码 https://my.oschina.net/u/3959468/blog/2979069


2、业务下游队列缓冲，限速执行第二种方法

rabbitMQ 提供了一种 QOS (服务质量保证)功能，即在非自动确认消息的前提下，如果一定数目的消息(通过基于 consume 或者 channel 设置 QOS 的值)未被确认前，不进行消费新的消息。关键代码就是在声明消费者代码里面的

void basicQos(unit prefetchSize , ushort prefetchCount, bool global )

1. prefetchSize：0

2. prefetchCount：会告诉 RabbitMQ 不要同时给一个消费者推送多于 N 个消息，即一旦有 N 个消息还没有 ack，则该 consumer 将 block 掉，直到有消息 ack

3. global：true、false 是否将上面设置应用于 channel，简单点说，就是上面限制是 channel 级别的还是 consumer 级别

备注：prefetchSize 和 global 这两项，rabbitmq 没有实现，暂且不研究。特别注意一点，prefetchCount 在 no_ask=false 的情况下才生效，即在自动应答的情况下这两个值是不生效的。

具体可以学习：https://www.jianshu.com/p/36b9c367d440