MQ如何快速实现流量削峰填谷

问：站点与服务，服务与服务上下游之间，通常如何通信？

答：有两种常见的方式

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

在某些业务场景之下（具体哪些业务场景，见《到底何时该使用MQ？》），能够采用“MQ推送”，上游将消息发给MQ，MQ将消息推送给下游。

 

问：为何会有流量冲击？

答：无论采用“直接调用”仍是“MQ推送”，都有一个缺点，下游消息接收方没法控制到达本身的流量，若是调用方不限速，颇有可能把下游压垮。

 

举个栗子，秒杀业务：

上游发起下单操做

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

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

 

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

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

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

 

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

 

问：如何缓冲流量？

答：明明中间有了MQ，而且MQ有消息落地的机制，为什么不能利用MQ来作缓冲呢？显然是能够的。

 

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

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

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

 

问：若是上游发送流量过大，MQ提供拉模式确实能够起到下游自我保护的做用，会不会致使消息在MQ中堆积？

答：下游MQ-client拉取消息，消息接收方可以批量获取消息，须要下游消息接收方进行优化，方可以提高总体吞吐量，例如：批量写。

 

结论

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

2）要想提高总体吞吐量，须要下游优化，例如批量处理等方式（消息接收方须要作的）