思考

整个链路

高速队列

基于提问者的这个问题，歪师傅也想起了两个类似的场景。

一个是我参与开发过的一个对客发送短信的消息系统，简化一下整个流程大概是这样的：

上面这个图片会出现什么问题呢？

就是消息堆积。

当某个业务系统调用短信发送接口，批量发送消息的时候，比如发送营销活动时，大量的消息就在队列里面堆着，慢慢消费。

其实堆积也没有关系，毕竟营销活动的实时性要求不是那么高，不要求立马发送到客户手机上去。

但是，如果在消息堆积起来之后，突然有用户申请了验证码短信呢？

需要把前面堆积的消费完成后，才会发送验证码短信，这个已经来不及了，甚至验证码已经过期很久了你才发过去。

客户肯定会骂娘，因为获取不到验证码，他就不能进行后续业务。

如果大量客户因为收不到验证码不能进行后续业务，引起群体性的客诉，甚至用户恐慌，这个对于企业来说是一个非常严重的事件。

怎么办呢？

解决方案非常简单，再搞一个“高速”队列出来：

验证码消息直接扔到“高速”队列中去，这个队列专门用来处理验证码、动账通知这一类时效性要求极高的消息，从业务场景上分析，也不会出现消息堆积。

不是特别复杂的方案，大道至简，问题得到了解决。

类比到前面说的“快慢”线程池，其实是一样的思想，都是从资源上进行隔离。

只不过我说的这个场景更加简单，不需要去收集信息进行动态判断。业务流程上天然的就能区分出来，哪些消息实时性比较高，应该走“高速”队列；哪些消息慢慢 发没关系，可以应该走“常规”队列。

而这个所谓的“高速”和“常规”，只是开发人员给一个普通队列赋予的一个属性而已，站在 MQ 的角度，这两个队列没有任何区别。