Ý chính: Thêm máy chủ chỉ tăng số việc có thể xử lý. Nó không sửa được một yêu cầu vốn đã quá nặng.
Thuật ngữ trong bài: Concurrency: số việc xử lý đồng thời; backpressure: giảm hoặc từ chối việc mới khi hệ thống gần quá tải; autoscaling: tự động tăng hoặc giảm máy chủ.
Bài toán thực tế
Nếu một yêu cầu phải gửi email, tạo báo cáo và xử lý tệp trước khi phản hồi, người dùng sẽ chờ lâu. Mỗi máy chủ mới còn mở thêm kết nối tới cơ sở dữ liệu, khiến điểm nghẽn phía dưới nghiêm trọng hơn.
Điểm dễ bị bỏ qua
Tự động mở rộng chỉ phản ứng sau khi một tín hiệu vượt ngưỡng; nó không làm một yêu cầu nặng trở nên rẻ hơn. Nếu mỗi máy chủ mới lại mở thêm kết nối và tạo thêm việc đồng bộ, điểm nghẽn chỉ bị đẩy xuống cơ sở dữ liệu.
Bước đầu tiên luôn là rút ngắn luồng đồng bộ của người dùng, xác định rõ việc nào có thể trì hoãn và đặt giới hạn cho hệ thống phía sau.
Luồng xử lý
Kiểm tra và lưu dữ liệu→API
Phản hồi nhanh→Queue
Hấp thụ tải đột biến→Worker
Xử lý việc phụ
Thiết kế và triển khai
Xác định rõ hợp đồng đồng bộ
Chỉ commit đúng phần trạng thái cần thiết để xác nhận thao tác của người dùng.
Thiết kế worker an toàn khi thử lại
Dùng một khóa chống xử lý trùng (khóa nhận diện để không xử lý trùng) cho mỗi thao tác nghiệp vụ, lưu trạng thái lần thử, và tách lỗi tạm thời khỏi lỗi kiểm chứng vĩnh viễn.
Mở rộng theo nhu cầu và mức bão hòa
API replica có thể bám theo mức xử lý đồng thời và độ trễ.
Đi sâu vào thiết kế
Backpressure là một phần của API contract
Queue không phải là năng lực vô hạn. Nó biến quá tải tức thời thành công việc bị trì hoãn.
Exactly-once là kết quả nghiệp vụ, không phải tính năng có sẵn của broker
Phần lớn broker (hệ thống trung chuyển tác vụ) chỉ đảm bảo at-least-once, nhất là quanh thời điểm crash. Để chỉ tạo đúng một hiệu ứng nghiệp vụ (exactly-once: chỉ tạo đúng một hiệu ứng nghiệp vụ), hãy lưu một idempotency record bền vững cùng một lần chuyển trạng thái, commit trong cùng transaction với đầu ra.
Cách triển khai
- Đo thời gian phản hồi rồi tách những việc người dùng không cần chờ khỏi luồng đồng bộ.
- Thiết kế tác vụ trong hàng đợi để chạy lặp vẫn chỉ tạo một kết quả, nhờ đó việc thử lại luôn an toàn.
- Mở rộng worker theo thời gian chờ của tác vụ cũ nhất và giới hạn phía sau, không chỉ theo CPU.
Mã minh họa: Tính năng lực hàng đợi và ngưỡng mở rộng
arrivalRate = jobsAdded / windowSeconds
serviceRate = jobsCompleted / windowSeconds
backlogTime = queueDepth / max(serviceRate, 1)
desiredWorkers = ceil(arrivalRate / jobsPerWorker)
desiredWorkers = clamp(desiredWorkers, minWorkers, maxWorkers)
if backlogTime > objectiveSeconds:
desiredWorkers = min(desiredWorkers + burstStep, maxWorkers)Little’s Law chỉ có ý nghĩa khi các phép đo dùng cùng một cửa sổ thời gian và hệ thống đang ở trạng thái tương đối ổn định.
Rủi ro cần tính trước
- Hàng đợi nhận việc nhanh hơn tốc độ cơ sở dữ liệu có thể ghi nhận kết quả.
- Một đợt triển khai dừng worker khi tác vụ vẫn đang thực hiện.
- Dịch vụ bên thứ ba giới hạn tần suất riêng một loại tác vụ và kéo dài toàn bộ hàng đợi.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Thời gian chờ của tác vụ cũ nhất | Đo trực tiếp độ trễ người dùng cảm nhận, kể cả khi số tác vụ không lớn. |
| Tốc độ nhận việc so với tốc độ hoàn tất | Cho biết lượng việc tồn đọng chỉ là tạm thời hay chắc chắn tiếp tục tăng. |
| Mức sử dụng worker và P95 thời gian xử lý | Phân biệt thiếu năng lực với một nhóm tác vụ chạy chậm bất thường. |
| Mức bão hòa kết nối và hạn mức dịch vụ bên ngoài | Xác định trần an toàn mà việc tăng worker không được vượt qua. |
Cách kiểm chứng
- Replay mỗi tác vụ nhiều lần, và xác nhận nghiệp vụ row, notification cùng external call đều chỉ có đúng một.
- Đẩy arrival rate vượt service rate, và kiểm tra khâu tiếp nhận control kích hoạt trước khi cơ sở dữ liệu bão hòa.
- Giết worker ở từng bước chuyển tiếp—trước khi claim, trong lúc xử lý và sau khi commit—để thử lease phục hồi.
- Giới hạn tốc độ một external dịch vụ phụ thuộc, và chứng minh queue tách biệt vẫn giữ được độ trễ cho các nhóm tác vụ không liên quan.
- Đo thời gian phục hồi sau một sự cố gián đoạn kéo dài, với toàn bộ lượng việc tồn đọng cộng thêm lưu lượng mới bình thường.
Đưa vào production từng bước
Chuyển từng tác động phụ, chẳng hạn gửi email hoặc tạo báo cáo, sang outbox và hàng đợi. Trong giai đoạn đầu, giữ kết quả đồng bộ làm chuẩn để đối chiếu; sau đó mới mở rộng worker theo tuổi hàng đợi và giới hạn thực tế của cơ sở dữ liệu.
Checklist trước khi vận hành
- Queue giúp hệ thống bền hơn, nhưng đổi lại kết quả sẽ hoàn tất sau chứ không tức thì.
- Lượng việc tồn đọng (lượng việc còn tồn đọng) tăng lên cần được cảnh báo trước khi người dùng cảm nhận được độ trễ.
- Bảo vệ cơ sở dữ liệu bằng giới hạn kết nối và mức đồng thời.
Điều cần nhớ
Tự động mở rộng chỉ phát huy tác dụng khi đơn vị công việc đã rõ, tải nặng đã được tách khỏi luồng người dùng và tín hiệu mở rộng phản ánh đúng nhu cầu.