如何应对突发流量或“Thundering Herd 问题”？

想象一个场景，某个事件导致您的一个或多个服务突然遭遇巨大的流量激增，超过了它们的承载能力。这可能导致一个或多个依赖项，如数据库，变得过载并无法响应，最终导致服务失败，即所谓的“级联故障”。此类事件可能包括多个服务实例失败并将所有流量重定向到单个实例，一个病毒图片或视频突然爆红，或在节日期间进行的在线销售导致数据库过载。这种情况通常是由突然的流量激增引发，从而导致服务不可用。这种情况被称为“Thundering Herd 问题”，或直译为“怒冲羊群问题”。

图。轰鸣兽群效应

解释：指数级抖动指的是每次尝试之间的时间间隔呈指数增长，重试策略则是当操作失败时，按照设定的规则自动再次尝试。

当服务未能响应时，一种本能的解决方式是重试请求，假设这是一个暂时的失败。然而，这种方法可能导致“惊群”现象，或者加剧现有的情况，因为所有客户端会同时重试，从而压垮系统。相反，如果客户端以随机间隔重试，超载的系统就有时间恢复并作出回应。这种重试时间上的随机性，称为抖动（Jitter），有助于更均匀地分配负载，并防止系统进一步承压。

图示：指数抖动重试

考虑一种场景，当从缓存获取图像的请求导致缓存未命中，从而导致请求直接从数据存储中获取。如果大量同时请求未能从缓存中找到所需图像并被转发至数据存储，这可能引发“Thundering Herd”现象。因为所有请求都是针对同一个图像，因此只需将一个请求转发到数据存储中处理。其他请求则排队等待，一旦初始请求从数据存储返回并更新缓存，这些请求就能从缓存中获取响应。

排队请求的图示

每个大型应用在某个时候都需要在后台进行服务复制部署以处理日益增长的流量。然而，如果这些流量没有均匀地分配到所有的服务副本上，某些实例可能会过载。使用负载均衡器均匀分配负载有助于避免“Thundering Herd”问题。

图：负载平衡

如果你喜欢这篇文章，请免费订阅我的每周通讯通讯，你就可以直接在邮箱里收到下一篇文章了。我用简单易懂的方式解释软件工程概念，就像在给五岁的小朋友讲解一样！

如果一个服务暴露了API，向其客户端提供无限制的访问可能会带来灾难性后果，如果一个或多个客户端滥用它。像DDOS攻击或计划好的批处理作业这样的场景可能会触发“Thundering Herd（奔腾的畜群）”问题。通过实施速率限制来控制客户端调用API的频率可以帮助管理高吞吐量请求并避免类似的问题。

图：限速

一个服务依赖项，如数据库，可能会因为“Thundering Herd”（雷轰群）问题而失败。类似于MCB（微型断路器）通过在电压突然升高时断开电路来保护电路，服务也可以实现断路器方法。这种方法会暂停发送更多的向外请求，直到依赖项恢复并准备好再次应对请求。

图：示例断路器

虽然断路器允许一个服务停止向依赖项发送请求，依赖项可以丢弃传入的请求以进行负载减载，这是一种防止“羊群效应”问题的技术。这类似于电力系统中的轮流停电，当需求超过容量时，电力供应商会减少负载以防止整个系统崩溃。

图：限电

如果您喜欢阅读，可以考虑订阅我的周报通讯通讯_，直接发送到您的邮箱。我用简单的方式解释软件工程的相关概念，就像在给五岁的小朋友解释一样！

订阅我们的通讯