Behind the scenes: How Database Traffic Control works

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

Bài kỹ thuật về một tính năng của nhà cung cấp (PlanetScale Postgres). Cơ chế mô tả chi tiết và dùng lại được; mọi nhận định về hiệu quả là theo PlanetScale.

Bối cảnh

• Bài toán: database quá tải vì query đắt bất ngờ, kể cả nhiều query vừa phải cộng dồn lại.
• PlanetScale đã có extension pginsights dùng hook ExecutorRun/ProcessUtility để đo tài nguyên từng query (cho Query Insights). Ban đầu viết extension mới để chặn query, sau tách hai hướng: chặn theo phân tích tĩnh (thành pg_strict) và chặn theo tài nguyên dùng cộng dồn (thành Traffic Control, gộp vào pginsights để khỏi thêm overhead).

Cơ chế

• Lúc query bắt đầu thực thi, extension: (1) tìm các rule khớp tag/metadata của query (mỗi rule trỏ tới một budget); (2) kiểm tra giới hạn concurrency của budget; (3) kiểm tra chi phí ước lượng của từng query; (4) kiểm tra budget còn đủ chỗ (burst limit + server share). Trượt thì warn hoặc block.
• Block trước khi chạy nên server không tốn tài nguyên cho query bị chặn, khác với cgroups (cho chạy rồi bỏ đói) hay statement_timeout (cho ăn tài nguyên tới lúc hết giờ).
• Ước lượng chi phí: cost của planner gần tuyến tính nhưng không có đơn vị thật. Với mỗi query pattern trên mỗi host, giữ hai trung bình trượt mũ: CPU time thật và cost của planner. Tỉ số của chúng là hệ số k; chi phí dự đoán = cost planner × k, cập nhật sau mỗi query.
• Leaky bucket đảo ngược: mỗi query thêm "nợ" vào bucket; tràn thì chặn; nợ rút dần theo thời gian. Kích thước bucket = burst limit, tốc độ rút = server share dài hạn. Đảo ngược để bucket rỗng khỏi phải lưu: chỉ lưu bucket đang có nợ trong shared memory, không có tác vụ định kỳ; bucket được cập nhật khi đọc, và bị đẩy ra khi rỗng hoặc sắp rỗng nhất.
• Rule set: đánh chỉ mục rule theo cặp <key, value> nên số lần tra cứu tỉ lệ với số metadata của query, không phải số rule (O(1)), trừ rule theo dải IP (mỗi độ dài mask một lần tra) và rule kết hợp nhiều điều kiện.
• Áp rule mới trong 1–2 giây: rule được ghi thành tham số Postgres không cần restart, đẩy vào postgresql.conf trên mọi replica; mỗi worker nạp lại trước query tiếp theo. Dùng file cấu hình thay vì gửi qua SQL vì lúc cần rule gấp nhất (CPU 100%, hết worker) thì có thể không mở nổi kết nối mới.

Bài học cho SWE

• Load shedding ở tầng database: chặn trước khi tốn tài nguyên, theo budget có burst và chia sẻ dài hạn (Load shedding, rate limit và backpressure).
• Không cần ước lượng chi phí chính xác tuyệt đối; tự hiệu chỉnh theo thực tế từng pattern là đủ.
• Cấu trúc dữ liệu cho đường nóng nên tránh tác vụ định kỳ và chỉ lưu trạng thái khác mặc định.
• Kênh điều khiển phải sống được khi data plane quá tải: đừng gửi lệnh cứu hộ qua chính đường đang nghẽn.

Liên quan

• PlanetScale 2025 · PlanetScale 2026
• Load shedding, rate limit và backpressure