从静态到自适应：Airbnb 键值存储系统应对流量峰值的控制机制

Airbnb 升级了其多租户键值存储 Mussel 的流量管理架构，用一个完全自适应的资源感知系统取代了针对每个客户端的静态速率限制。这次重新设计是为了在流量高峰期间仍然能够保持服务质量，保护关键工作流程，并确保成千上万的租户之间能够公平地使用其服务。

Mussel最初依赖于一个基于Redis的计数器，将每个客户端的每秒查询数（QPS）限制在一个固定的值。虽然这能实现基本的隔离，但它没有考虑到请求的真实成本，也无法快速适应变化的工作负载。高波动性流量模式、大规模数据上传、促销带来的突发流量，以及自动化流程引发的流量峰值，都暴露了设置静态上限的局限性。

流量管理策略的演进（图片来源：Airbnb技术博客）

Airbnb 工程师Shravan Gaonkar、Casey Getz和Wonhee Cho解释了在 Mussel 上进行流量管理的重要性：

Mussel 系统日常处理数百万可预测的读取请求，但在高峰事件期间，必须应对更大的数据量、达太字节级别的上传任务，以及来自机器人或 DDoS 攻击的突发流量。可靠地处理这种波动性流量，对 Airbnb 的用户体验和支撑平台运行的服务的稳定性都至关重要。

重新设计的第一个组件是一个资源感知速率控制器。它使用请求单元（RU）来度量请求，考虑了处理的行数、读取或写入的字节数以及延迟。每个调度器的令牌桶都会定期补充，并按请求扣除 RU 成本。当令牌耗尽时，调度器会返回 HTTP 429 响应。本地执行消除了跨节点协调，可实现毫秒级的快速独立决策。

延迟响应随时间变化的情况和限流示意图（图片来源：Airbnb技术博客）

为了在流量激增时能够保持稳定，系统新增了负载削减机制。调度器通过P²分位数估计算法计算延迟比率，在不存储完整样本的情况下对比短期与长期 p95 延迟值。结合内部队列压力信号及客户端流量分类，当后端资源接近饱和时，调度器可延迟或丢弃请求以保障整体吞吐量。

Airbnb 还引入了一个热键防御层。调度器通过内存 top-k 检测和本地 LRU 缓存，识别出流量异常集中的键。当某个键成为热键时，调度器会提供缓存结果并合并并发请求，从而降低后端分片的负载。

实时检测并从调度器缓存提供热键（图片来源：Airbnb技术博客）

根据 Airbnb 的报告，在一次针对一小组键值的受控 DDoS 演练中（大约一百万 QPS），热键层将突发流量削减成了涓涓细流。每个调度器仅转发零星请求，使负载始终远低于单个分片的承载能力，从而避免了后端过载。

工程团队强调，保持控制回路本地化是 Mussel 演变的关键。资源感知速率控制、负载削减和热键管理都是在每个调度器内运行，消除了跨节点协调。这种设计有助于实现快速的独立决策、压力下的线性扩展，并在高峰事件期间可靠地保护系统，生动展示了分层成本感知QoS在处理不稳定流量时如何兼顾弹性和公平性。

Airbnb 计划进一步改进，包括根据历史使用情况自动调整配额以及通过资源组实现更紧密的数据库集成，从而提高 Mussel 的吞吐量和服务隔离。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2025/11/airbnb-mussel-adaptive-traffic/