Scaling and benchmarking a critical message bus using a new indexing strategy

Jane Street · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

Aria là framework và hệ messaging nội bộ (dựa trên state machine replication) xử lý nhiều terabyte dữ liệu mỗi ngày (2026); client subscribe để nhận luồng message trực tiếp. Luồng chia theo topic dạng cây như hệ thư mục; client subscribe một topic hoặc cả cây con.
Tip recovery: phần đuôi gần nhất của luồng ("stream tip") nằm trong ring buffer trong RAM; client tụt lại thì xin lại từ đây. Aria lọc bằng một vòng quét tuyến tính qua toàn bộ luồng: kém về thuật toán nhưng thân thiện cache CPU nên từng đủ nhanh. Khi số client recovery tăng, có server lên 100% CPU, client "rơi khỏi tip" không đuổi kịp; giải pháp tạm là thêm server.
Initial recovery: client khởi động lại thường xin mọi message từ đầu tuần, có khi tới hàng tỉ message, và client hay khởi động cùng lúc. Một sự cố: recovery thường dưới 2,5 giây mất hơn 13 phút, vì Aria đọc và lọc gấp 10 lần lượng cần gửi.

Index theo topic partition (mọi topic chung hai đoạn tiền tố, ví dụ app/codestore), vì một instance có gần một triệu topic, index từng topic không khả thi. Khi client xin message, Aria merge n-đường các index bằng min-heap để dựng lại luồng đúng thứ tự.
Viết công cụ benchmark nhiều kịch bản recovery trước; profiling thấy min-heap là nút cổ chai. Cho agent dựng năm bản heap và profile qua đêm; fast_heap_unboxed nhanh gấp 2 lần.
Block pool dùng chung (mỗi block 1.024 entry) thay vì ring buffer riêng cho mỗi index: message nhỏ nhất 32 byte, nếu cấp theo trường hợp xấu nhất thì mỗi index tới 2 GB. Block được thu hồi khi mọi message trong nó đã rời ring buffer.
Chia subtree store thích ứng: trên đĩa, heuristic cũ tách store theo ba đoạn đầu của topic, nên một topic 2,72 GB nằm chung store với topic 10 MB. Thuật toán mới (gom cụm tham lam + binary search theo khối lượng message từng topic) cho topic lớn store riêng, gộp các topic nhỏ. Người dùng không còn phải hiểu chi tiết nội bộ khi đặt tên topic.
Kiểm chứng bằng expect test, property-based test (chia cây ngẫu nhiên, nội dung và thứ tự message không đổi), chạy trong Antithesis, và một "bầy" agent soát code.

Kết quả (2026): index tip đã lên production; trong staging giảm 30% CPU ở một số kịch bản thật, latency toàn client giảm rõ; server chưa có index vẫn có tail latency vài giây. Chia store thích ứng đang ở staging.

Quét tuyến tính thân thiện cache là lựa chọn đúng lúc đầu, tới khi số người đọc nhân lên.
Chọn độ hạt của index theo số lượng thực (partition thay vì topic) và cấp phát bộ nhớ theo nhu cầu thật (block pool) thay vì theo trường hợp xấu nhất.
Thử nghiệm giờ rẻ: dựng nhiều phương án và đo trên dữ liệu thật thay vì chọn theo trực giác.
Hệ đã persist thì phải test tính đúng (mất hay đảo message) nặng tay như test hiệu năng.