Một cựu kỹ sư hạ tầng của Reddit gần đây đã chia sẻ cách tiếp cận của họ để giải quyết các vấn đề hàng đợi phân tán đã làm khổ nền tảng mạng xã hội này hơn một thập kỷ trước. Bài viết hứa hẹn cung cấp những hiểu biết sâu sắc về cách họ giải quyết các vấn đề mà ở đó các lượt vote, bình luận và bài đăng của người dùng có thể biến mất khi hệ thống gặp sự cố. Tuy nhiên, cộng đồng kỹ thuật đã đặt ra câu hỏi về tính đầy đủ của lời giải thích và cách trình bày giải pháp.
Vấn đề ban đầu tại Reddit
Trong những năm đầu của Reddit, nền tảng này phụ thuộc rất nhiều vào RabbitMQ làm message broker để xử lý các tương tác của người dùng. Khi người dùng upvote các bài đăng, hành động này sẽ đi vào một hàng đợi phân tán trước khi đến cơ sở dữ liệu. Kiến trúc này cung cấp khả năng mở rộng theo chiều ngang và kiểm soát luồng nhưng đi kèm với các vấn đề đáng kể về độ tin cậy. Sự cố hệ thống có thể dẫn đến mất dữ liệu, và khi chính hàng đợi gặp sự cố, các lượt vote và bình luận của người dùng sẽ đơn giản là biến mất.
Kỹ sư này giải thích rằng những gì Reddit thực sự cần là các hàng đợi bền vững có thể checkpoint trạng thái tác vụ vào bộ nhớ lâu dài như PostgreSQL. Những hệ thống này kết hợp hàng đợi tác vụ với các workflow bền vững, cho phép các công việc bị lỗi có thể tiếp tục từ bước hoàn thành cuối cùng thay vì bắt đầu lại hoặc biến mất hoàn toàn.
Kiến trúc gốc của Reddit (hơn 15 năm trước):
- Message Broker: RabbitMQ
- Cache: Hệ thống giống Redis
- Database: PostgreSQL
- Luồng xử lý: Hành động của người dùng → Queue + Cache → Phản hồi thành công → Bộ xử lý Queue → Database + Tính toán lại
Câu hỏi của cộng đồng về những khoảng trống kỹ thuật
Cộng đồng kỹ thuật đã chỉ ra một số vấn đề với cách trình bày của bài viết. Những người chỉ trích lưu ý rằng bài viết không bao giờ giải thích rõ ràng cách tác giả giải quyết vấn đề ban đầu, bất chấp tiêu đề đầy hứa hẹn. Bài viết tập trung rất nhiều vào việc mô tả hàng đợi bền vững như một khái niệm nhưng thiếu chi tiết cụ thể về triển khai hoặc so sánh với các giải pháp hiện có.
Tôi có bỏ lỡ điều gì đó không hay bài viết không bao giờ đề cập đến tiêu đề? Bài đăng là một mô tả hay về hàng đợi bền vững, nhưng nó không bao giờ nói rõ ràng rằng chúng là giải pháp cho vấn đề hàng đợi phân tán, cũng không định nghĩa cụ thể vấn đề đó là gì.
Ngoài ra, các nhà phát triển có kinh nghiệm đã đặt câu hỏi liệu chính RabbitMQ có phải là vấn đề hay không, lưu ý rằng ngay cả 15 năm trước, RabbitMQ đã hỗ trợ tính bền vững và giao dịch với khả năng rollback. Một số người cho rằng các vấn đề được mô tả có thể xuất phát từ việc sử dụng RabbitMQ không đúng cách thay vì những hạn chế của chính công nghệ này.
 |
|---|
| Cảnh kẹt xe tượng trưng cho tình trạng tắc nghẽn và kém hiệu quả trong quản lý hàng đợi phân tán, phản ánh mối quan ngại của cộng đồng về các giải pháp trong bài viết gốc |
Thảo luận về Durable Workflows
Trọng tâm của bài viết chuyển hướng đáng kể sang durable workflows, khác với các hàng đợi bền vững đơn giản. Durable workflows cho phép các nhà phát triển viết code có thể tạm dừng và tiếp tục thực thi qua các lỗi hệ thống, duy trì trạng thái trong bộ nhớ lâu dài. Công nghệ này đã thu hút sự chú ý với các nền tảng như Temporal, DBOS, Inngest, và Restate cung cấp các triển khai khác nhau.
Tuy nhiên, các thành viên cộng đồng lưu ý rằng durable workflows yêu cầu các nhà phát triển tái cấu trúc code của họ xung quanh các async runtime tùy chỉnh và lập trình kiểu callback. Điều này đại diện cho một thay đổi kiến trúc đáng kể vượt xa việc đơn giản làm cho hàng đợi đáng tin cậy hơn.
Lưu ý: Durable workflows là các hệ thống có thể tạm dừng và tiếp tục các quy trình chạy dài qua các lỗi hệ thống bằng cách lưu trạng thái của chúng vào bộ nhớ lâu dài tại các checkpoint quan trọng.
Các Nền Tảng Hàng Đợi Bền Vững Được Đề Cập:
- Temporal (https://temporal.io/)
- DBOS (https://www.dbos.dev/)
- Inngest (https://www.inngest.com/)
- Restate (https://restate.dev/)
 |
|---|
| Một đoạn mã Python cho thấy cách triển khai hàng đợi bền vững, đại diện cho một phần quan trọng trong việc tái cấu trúc quy trình làm việc như đã thảo luận trong bài viết |
Đánh đổi hiệu suất và các lựa chọn thay thế hiện đại
Cuộc thảo luận tiết lộ những cân nhắc quan trọng về khi nào nên chọn hàng đợi bền vững thay vì các giải pháp truyền thống. Hàng đợi bền vững thường sử dụng cơ sở dữ liệu quan hệ như PostgreSQL cho cả message brokering và lưu trữ, điều này cung cấp đảm bảo mạnh mẽ hơn nhưng có khả năng throughput thấp hơn so với các giải pháp trong bộ nhớ như Redis.
Cộng đồng cũng đặt ra câu hỏi về cách tiếp cận này so sánh với các nền tảng streaming hiện đại như Kafka, có thể cung cấp cả tính bền vững và hiệu suất cao. Một số người cho rằng việc lựa chọn giữa các công nghệ hàng đợi khác nhau phụ thuộc nhiều hơn vào các trường hợp sử dụng cụ thể và chi tiết triển khai hơn là những hạn chế kiến trúc cơ bản.
Các đánh đổi kỹ thuật chính:
- Hàng đợi truyền thống: Thông lượng cao hơn, lưu trữ trong bộ nhớ ( Redis ), có khả năng mất dữ liệu
- Hàng đợi bền vững: Thông lượng thấp hơn, lưu trữ liên tục ( PostgreSQL ), đảm bảo tính bền vững
- Hiệu suất: Hàng đợi bền vững tốt hơn cho các tác vụ có khối lượng thấp, quan trọng về mặt kinh doanh; hàng đợi truyền thống tốt hơn cho các tác vụ có khối lượng cao, nhỏ hơn
Kết luận
Trong khi bài viết gốc nhằm chia sẻ các bài học kinh nghiệm từ việc giải quyết vấn đề hàng đợi phân tán tại Reddit, thay vào đó nó đã khơi mào một cuộc thảo luận rộng hơn về sự phát triển của các công nghệ message queuing và những đánh đổi liên quan trong các cách tiếp cận khác nhau. Phản ứng của cộng đồng nhấn mạnh tầm quan trọng của việc cung cấp chi tiết kỹ thuật cụ thể và thừa nhận toàn cảnh các giải pháp có sẵn khi thảo luận về các thách thức hạ tầng. Cuộc trò chuyện tiếp tục phát triển xung quanh các thực hành tốt nhất để xây dựng hệ thống phân tán đáng tin cậy trong các ứng dụng hiện đại.
Tham khảo: How I solved a distributed queue problem after 15 years