Thiết kế hàng đợi chịu tải, công bằng và dễ phục hồi

Ý chính: Hàng đợi chỉ hấp thụ được các đợt tăng tải ngắn. Nếu nhận việc không giới hạn, nó chỉ biến quá tải thành thời gian chờ dài hơn.

Thuật ngữ trong bài: Queue: hàng đợi công việc; backpressure: giảm nhận việc khi xử lý không kịp; dead-letter queue: nơi giữ các công việc đã thử nhiều lần nhưng vẫn lỗi.

Bài toán thực tế

Tăng số tiến trình theo độ dài hàng đợi có thể làm quá tải cơ sở dữ liệu hoặc dịch vụ bên thứ ba. Một khách hàng nhập dữ liệu số lượng lớn cũng có thể chiếm hết năng lực xử lý nếu hệ thống không có hạn mức công bằng.

Điểm dễ bị bỏ qua

Số lượng tác vụ trong hàng đợi không phản ánh đầy đủ tác động tới khách hàng: mười email khác hoàn toàn mười tác vụ mã hóa video. Tín hiệu hữu ích hơn là thời gian chờ của tác vụ cũ nhất theo từng nhóm dịch vụ.

Tăng worker có thể làm hàng đợi ngắn lại nhưng khiến cơ sở dữ liệu hoặc nhà cung cấp bên ngoài quá tải. Mỗi nhóm tác vụ cần giới hạn xử lý đồng thời dựa trên năng lực thật của hệ thống phía sau.

Luồng xử lý

Thiết kế và triển khai

Cô lập miền sự cố

Tách queue hoặc nhóm worker cho tác vụ cần phản hồi nhanh, tác vụ hàng loạt và tích hợp bên thứ ba để một chỗ chậm không chặn toàn hệ thống.

Bảo đảm công bằng theo khách hàng

Đặt hạn mức đang xử lý theo khách hàng và cơ chế lập lịch có trọng số. Gói cao hơn có thể có trọng số lớn hơn, nhưng không khách hàng nào có mức xử lý đồng thời vô hạn.

Giới hạn mọi thử lại

Phân biệt lỗi tạm thời và vĩnh viễn; đặt số lần, thời hạn tổng và chính sách xử lý lỗi cuối cho từng nhóm.

Đi sâu vào thiết kế

Backpressure bắt đầu từ khâu tiếp nhận

Khi độ trễ dự đoán vượt mục tiêu, hãy từ chối, trì hoãn hoặc giảm chất lượng việc ưu tiên thấp. Nhận mọi thứ là tạo cam kết nền tảng không thể giữ.

Phục hồi phải có nhịp

Sau sự cố gián đoạn, xả lượng việc tồn đọng theo nhịp tăng dần và giới hạn của dịch vụ phụ thuộc. Mở toàn bộ worker ngay lập tức thường tạo sự cố gián đoạn lần hai.

Cách triển khai

1. Phân loại tác vụ theo mục tiêu độ trễ, chi phí xử lý và khách hàng trước khi đưa vào hàng đợi.
2. Mỗi tác vụ cần khóa chống xử lý trùng, giới hạn thử lại và chính sách rõ khi đã thử hết số lần.
3. Mở rộng theo thời gian chờ của tác vụ cũ nhất, nhưng không vượt giới hạn của cơ sở dữ liệu và dịch vụ bên ngoài.

Mã minh họa: Xử lý tác vụ an toàn khi broker giao trùng

job = broker.receive(visibilityTimeout = 60s)
if inbox.exists(job.id): ACK
with dependencyLimiter.acquire(job.kind):
  result = handle(job.payload)
  transaction(inbox.insert(job.id), save(result))
ACK

Thời gian giữ quyền xử lý phải dài hơn thời gian chạy thông thường; tác vụ dài cần gửi tín hiệu duy trì để gia hạn.

Rủi ro cần tính trước

• Quyền xử lý hết hạn khi worker vẫn đang chạy, khiến cùng một tác vụ được thực thi đồng thời hai lần.
• Bão thử lại xuất hiện khi dịch vụ phụ thuộc mới chỉ phục hồi một phần.
• Hàng đợi lỗi tăng âm thầm và biến thành mất dữ liệu nếu không có cảnh báo cùng người phụ trách.

Nên theo dõi gì?

Cách kiểm chứng

• Chủ động hạ năng lực cơ sở dữ liệu và chứng minh mức xử lý đồng thời không vượt ngân sách.
• Cho một khách hàng gửi một lô công việc lớn và kiểm tra tác vụ cần phản hồi nhanh vẫn đạt mục tiêu.
• Làm lease hết hạn giữa tác vụ và chứng minh trùng lặp chỉ tạo một kết quả.

Đưa vào production từng bước

Đo thời gian chờ và nguyên nhân thử lại trước khi thay đổi số worker. Tách một loại tác vụ rủi ro sang nhóm riêng, áp dụng giới hạn ở chế độ quan sát, rồi mới bật bắt buộc cho một nhóm khách hàng nhỏ và diễn tập phát lại từ hàng đợi lỗi.

Checklist trước khi vận hành

• Khi chi phí tác vụ khác nhau, thời gian chờ lâu nhất quan trọng hơn số lượng công việc.
• Mỗi lần thử lại cần giãn cách theo cấp số nhân có jitter và thời hạn hữu hạn.
• Hàng đợi chứa tác vụ lỗi phải có người phụ trách, cảnh báo và công cụ replay.

Điều cần nhớ

Hàng đợi trong production là một cơ chế kiểm soát năng lực, không phải vùng đệm vô hạn để nhận mọi công việc.