Monzo 采用有针对性的流量削峰策略，以抵御移动应用引发的惊群效应

Monzo 已经开发了一种解决方案，用于应对其平台突然而强烈的流量负担，以防止服务中断。这种流量高峰可能是由移动应用引发的，例如推送通知或用户活动的突发增加。这一解决方案能够在几乎不影响客户体验的前提下，将读取流量减少近 50%，整体准确率高达 90%。

Monzo 银行平台拥有数百万用户，他们主要通过移动应用程序与平台互动。然而，有时流量激增可能会使平台陷入不稳定状态。这可能是由于向大量用户发送定期的推送通知或特定时间的功能，比如“提前获得薪水”。尽管 Monzo 团队已经采取了积极的扩展措施来确保平台具备足够的容量来处理 “提前获得薪水” 等事件，但突如其来的流量激增仍然构成重大风险。

Monzo 的高级工程师 Jacob Moxham 解释了为什么惊群效应（类似于“惊群问题”）对于 Monzo 平台的稳定性非常危险：

惊群效应是我们用来描述大量客户在非常短的时间内打开应用程序的情况。如果我们没有为这些时刻做好准备，可能会用尽缓冲容量，无法迅速扩展我们的平台。在最糟糕的情况下，共享基础设施可能会超负荷，导致广泛的中断。

问题被放大，因为 Monzo 应用在打开或接收到推送通知时会预取数据，以确保立即提供最新信息。团队怀疑大多数这些请求只会返回相同的数据。在为 0.1% 的用户部署额外的日志记录到边缘代理后，日志显示在 24 小时内大约有 70% 的请求返回相同的数据。

为了消除“浪费”的请求，工程师首先选择创建一个“更改 API”，该 API 将返回最常用和昂贵的终端的最后更新时间。移动应用程序将查询新的更改 API，并仅在自上次调用以来数据已更改时才请求数据。这种方法在提供准确的最后更新时间戳方面遇到困难，因为常规 API 终端中实施了实时数据增强，并且对 API 资源的更新存在复杂的数据流程。

 边缘代理中的请求削峰逻辑 （来源 ：Monzo Technology Blog）

相反，团队得出结论，与其实施完美且永久的解决方案，他们可以创建一个足够但成本更低的解决方案，只在平台出现严重和意外负荷时激活它。他们确定了三个特征来帮助确定是否削减请求：响应计算的时间，数据预取的触发器以及在进行请求时移动应用程序打开的时间。

对于第一个特征，工程师重新利用了 API 终端返回的 Etag HTTP 标头，其中包含响应哈希和上次计算的时间。在预取数据时，移动应用程序将发送包含与相同请求的先前返回的 Etag 标头的值以及自定义标头中的其他两个特征的 If-None-Match HTTP 标头。基于标头中的元数据，边缘代理中部署的负载削减策略将确定是否忽略请求并返回 304（未修改）状态码或返回计算的响应。不同的预取触发器的策略可以分别激活，使团队逐步减少移动应用程序流量的各个部分。

启用请求削峰后的流量减少（来源：Monzo Technology Blog）

团队通过在阴影模式下部署新的策略进行试验，即计算响应并根据请求元数据与实际结果进行比较来决定是否削减请求。当所有策略都激活时，平台能够在整体准确率达到 90% 的情况下，减少近 50% 的 GET 请求。工程师报告称，客户体验没有明显变化，与可能影响整个平台的主要故障相比，允许一小部分用户看到陈旧数据是可以接受的。

原文链接：

https://www.infoq.com/news/2023/10/Nvidia-matx-cpp-numerical-lib/