Queen MQ ra mắt message broker hỗ trợ ACID với hàng đợi riêng cho từng thực thể và tính nhất quán cao

Người dùng GitHub queen-mq đã phát hành Queen, một message broker mã nguồn mở được thiết kế để cung cấp các đảm bảo ACID (Atomicity - Tính nguyên tử, Consistency - Tính nhất quán, Isolation - Tính cô lập, Durability - Tính bền vững) cho truyền thông phân tán. Được công bố vào ngày 10 tháng 11 năm 2026, hệ thống dựa trên Rust này nhằm đơn giản hóa kiến trúc backend bằng cách coi mỗi khách hàng, đơn hàng hoặc cuộc hội thoại là một hàng đợi riêng biệt, đảm bảo rằng các thay đổi trạng thái và xác nhận tin nhắn được cam kết cùng nhau như một giao dịch duy nhất.

Chuyện gì đã xảy ra

Bản phát hành giới thiệu một broker thoát khỏi các mô hình nhất quán cuối cùng (eventual consistency) thường thấy trong các hệ thống có thông lượng cao. Thay vì dựa vào các cơ chế riêng biệt để khóa, lên lịch hoặc thử lại các tin nhắn thất bại, Queen tích hợp trực tiếp các khả năng này vào lõi giao dịch của nó. Tài liệu dự án nhấn mạnh rằng mọi bước trong quy trình làm việc, bao gồm cả việc xác nhận, gửi tin nhắn tiếp theo, cập nhật trạng thái và cài đặt bộ đếm thời gian, đều được cam kết như một đơn vị nguyên tử. Cách tiếp cận này loại bỏ sự phức tạp trong việc quản lý các khóa Redis, cron jobs hoặc các bảng thử lại chuyên dụng.

Queen hỗ trợ nhiều ngôn ngữ lập trình, bao gồm JavaScript, Python, Go và Rust, đồng thời cung cấp các tính năng như xử lý luồng với cửa sổ tumbling, sliding và session. Nó cũng bao gồm hỗ trợ cho các nhóm người tiêu dùng hợp nhất (conflating consumer groups), chỉ cung cấp tin nhắn mới nhất cho các phân vùng mà chỉ giá trị gần nhất là quan trọng. Đối với các mẫu request-reply, broker cung cấp các hàng đợi tạm thời trong bộ nhớ, nhanh nhưng cố ý bị mất khi gặp sự cố, phân biệt chúng với các log bền vững. Hệ thống được xây dựng để xử lý quản lý trạng thái phức tạp, cung cấp lưu trữ key-value, khóa phân tán và bộ đếm thời gian theo lịch trình trong cùng ranh giới giao dịch với quá trình xử lý tin nhắn.

Chi tiết chính

• Giao dịch ACID: Mọi thao tác tin nhắn, bao gồm acks, thay đổi trạng thái và bộ đếm thời gian, được cam kết nguyên tử, đảm bảo không có cập nhật một phần nào xảy ra.
• Hiệu suất Benchmark cao: Trên ba nút GCP với ổ cứng NVMe cục bộ, Queen đạt 3 triệu tin nhắn mỗi giây với độ trễ p99 từ 15-25 ms trên tối đa 10 triệu phân vùng.
• Khôi phục nhanh chóng: Một nút tham gia lại cụm sau năm phút ngừng hoạt động chỉ cần đồng bộ delta 1,1 GB trong 28 giây, nhanh hơn đáng kể so với các phiên bản trước.
• Không phụ thuộc ngôn ngữ: Hỗ trợ client cho JavaScript, Python, Go và Rust, và cho phép các producer và consumer Kafka không thay đổi kết nối qua cổng tương thích Kafka.
• Lưu trữ tích hợp: Broker có thể ghi trực tiếp các hàng đợi vào bảng PostgreSQL hoặc bucket S3 ở định dạng JSONL hoặc Parquet mà không cần các quy trình bên ngoài.
• Độ tin cậy đã được chứng minh: Phần mềm đã vượt qua 226 bài kiểm tra Jepsen trên phiên bản 2.7, xác nhận rằng không có tin nhắn đã xác nhận nào bị mất và không có lease nào được giữ hai lần.

Bối cảnh

Message brokers là những thành phần thiết yếu trong kiến trúc phần mềm hiện đại, đóng vai trò trung gian cho phép các phần khác nhau của hệ thống giao tiếp bất đồng bộ. Các broker truyền thống như Kafka hoặc RabbitMQ thường ưu tiên thông lượng và tính sẵn sàng, đôi khi phải đánh đổi bằng tính nhất quán tức thì. Các nhà phát triển thường phải xây dựng thêm cơ sở hạ tầng, chẳng hạn như hàng đợi thử lại dựa trên cơ sở dữ liệu hoặc trình quản lý khóa phân tán, để đảm bảo logic nghiệp vụ vẫn nhất quán khi tin nhắn thất bại hoặc đến sai thứ tự.

Các thuộc tính ACID, thường liên quan đến cơ sở dữ liệu quan hệ, đảm bảo rằng các giao dịch được xử lý một cách đáng tin cậy. Tính nguyên tử nghĩa là tất cả các phần của một giao dịch thành công hoặc thất bại cùng nhau. Tính nhất quán đảm bảo cơ sở dữ liệu vẫn ở trạng thái hợp lệ. Tính cô lập ngăn chặn các giao dịch đồng thời can thiệp lẫn nhau, và Tính bền vững đảm bảo dữ liệu đã cam kết tồn tại sau các sự cố hệ thống. Bằng cách mang những đảm bảo này vào việc môi giới tin nhắn, Queen cố gắng giảm bớt gánh nặng vận hành cho các nhóm kỹ thuật trước đây phải ghép nối nhiều công cụ để đạt được độ tin cậy tương tự.

Tại sao điều này quan trọng

Đối với các đội ngũ chạy phần mềm riêng, lời hứa về tuân thủ ACID trong một message broker có thể giảm đáng kể độ phức tạp của kiến trúc. Hiện tại, nhiều ứng dụng tự host yêu cầu sự kết hợp giữa một hàng đợi tin nhắn, một cơ sở dữ liệu quan hệ cho trạng thái và một kho lưu trữ riêng cho các khóa phân tán. Quản lý tính nhất quán giữa ba hệ thống này là một nguồn gốc phổ biến của lỗi và chi phí vận hành. Nếu Queen đáp ứng được các tuyên bố của mình, các nhà phát triển có thể thay thế bộ ba này bằng một thành phần duy nhất, giúp đơn giản hóa việc triển khai, giám sát và gỡ lỗi.

Các benchmark hiệu suất cho thấy sự đơn giản này không đi kèm với cái giá quá đắt về thông lượng. Xử lý 3 triệu tin nhắn mỗi giây với độ trễ thấp là cạnh tranh với các tên tuổi lớn như Redpanda và Pulsar, đặc biệt là ở số lượng phân vùng cao. Đối với các công ty vừa và nhỏ đang mở rộng cơ sở hạ tầng, khả năng xóa sạch 100 GB độ trễ trong 32 giây và khôi phục các nút nhanh chóng có thể tạo nên sự khác biệt giữa một trục trặc nhỏ và một sự cố kéo dài trong giờ cao điểm.

Tuy nhiên, việc áp dụng một thành phần cơ sở hạ tầng lõi mới luôn đi kèm rủi ro. Mặc dù các bài kiểm tra Jepsen cung cấp sự tự tin vào mô hình nhất quán của nó, các trường hợp sử dụng thực tế trong sản xuất rất đa dạng. Các đội ngũ phải đánh giá xem các tính năng cụ thể, chẳng hạn như hàng đợi cho từng thực thể và xuất dữ liệu sang S3 tích hợp, có phù hợp với nhu cầu lưu giữ và xử lý dữ liệu của họ hay không. Giấy phép Apache-2.0 cho phép sử dụng thương mại và sửa đổi, điều này hấp dẫn đối với các công ty muốn tránh khóa vendor lock-in trong khi vẫn duy trì quyền kiểm soát mã nguồn của họ.

Bạn có thể làm gì

• Xem xét tài liệu: Tải xuống PDF "The little book of QueenMQ" để hiểu kiến trúc, mô hình lưu trữ và các đảm bảo API trước khi cân nhắc áp dụng.
• Chạy các bài kiểm tra benchmark: Nhân bản các benchmark được cung cấp bằng phần cứng hoặc môi trường đám mây của bạn để xác minh xem thông lượng và độ trễ được tuyên bố có đáp ứng yêu cầu ứng dụng của bạn hay không.
• Đánh giá lộ trình di chuyển: Nếu bạn hiện đang sử dụng Kafka, hãy thử nghiệm cổng tương thích Kafka để xem liệu các producer và consumer hiện có thể kết nối mà không cần thay đổi mã hay không.
• Đánh giá nhu cầu quản lý trạng thái: Xác định xem logic ứng dụng của bạn có hưởng lợi từ việc tích hợp trực tiếp KV storage, khóa và bộ đếm thời gian vào luồng giao dịch tin nhắn hay không.
• Kiểm tra các kịch bản lỗi: Sử dụng tính năng cụm dự phòng và cơ chế khôi phục nút trong môi trường staging để xác thực thời gian tham gia lại 28 giây và tính toàn vẹn dữ liệu.
• Kiểm tra hỗ trợ ngôn ngữ: Đảm bảo rằng các thư viện client cho các ngôn ngữ phát triển chính của bạn (JS, Python, Go, Rust) đủ trưởng thành cho các tiêu chuẩn sản xuất của bạn.