Cộng đồng công nghệ đang sôi nổi với những câu chuyện về các triển khai message queue phi truyền thống, được khơi dậy bởi các cuộc thảo luận xung quanh các giải pháp kỹ thuật sáng tạo. Trong khi các message queue truyền thống như Amazon SQS hoặc Apache Kafka là những lựa chọn tiêu chuẩn, các lập trình viên đã tìm thấy những giải pháp thay thế hiệu quả đáng ngạc nhiên ở những nơi bất ngờ nhất.
Email Server như Message Queue
Một trong những ví dụ hấp dẫn nhất đến từ một startup thập niên 1990 không đủ khả năng chi trả cho các giải pháp messaging doanh nghiệp đắt đỏ. Nhóm này đã chuyển sang sử dụng Microsoft Exchange Server như hệ thống message queue của họ. Các message producer sử dụng thư viện SMTP để gửi email, trong khi consumer sử dụng Exchange API để đọc các tin nhắn chưa đọc. Họ đánh dấu tin nhắn là đã đọc trong quá trình xử lý và chuyển các tác vụ hoàn thành sang các thư mục khác nhau. Giải pháp sáng tạo này đã hoạt động hiệu quả đáng kể trong năm năm, cung cấp khả năng kiểm tra queue dễ dàng thông qua các email client tiêu chuẩn và thậm chí cho phép con người xử lý một số queue khi cần thiết.
SMTP (Simple Mail Transfer Protocol) là giao thức tiêu chuẩn để gửi email, trong khi API (Application Programming Interface) là tập hợp các công cụ cho phép các chương trình phần mềm khác nhau giao tiếp với nhau.
Ví dụ về Message Queue sáng tạo:
- Máy chủ email ( Microsoft Exchange với SMTP/APIs )
- Bảng cơ sở dữ liệu với SELECT FOR UPDATE SKIP LOCKED
- Bucket Amazon S3 (đắt đỏ và không hiệu quả)
- Repository Git với webhooks
- Bộ định tuyến mạng với gói tin UDP
- Hệ thống tệp và gói tin ping
Bài học đắt giá của Amazon với S3
Cuộc thảo luận cũng làm nổi bật sai lầm kiến trúc khét tiếng của Amazon Prime Video , nơi họ sử dụng các storage bucket Amazon S3 để xử lý từng frame video riêng lẻ cho xử lý thời gian thực. Cách tiếp cận này tạo ra chi phí khổng lồ do số lượng storage request cao và chạm đến giới hạn dịch vụ AWS . Nhóm cuối cùng đã quay trở lại kiến trúc monolithic truyền thống, chứng minh rằng ngay cả các gã khổng lồ công nghệ cũng có thể rơi vào bẫy over-engineering với các dịch vụ cloud.
Họ thực sự đã say mê AWS serverless quá sâu nếu họ nghĩ cách đúng để stream video là nhiều microservice truy cập từng frame riêng lẻ trên S3 .
Bảng cơ sở dữ liệu và giao thức mạng
Nhiều lập trình viên đã chia sẻ kinh nghiệm với message queue dựa trên cơ sở dữ liệu sử dụng các lệnh SQL như SELECT FOR UPDATE SKIP LOCKED để ngăn chặn xử lý trùng lặp. Mặc dù điều này hoạt động với các ứng dụng nhỏ hơn, nó thường bị hỏng dưới lưu lượng truy cập cao do các vấn đề khóa và race condition. Một số thậm chí đề xuất sử dụng router mạng và UDP packet như hệ thống phân phối tin nhắn thông lượng cao, mặc dù cách tiếp cận này hy sinh đảm bảo phân phối để đổi lấy tốc độ.
UDP (User Datagram Protocol) là một giao thức mạng gửi dữ liệu nhanh chóng nhưng không đảm bảo rằng tất cả tin nhắn sẽ đến hoặc đến theo thứ tự.
Git Repository và hơn thế nữa
Có lẽ giải pháp sáng tạo nhất liên quan đến việc sử dụng GitLab repository với webhook như một hệ thống event có queue. Các thay đổi sẽ kích hoạt webhook thêm dữ liệu vào file JSON , commit các thay đổi và kích hoạt các quy trình downstream. Mặc dù được mô tả là kinh hoàng và tuyệt vời, nó chứng minh độ dài mà các lập trình viên sẽ đi để giải quyết vấn đề với các công cụ có sẵn.
Những đánh đổi chính:
- Chi phí: Các giải pháp sáng tạo thường rẻ hơn ban đầu
- Độ tin cậy: Các hàng đợi được xây dựng chuyên dụng cung cấp đảm bảo tốt hơn
- Khả năng mở rộng: Các hàng đợi truyền thống xử lý lưu lượng cao tốt hơn
- Tính năng: Hàng đợi thư chết tích hợp, số liệu thống kê, logic thử lại
- Bảo trì: Các giải pháp tùy chỉnh đòi hỏi nhiều công việc bảo trì hơn
 |
|---|
| Một nhân vật sẵn sàng hành động đại diện cho tư duy giải quyết vấn đề sáng tạo cần thiết khi sử dụng các phương pháp không theo quy ước như GitLab làm message queue |
Bài học trong kỹ thuật sáng tạo
Những câu chuyện này làm nổi bật một nguyên tắc quan trọng trong phát triển phần mềm: đôi khi giải pháp tốt nhất không phải là giải pháp rõ ràng nhất. Trong khi các message queue được xây dựng chuyên biệt cung cấp độ tin cậy và các tính năng như dead letter queue và tự động mở rộng, các giải pháp thay thế sáng tạo có thể hoạt động hiệu quả đáng ngạc nhiên cho các trường hợp sử dụng cụ thể. Chìa khóa là hiểu sự đánh đổi giữa chi phí, độ phức tạp và yêu cầu.
Tuy nhiên, như một thành viên cộng đồng lưu ý, tự tạo message queue thường dẫn đến việc phát minh lại bánh xe một cách kém cỏi. Các dịch vụ hiện đại như Amazon SQS xử lý quản lý trạng thái phức tạp làm cho message queue đáng tin cậy, bao gồm các tính năng như message visibility timeout và cơ chế tự động thử lại.
Tham khảo: Anything can be a message queue if you use it wrongly enough