The LMAX Architecture

Nguồn thứ cấp: bài của Martin Fowler, viết theo lời kể của đội LMAX (Martin Thompson, Dave Farley). Nhận định ghi "theo LMAX qua lời kể của Fowler".

LMAX · 2011 · 2. Tăng trưởng · Độ khó: Khó — bài gốc

Bối cảnh

• LMAX là sàn giao dịch phái sinh cho nhà đầu tư cá nhân (công ty mẹ là Betfair). Sàn cần latency thấp vì mỗi giao dịch làm thay đổi thị trường cho giao dịch sau; bán lẻ thì thêm nhiều người dùng. Phần lớn hoạt động đến từ market maker; lúc biến động, một công cụ có thể nhận hàng trăm cập nhật mỗi giây, có những đợt dồn hàng trăm giao dịch trong một micro giây.
• Loại bỏ cách truyền thống (nhiều session phối hợp qua một DB giao dịch): theo kinh nghiệm Betfair, giữ hiệu năng cho một DB cực nóng đã đòi nhiều "hành động trái tự nhiên", không đủ cho latency của sàn.
• Thử concurrency tường minh trước: prototype sàn theo actor model/SEDA. Đo hiệu năng thấy CPU tốn nhiều thời gian quản lý hàng đợi hơn chạy logic; hàng đợi là nút cổ chai.

Thay đổi chính

• Business Logic Processor (BLP): toàn bộ logic nghiệp vụ (mọi giao dịch, mọi khách, mọi thị trường) chạy trên một thread, hoàn toàn trong RAM, không DB. Benchmark: 6 triệu lệnh/giây trên một server Nehalem hai socket. Không có ORM, không transaction.
• Event sourcing cho độ bền: trạng thái của BLP suy ra hoàn toàn từ chuỗi event đầu vào được ghi bền. Snapshot mỗi đêm; khởi động lại đầy đủ (JVM + snapshot + replay journal một ngày) dưới một phút. Chạy ba BLP cùng xử lý mọi event (hai ở DC chính, một ở DR), chỉ một bản có output được dùng; chuyển sang bản khác trong vài micro giây; khởi động lại mỗi đêm không downtime.
• Event sourcing còn cho phép copy chuỗi event về máy dev để replay khi có hành vi lạ, và dựng bản sao domain model riêng cho tính toán rủi ro nặng (ví dụ top 20 khách theo rủi ro) mà không chạm luồng xử lý lệnh.
• Tune hiệu năng: tuần tự + trong RAM đạt khoảng 10K TPS; code gọn, hàm nhỏ (giúp HotSpot và cache) lên khoảng 100K; collection tự viết thân thiện cache và GC (ví dụ map khoá long trên mảng) và test hiệu năng viết trước mới lên thêm một bậc.
• Mô hình lập trình: không gọi dịch vụ ngoài trong logic; kết thúc bằng một event đầu ra và chờ event đầu vào phản hồi. Không có rollback tự động, nên kiểm hợp lệ toàn bộ input trước khi sửa trạng thái.
• Disruptor quanh BLP: phía vào phải unmarshal, journal (ghi tuần tự ra filesystem, "disk is the new tape"), replicate (IP multicast; leader định thứ tự tất định cho follower). Ba việc độc lập nên chạy song song. Disruptor là một ring buffer (20 triệu slot đầu vào, 4 triệu mỗi đầu ra, kích thước luỹ thừa 2), mỗi producer/consumer có bộ đếm sequence riêng và đọc bộ đếm của nhau, không cần lock; consumer tụt lại đọc theo lô để bắt kịp. Mã nguồn mở.

Vì sao

• Single-writer principle và "mechanical sympathy": truy cập RAM chậm so với cache; hàng đợi buộc nhiều core cùng ghi một cấu trúc, cần lock, dễ chuyển ngữ cảnh vào kernel và mất cache. Thiết kế tốt nhất cho cache là mỗi vị trí bộ nhớ chỉ một core ghi (kể cả tách bộ đếm sang cache line khác nhau).
• Theo LMAX, viết test hiệu năng có ý nghĩa thường khó hơn viết code production; phải test với component rỗng để chắc bộ test đủ nhanh.
• Theo Fowler, kiến trúc hợp với miền "kết nối", nơi mỗi giao dịch ảnh hưởng giao dịch sau; giao dịch độc lập thì xử lý song song hấp dẫn hơn.

Bài học cho SWE

• Trước khi song song hoá, thử xem một thread được giải phóng khỏi chi phí phối hợp chạy nhanh tới đâu.
• Working set vừa RAM + event sourcing giải quyết độ bền mà không cần DB trên đường nóng; replay event cũng là công cụ debug.
• Đo, đừng suy đoán: actor model bị loại nhờ prototype và benchmark chứ không nhờ lý thuyết.

Liên quan

• Jane Street 2026 (Aria: cũng log + state machine replication) · Jane Street 2015 · Hudson River Trading 2022
• Hệ thống độ trễ thấp (low latency) · Event-driven, message queue và Kafka · Failover, replica và dự phòng dữ liệu