后端技能树修炼：基于队列的流量削峰模式
source link: https://blog.csdn.net/asce1885/article/details/82822928?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作者简介：ASCE1885， 《Android 高级进阶》 和 《Android 高级进阶(源码剖析篇)》 作者
本文由于潜在的商业目的，未经授权不开放全文转载许可，谢谢！
在分布式架构中，前端一个请求会经过后端的多个服务的处理才返回结果，这时就可能会存在一种情况，在间歇性高负载情况下，某个服务 B 的处理能力不能满足负载的需求，从而导致服务 B 崩溃或者服务调用者 A 响应超时，如下图所示：
那么如何解决这种问题呢？有读者可能会说，那就给服务 B 作单机性能优化，从而提升单机处理能力，进而提升服务 B 集群的整体处理能力；或者当单机处理能力已经无法进一步优化或者即使优化后仍然无法满足负载需求时，那么就对服务 B 集群进行水平扩容，从而提升集群整体的处理能力。
没错，这是一种常见的解决方案，但如果服务 B 集群扩容成本很高呢？例如服务 B 需要用到 GPU 来跑 AI 模型，而我们知道 GPU 成本不低。有一种解决方案是通过引入消息队列（例如 Kafka，RabbitMQ 等）来作为缓冲区，从而最小化请求峰值对服务可用性和响应性的影响（当然，也要考虑具体业务场景是否适合使用这种方式），如下图所示：
引入消息队列后，原来的同步调用变为异步执行，服务 A 将原来的请求封装成消息，发送到消息队列中，而服务 B 则根据自己的处理节奏从消息队列中获取消息进行处理，消息队列起到缓冲区的作用。这样即使服务 A 集群对服务 B 集群发起大量的并发请求，也不会导致服务 B 集群处理不过来甚至崩溃。
当然这种模式也适用于进程内的流量削峰，我们只需把上面的服务 A 和服务 B 替换成同一个应用进程内的模块间调用，而消息队列则替换成进程内的队列实现方案（例如 Disruptor）即可， 模式是活的，具体如何应用就看使用者的水平了 。
参考资料： Queue-Based Load Leveling pattern
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK