RocketMQ High-Availability Paper Admitted to ACM FSE: Replication-Free Failover

Alibaba · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Bài giới thiệu ngắn một paper (FSE 2026 Industry Track) của team Messaging của Alibaba Cloud, đồng thời quảng bá ApsaraMQ for RocketMQ. Bài không có số liệu cụ thể ngoài "phút → giây" và "hàng chục nghìn lần diễn tập"; mọi nhận định ghi "theo Alibaba". Cùng hướng với Alibaba 2025 (lease và fence trên storage chia sẻ).

Bối cảnh

• Alibaba Cloud chạy hàng nghìn cụm RocketMQ tách theo tenant. Theo bài, dịch vụ có trạng thái trên cloud muốn ba thứ vốn kéo ngược nhau: rẻ, hiệu năng ổn định, phục hồi nhanh.
• Cấu hình một replica trên cloud disk trong Kubernetes phục hồi mất vài phút khi node chết. Cách thường thấy để nhanh hơn là thêm replica dữ liệu ở tầng ứng dụng (tốn gấp đôi, thêm write amplification) hoặc làm node thành stateless (viết lại storage engine, WAL chung, object storage).

Thay đổi chính

• Giữ nguyên đường dữ liệu bình thường: vẫn một replica, file system một node, cloud block storage tự có dự phòng phía storage. Không thêm bản sao dữ liệu nghiệp vụ ở tầng RocketMQ; CommitLog và WAL không đổi; vẫn tương thích bản Apache.
• Chuyển quyền sở hữu ở tầng giao thức storage, không ở ứng dụng: Multi-Attach cho node dự bị thấy đĩa từ trước; NVMe Persistent Reservation rào quyền ghi (fencing). Kiểm tra người đang giữ, giành quyền nguyên tử, đánh dấu pha quan trọng, backoff, để quyền ghi không bị giành lại giữa chừng.
• Phục hồi là một máy trạng thái: xác nhận quyền ghi → xoá cache cũ → mount → replay journal → crash recovery → readiness check → mở traffic.
• Hỏi "primary còn ghi bền không" thay vì "node còn sống không": đọc tiến độ phiên bản lease trên đĩa chung. Cách này bắt được I/O treo (node sống, ghi đứng) và bớt phụ thuộc control plane tập trung; khi mạng bị chia, rào ghi ở storage giữ được một writer duy nhất.
• Thao tác đặc quyền (NVMe PR, cache, mount) nằm trong một Agent phía node; container nghiệp vụ không giữ quyền hệ thống. Toàn chuỗi phát hiện → đổi quyền → phục hồi → mở traffic quan sát và diễn tập lặp lại được.
• Kết quả theo Alibaba: từ vài phút xuống vài giây, throughput và latency gần bản một replica; hàng chục nghìn lần diễn tập DR, đã chạy production.

Vì sao

• Theo Alibaba, chỉ thiết kế lại đường failover chứ không thay storage engine thì CommitLog, page cache, crash recovery đã chín muồi giữ nguyên; sửa ít vào lõi Broker nên nâng phiên bản cộng đồng rẻ, và tính năng storage sau này không cần làm lại phần HA.

Bài học cho SWE

• Không phải HA nào cũng cần thêm bản sao dữ liệu: nếu tầng storage đã dự phòng, bài toán còn lại là chuyển quyền ghi an toàn (fencing) và rút ngắn chuỗi phục hồi (Failover, replica và dự phòng dữ liệu).
• Tín hiệu sức khoẻ nên đo đúng việc quan trọng (còn ghi bền không), không chỉ heartbeat; I/O treo là kiểu lỗi mà liveness bỏ sót.
• Đánh đổi chi phí: một replica + fence rẻ hơn hai replica, đổi lại phụ thuộc vào tính năng của storage cloud (Multi-Attach, NVMe PR) (Chi phí hạ tầng và build vs buy).

Liên quan

• Tách compute khỏi storage
• Cùng công ty: Alibaba 2025 · Alibaba 2026 · Alibaba 2021
• Failover, replica và dự phòng dữ liệu · Chi phí hạ tầng và build vs buy