Uber's Rate Limiting System

Uber · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Kiến trúc service của Uber xử lý hàng trăm triệu RPC mỗi giây qua hàng nghìn service. Thời đầu mỗi team tự throttle (trong logic nghiệp vụ, middleware riêng, counter Redis): cấu hình và hành vi khác nhau dù cùng quota; limiter Redis thêm latency và một fleet phải vận hành; đổi limit phải deploy lại; limiter rải rác khó tìm và sửa lúc có sự cố, nâng thư viện có thể đổi hành vi; nhiều service nhỏ không có limiter nào; metric không thống nhất nên không biết lỗi do rate limit hay do thứ khác.
• Theo Uber, counter tập trung kiểu Redis không scale tới hàng trăm nghìn host ở nhiều region (mỗi request một lượt đọc/ghi từ xa, khó nhất quán giữa region, cần hàng trăm cụm Redis); đồng bộ counter định kỳ thì dữ liệu cũ và phản ứng chậm với đỉnh đột ngột.

Thay đổi chính

• Global Rate Limiter (GRL) trong service mesh: mọi request được xét trước khi tới đích, không phụ thuộc ngôn ngữ, không cần sửa code của service đích. Ba tầng: client trong data plane của mesh quyết định tại chỗ và báo số request mỗi giây của từng host; aggregator mỗi zone gộp mức dùng; controller mỗi region/toàn cầu tính mức dùng tổng và đẩy chỉ thị xuống. Quyết định nằm ở đường nóng tại chỗ, phối hợp toàn cục trong vài giây; control plane mất thì client fail open.
• Từ token bucket sang drop theo tỉ lệ: bản đầu dùng token bucket ở mỗi proxy (tốc độ nạp token theo tỉ lệ tải cục bộ so với tải toàn cục, giữ token dư tới 10–20 giây cho đợt bùng). Ở production: không chia công bằng khi số caller vượt limit, và host có traffic bùng bắt đầu drop sớm trong khi tổng tải vẫn dưới limit. Thêm drop-by-ratio: khi tải tổng của một caller vượt limit, mọi instance của caller đó drop ngẫu nhiên theo drop_ratio = (actual − limit) / actual (vượt 1,5 lần thì drop khoảng 33%). Sau đó bỏ hẳn token bucket, còn một mô hình: control plane tính tỉ lệ drop mỗi giây, client chỉ lấy mẫu ngẫu nhiên. Đánh đổi: quyết định trễ tối đa 2–3 giây so với traffic thật; theo Uber hầu như không đáng kể, trừ đợt bùng rất ngắn và rất cao, và chấp nhận được hơn là drop oan khi cả hệ còn dư.
• Cấu hình: bucket theo caller, procedure hoặc cả hai; phạm vi toàn cầu, region hoặc zone; chế độ deny hoặc shadow (chỉ quan sát).
• Kết quả, theo Uber: bỏ limiter Redis ở một service lớn làm request dồn về bucket latency thấp; P50 giảm khoảng 1 ms, P90 giảm hàng chục ms, P99.5 từ vài trăm ms xuống hàng chục ms (tới 90%); giải phóng nhiều instance Redis. GRL chặn quá tải lúc đỉnh, failover và retry storm, và là công cụ của playbook sự cố (áp limit có mục tiêu lên caller hay procedure trong vài giây, không deploy). Quy mô: khoảng 80 triệu request/giây qua hơn 1.100 service.
• Rate Limit Configurator (RLC): limit YAML tĩnh nhanh chóng lỗi thời (quá chặt thì throttle lúc đỉnh khoẻ, quá lỏng thì không bảo vệ gì). RLC định kỳ lấy metric vài tuần gần nhất, tính limit an toàn từ đỉnh lịch sử cộng khoảng đệm, ghi vào repo cấu hình chung, đẩy qua control plane. Chính sách cắm được: theo lịch sử, theo dự báo (dịch vụ bản đồ), hay quota cố định theo thoả thuận; chạy shadow trước khi bật. Sau đó: limit theo region để giảm bán kính ảnh hưởng khi đổi cấu hình, tăng tần suất cập nhật; lớp throttler gần ứng dụng bổ sung thêm.

Vì sao

• Theo Uber, chỉ kiến trúc phân tán hoàn toàn (proxy cục bộ quyết định theo tải đã gộp, không có counter trung tâm) đạt được cả latency thấp lẫn quy mô toàn cầu.

Bài học cho SWE

• Đặt bảo vệ quá tải ở lớp hạ tầng chung (mesh) thì mọi service có nó, kể cả service không ai nghĩ tới.
• Tách đường nóng (lấy mẫu ngẫu nhiên tại chỗ) khỏi phần tính toán (control plane mỗi giây); chấp nhận trễ vài giây để không có hop mạng mỗi request.
• Drop theo tỉ lệ trên toàn bộ instance của caller công bằng hơn token theo từng host.
• Limit tĩnh sẽ lỗi thời; sinh limit từ traffic thật và chạy shadow trước khi chặn.
• Control plane hỏng thì fail open, để công cụ bảo vệ không tự gây sự cố.

Liên quan

• Load shedding, rate limit và backpressure · Nền tảng nội bộ cho service (đường ray chung)
• Cùng công ty: Uber 2026 · Uber 2026
• Cùng bài toán: Salesforce 2026 (bỏ rate limit theo instance, quota toàn cục không coordinator)