Uber 如何征服数据库过载：从静态限流到智能负载管理的旅程

Uber’s thousands of microservices handle traffic for over 170 million monthly active users: riders, Uber Eats users, drivers, and couriers. At the heart of this infrastructure are Docstore and Schemaless, Uber’s in-house distributed databases built on top of MySQL®. These databases span thousands of clusters, store tens of petabytes of operational data, and serve tens of millions of requests per second with billions of rows read or updated. They back some of the most latency-sensitive and mission-critical workloads, powering every business vertical at Uber: from rides and deliveries to maps, payments, and beyond. 

Uber 的数千个微服务为超过 1.7 亿月活跃用户处理流量：乘客、Uber Eats 用户、司机和快递员。这一基础设施的核心是 Docstore 和 Schemaless，这些是 Uber 基于 MySQL® 构建的内部分布式数据库。这些数据库跨越数千个集群，存储数十 PB 的运营数据，并以每秒数千万请求的速率服务，读取或更新数十亿行数据。它们支持一些最具延迟敏感性和使命关键的工作负载，为 Uber 的每个业务垂直领域提供动力：从乘车和配送到地图、支付等。 

At this scale, even minor overloads aren’t isolated events, they cascade. A brief spike in one part of the system can ripple outward: downstream services time out, retries pile up, and degradation amplifies into broader failure. In a multitenant environment, it’s also critical to ensure fairness and prevent any tenant from hogging all the resources. With workloads varying in traffic shape, latency profiles, and system impact, building effective overload protection is a uniquely challenging problem.

在这种规模下，即使是轻微的过载也不是孤立事件，它们会级联。系统中一个部分的短暂峰值可以向外扩散：下游服务超时，重试堆积，退化放大成更广泛的故障。在多租户环境中，确保公平并防止任何租户占用所有资源也是至关重要的。随着工作负载在流量形状、延迟配置文件和系统影响方面的变化，构建有效的过载保护是一个独特具有挑战性的问题。

The cost of getting overload protection wrong is steep. This blog shares how we built an intelligent load manager that detects overload from multiple signals to keep our databases stable and fair under pressure.

过载保护出错的代价很高。本文分享了我们如何构建一个智能负载管理器，它从多个信号检测过载，以在压力下保持数据库稳定和公平。

Before diving into the load manager that protects Uber’s databases, let’s walk through their architecture.

在深入探讨保护 Uber 数据库的负载管理器之前，让我们先了解其架构。

While Docstore supports transactions with full CRUD operations and Schemaless is optimized for append-only workloads...