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 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
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ồ.
1. 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.
2. 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.
3. 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 replica để Paxos hoạt động. Chi phí storage và resource network 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 NewSQL
• Google 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 compress dữ liệu và tối ưu cho các đợt Spike nhờ kiến trúc LSM-Tree.
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
1. 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 OBProxy
• OBProxy 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.
1. LSM-Tree Storage Engine
LSM-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.
2. 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.
3. 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). Phần lớn khoảng > 95% transactions tại Alipay chạy local, chỉ 5% cần xử lý phân tán.
4. Dynamic Load Balancing
Peak Day traffic thường không đều: iPhone thì quá tải, giấy vệ sinh ít người mua. RootService sẽ tự động cân bằng lại.
Ví dụ 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: 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.
5.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 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.
6.Compression - Tiết kiệm 80% Storage
Vớ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.
7.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.
8.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à thiết kế đúng. Alipay chấp nhận trade-offs (dùng 5 replicas để đổi lấy an toàn, dùng deep compress để đổ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ứ khá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 #Alipay
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
