Thách thức
Một đội ngũ vận hành ứng dụng Rails trên YugabyteDB gặp bế tắc. Các job của Solid Queue liên tục rơi vào vòng lặp lỗi tuần tự hóa (serialization) rồi thử lại (retry) rồi lại lỗi, cho đến khi hệ thống hàng đợi sụp đổ dưới chính áp lực xử lý đồng thời của nó. Ứng dụng chính vẫn chạy bình thường. Hệ thống xử lý tác vụ nền thì không. Đổi thư viện hàng đợi hay đổi cơ sở dữ liệu, cả hai đều không phải là lựa chọn.
Chúng tôi đã làm gì
Chúng tôi truy ngược lỗi về đúng gốc rễ: mức cô lập giao dịch (transaction-isolation level). Solid Queue giả định cơ chế khóa (lock semantics) của Postgres chạy đơn nút (single-node); còn YugabyteDB mặc định áp dụng snapshot isolation. Hai giả định này không “khớp” được với nhau khi chịu tải cao.
Giải pháp kết hợp tinh chỉnh các cờ cấu hình (flag) của TServer ở phía cơ sở dữ liệu với một số thay đổi cấu hình nhỏ trong Rails, đủ để đồng bộ lại kỳ vọng giữa hai hệ thống, nhưng không đến mức phải fork (rẽ nhánh mã nguồn) bất kỳ dự án nào.
Điều gì đã thay đổi
Hàng đợi đứng vững. Hệ thống xử lý tác vụ nền giờ có khả năng mở rộng theo chiều ngang và phân tán địa lý theo mặc định, vì bản thân cơ sở dữ liệu bên dưới vốn đã như vậy. Tầng ứng dụng không hề thay đổi.