544.000 giao dịch/giây – Alibaba sập?🔥🔥🔥

Đêm Single Day 11.11 – 23:59:50, Tại HQ của Ant Group và Alibaba tại Hangzhou, hàng trăm engineer dán mắt vào màn hình dashboard. Đây là tiền thật, hàng tỷ USD của Alibaba đang được quyết định trong vài chục phút tới.

00:00:00:Festival bắt đầu. Cả tỷ người cùng lúc nhấn nút thanh toán. Traffic nhảy vọt từ 50k lên tận 544k TPS chỉ trong vòng 3 giây. Có sự cố là Alibaba mất trắng cả tỷ đô. Đỉnh điểm con số 544.000 giao dịch mỗi giây.

00:01:08: – 1 tỷ USD đầu tiên trong 68 giây- 10 tỷ USD sau chưa đầy 30p.

Kết thúc ngày hôm đó, con số thống kê kỷ lục:

• 544k TPS peak (kỷ lục thế giới tới thời điểm hiện tại)

• 1.3 tỷ đơn hàng

• 34 tỷ USD revenue- zero loss, zero downtime

Để anh em dễ hình dung:

Visa lúc căng nhất cũng chỉ gánh được tầm 65k TPS, Paypal là 10k TPS.

Discloser:

100% thông tin được trích dẫn từ nhiều nguồn public từ Alibaba và OceanBase, và một số bài viết trên Baidu,…

Các ví dụ là minh hoạ dựa trên mechanism và official document dùng để dễ hình dung, không khẳng định là hệ thống thực tế được config như vậy. và nhiều con số là ước tính dựa trên official document và src code Oceanbase

Oceanbase official Github: https://github.com/oceanbase/oceanbase

Phần lớn tài liệu bằng tiếng Trung nên tôi tổng hợp lại để anh em dễ hiểu hơn:

Vì sao Alipay không dùng Oracle, MySQL hay Postgres?

Vấn đề của Peak Day không nằm ở thiếu server, mà ở Database. Hệ thống thanh toán cần: Strong consistency, RPO ≈ 0, RTO cực thấp và chịu được cú spike write khổng lồ.

• Oracle: Rất mạnh ở single instance và RAC, nhưng khi TPS lên hàng trăm nghìn, shared storage và global lock trở thành bottleneck.

• MySQL/PostgreSQL: Có thể shard, nhưng transaction liên shard (cross-shard) phải xử lý ở tầng app hoặc dùng 2PC, cực khó giữ ổn định khi traffic nhảy vọt 10 lần trong vài giây. Sharding hàng vạn node thủ công thực sự là cơn ác mộng vận hành.

• NoSQL (MongoDB/Cassandra): Scale tốt nhưng thiên về eventual consistency; dùng cho thanh toán là rủi ro cực lớn.

Vì vậy, Alipay xây OceanBase ngay từ đầu cho Distributed Transaction.

Năm 2020 lập kỷ lục TPC-C 707M tpmC, đánh bại hoàn toàn các ông lớn Database truyền thống.

2025, OceanBase đã bị đánh bại bởi PolarDB với 2.05B tpmC

Đánh đổi để đạt 544k TPS Không có bữa trưa miễn phí, để gánh được con số này, Alipay phải chấp nhận:

• Gánh nặng hạ tầng: Cần ít nhất 3 đến 5 bản sao để Paxos hoạt động. Chi phí lưu trữ và tài nguyên mạng tốn gấp 3 đến 5 lần so với DB truyền thống.

• Độ phức tạp vận hành: Debug hệ thống phân tán là ác mộng. Việc xác định lỗi do network, node Leader hay Follower đòi hỏi hệ thống giám sát cực kỳ tinh vi.

So sánh với các ông lớn NewSQLGoogle Spanner:

Ông tổ của NewSQL, dùng đồng hồ nguyên tử để quản lý thời gian, mạnh về nhất quán toàn cầu trên hạ tầng Google Cloud.

TiDB: Dùng cơ chế Raft, thế mạnh là mã nguồn mở, dễ triển khai và tương thích cực tốt với hệ sinh thái MySQL.

OceanBase: Tập trung vào khả năng nén dữ liệu sâu và tối ưu cho các đợt Spike khổng lồ nhờ kiến trúc LSM-Tree tùy biến.

Góc thảo luận:

Alipay dám bỏ sạch Oracle và MySQL để dùng 100% OceanBase, tôi lại thắc mắc:

Tại sao các fintech và Bank lớn ở VN vẫn đang dùng hàng triệu đô mỗi năm cho Oracle vì sợ rủi ro?

Thực sự là hàng nội địa Trung chưa đủ tuổi so với các ông lớn phương Tây?

Anh em làm ở Momo, Shopee, ZaloPay, Tiki hay các Bank lớn (Techcom, VCB…) vào cho tôi xin cái view:

Hệ thống của các bác đang dùng giải pháp gì?Con số Peak TPS khủng nhất các bác từng gánh là bao nhiêu và có design gì hay chia sẻ cho anh em biết nhé?

—————————————————————–

Rồi giờ tới phần kỹ thuật

Kiến trúc Tổng thể

Mô tả đơn giản:

• OceanBase là distributed database với 3 thành phần chính:
• OBProxy: Định tuyến request đến đúng server
• OBServer: Xử lý SQL và lưu trữ data
• RootService: Quản lý metadata và load balancing

Ví dụ cụ thể: Khi user Li Wei mua iPhone lúc 00:00:01:

• Li Wei click Thanh toán → Request gửi đến OBProxyOBProxy tính toán: hash(user_id=293847) % 1000 = 847 → Partition 847 nằm ở OBServer Node 47
• OBProxy gửi request đến Node 47
• Node 47 xử lý: Kiểm tra balance, kiểm tra tồn kho, ghi 3 bảng (orders, payments, account_balance)
• Tất cả ở partition 847 (cùng node) nên không cần network
• Commit transaction trong 10ms và user nhận thông báo thành công.

LSM-Tree Storage EngineLSM-Tree tối ưu cho write-heavy workload bằng cách:

• Write vào memory (MemTable): Cực nhanh
• Định kỳ flush xuống disk thành files nhỏ (Mini SSTable)
• Background merge các files nhỏ thành file lớn (Compaction)

Ví dụ cụ thể khi User A thanh toán $100:

Bước 1: Write vào MemTable (0.1ms). Ghi vào RAM (B-Tree + Hash Index).

Bước 2: MemTable đầy → Freeze MemTable, tạo Active MemTable mới và background thread dump dữ liệu xuống disk.

Bước 3: Tạo Mini SSTable (2 giây sau). File 64MB đã được sorted và compressed trên disk.

Bước 4: Minor Compaction (1 giờ sau). Merge 50 Mini SSTables thành 1 Minor SSTable (2GB) và xóa duplicate keys.

Bước 5: Major Compaction (3am hàng ngày). Merge tất cả Minor SSTables với old Major SSTable. Chỉ rewrite những phần đã thay đổi (Incremental) giúp tiết kiệm 80% I/O.

Lợi ích: Write nhanh vì chỉ ghi vào RAM, read tối ưu nhờ cache và bloom filters, compaction chạy background không ảnh hưởng traffic.

Paxos Replication – Đảm bảo Data Không Mất

Mô tả đơn giản: Mỗi partition có 5 replicas ở 5 servers khác nhau: 1 Leader (nhận writes) và 4 Followers (backup data). Write chỉ commit khi ít nhất 3/5 replicas xác nhận (Majority).

Ví dụ cụ thể khi User A chuyển $100:

Bước 1: Leader (Node 47 – Beijing) nhận request, write vào MemTable và ghi Redo Log.

Bước 2: Leader gửi log song song đến 4 Followers ở các node khác (Beijing, Hangzhou, Shenzhen).

Bước 3: Chỉ cần 3/5 node xác nhận (thường mất 5ms) là đủ quorum để COMMIT và báo thành công cho user.

Bước 4: Các node chậm hơn vẫn apply log sau đó.

Kịch bản Leader chết:

Nếu Leader chết ngay sau khi gửi logs, các Followers vẫn nhận và apply bình thường.

Sau 8ms, Followers phát hiện Leader timeout.

Trong 30s, Paxos bầu Leader mới có full data. Transaction của user không bao giờ mất. RPO = 0, RTO < 30s.

Partitioning – Tránh Distributed Transactions

Vấn đề: Nếu 1 transaction cần update nhiều tables trên nhiều servers khác nhau sẽ rất chậm do network overhead.

Giải pháp: Đặt tất cả data của cùng 1 user lên cùng 1 server (Partition Colocation).

Ví dụ cụ thể: User 293847 mua hàng, hệ thống tính toán ra Partition 847. OBServer Node 47 sẽ chứa sẵn tất cả partition 847 của các bảng: orders, payments và account_balance. Giao dịch diễn ra hoàn toàn nội bộ trong 1 server (Local Transaction) chỉ mất 2ms.

So sánh: Nếu dùng 2PC (Two-Phase Commit) qua network giữa các server, latency sẽ là 15-30ms (chậm hơn gấp 7-15 lần).

Thống kê: 95% transactions tại Alipay chạy local, chỉ 5% cần xử lý phân tán.

Dynamic Load Balancing

Peak Day traffic thường không đều:

iPhone hot thì quá tải, giấy vệ sinh rảnh rỗi. RootService sẽ tự động cân bằng lại.

Ví dụ cụ thể lúc 00:00 Flash Sale:

Bước 1: RootService phát hiện Node 47 đang gánh partition Apple Store với CPU 95%.

Bước 2: Hệ thống phân tích thấy 80% traffic tập trung vào đúng một merchant_id.

Bước 3: Tách partition (Split). Chia làm 2 phần: phần bình thường và phần Apple Store.

Bước 4: Di dời (Migrate) phần Apple Store sang Node 89 đang rảnh. Quá trình mất 30 giây, zero downtime.

Kết quả: Cả 2 node đều chạy ổn định ở mức CPU an toàn.

HTAP – Xử lý OLTP và OLAP Đồng thời

Thay vì dùng 2 database riêng (MySQL cho giao dịch + Snowflake cho phân tích), OceanBase làm cả hai.

OLTP: Merchant xem chi tiết 1 đơn hàng (Point query) mất 0.05ms nhờ Row Cache.

OLAP: Merchant xem dashboard tổng doanh thu vùng miền trong 1 giờ qua. Hệ thống scan hàng chục triệu dòng bằng column-oriented storage, chỉ đọc các cột cần thiết, xử lý 1000 dòng cùng lúc (Vector execution).

Kết quả trả về trong 2 giây cho 10 triệu dòng.

Lợi ích: Không cần quy trình ETL phức tạp, dữ liệu phân tích là real-time và tiết kiệm chi phí hệ thống.

Compression – Tiết kiệm 80% StorageVới hàng trăm petabytes, Alipay dùng các kỹ thuật nén sâu:

Dictionary Encoding: Chuyển các chữ như ‘success’, ‘pending’ thành số 0, 1. Tiết kiệm 97%.

Delta Encoding: Chỉ lưu phần chênh lệch của timestamp. Tiết kiệm 98%.

Run-Length Encoding: Khi 500k user mua cùng 1 sản phẩm, thay vì lưu mã sản phẩm 500k lần, chỉ lưu (mã_sp, 500.000). Tiết kiệm gần như tuyệt đối.

Kết quả: Từ 32.5TB dữ liệu thô sau khi nén chỉ còn 6.5TB, tiết kiệm hàng triệu đô tiền hạ tầng mỗi năm.

Cache Architecture – Sub-millisecond Latency

Hệ thống dùng 2 tầng cache:Row Cache: Cho các truy vấn tìm đích danh (tăng tốc 40 lần).

Block Cache: Cho các truy vấn quét dữ liệu (tăng tốc 2.5 lần).

Đặc biệt có cơ chế Cache Warming: Sau khi gộp dữ liệu (Compaction), hệ thống chủ động nạp trước 20% dữ liệu hot vào RAM trong 10 giây trước khi mở lại traffic. Điều này đảm bảo hệ thống không bị chậm (degradation) khi vừa khởi động lại cache.High Availability – RPO=0, RTO < 30s

Kịch bản: Toàn bộ Datacenter tại Bắc Kinh mất điện (2/5 replicas down).

Sau 2 giây: Các node ở Hàng Châu và Thâm Quyến phát hiện. Vẫn còn 3/5 node, đủ quorum hoạt động.

Sau 10 giây: Bầu leader mới tại Hàng Châu.Sau 20 giây: Cập nhật bảng định tuyến, hệ thống hoạt động bình thường. Downtime chỉ 20 giây, không mất bất kỳ một dòng dữ liệu nào (Data loss: ZERO).

Quan trọng: Scale không chỉ là thêm servers mà cần kiến trúc đúng. Alipay chấp nhận các đánh đổi thông minh (dùng 5 replicas để đổi lấy an toàn, dùng nén sâu để đổi lấy dung lượng).

Lưu ý: Đây chỉ là phần nhỏ. Thực tế Alipay còn service mesh, network protocol, MQ và rất nhiều thứ bảo mật khác k share được. Tôi giải thích ngắn gọn nên anh em có gì chưa rõ cứ góp ý nhé!#systemdesign #OceanBase

—————————————————-

Giao dịch mỗi giây (Transactions Per Second – TPS): Thước đo hiệu suất của mạng lưới (như blockchain), chỉ số lượng giao dịch hoàn thành trong một giây. TPS cao = hiệu quả cao hơn. 

RPO (Recovery Point Objective – Mục tiêu điểm phục hồi) là lượng dữ liệu tối đa mà một doanh nghiệp có thể chấp nhận mất đi trong trường hợp sự cố, được tính bằng khoảng thời gian từ lúc xảy ra sự cố đến thời điểm sao lưu gần nhấ

RTO (Recovery Time Objective – Mục tiêu Thời gian Phục hồi) là khoảng thời gian tối đa cho phép để một hệ thống, ứng dụng hoặc dịch vụ hoạt động trở lại sau sự cố/thảm họa, để tránh tổn thất kinh doanh không thể chấp nhận được