Alipay Double 11: Giải Thích Kiến Trúc 583,000 TPS

Vào lúc nửa đêm ngày 11 tháng 11, khoảng 1,5 tỷ người trên khắp châu Á đồng loạt mở một ứng dụng duy nhất và bắt đầu chạm vào “Mua ngay”. Trong 60 giây đầu tiên, Alipay xử lý nhiều giao dịch hơn một ngân hàng lớn ở phương Tây xử lý trong cả một ngày. Đỉnh điểm của Ngày Lễ Độc Thân (Singles’ Day) năm 2023 — 583.000 giao dịch thanh toán mỗi giây (TPS) — không chỉ là một tiêu đề báo. Đó là sản phẩm của mười bốn năm tiến hóa kiến trúc đã định nghĩa lại ý nghĩa của từ “sẵn sàng cho production” đối với một nền tảng tài chính.

Bài viết này đúc kết những quyết định kiến trúc then chốt đằng sau con số đó. Nếu bạn muốn đi sâu hơn vào từng tầng, loạt bài Toàn Tập Kiến Trúc Alipay Double 11 của chúng tôi sẽ đề cập chi tiết đến từng thành phần qua chín chương.

Double 11 Là Gì Và Tại Sao Đây Là Bài Toán Kỹ Thuật Ở Quy Mô Hành Tinh

Double 11 (11.11, Ngày Lễ Độc Thân) là một lễ hội mua sắm thường niên của Trung Quốc đã phát triển thành sự kiện thương mại điện tử lớn nhất thế giới. Năm 2023, hệ sinh thái Alibaba đã xử lý hơn 1 nghìn tỷ NDT (≈138 tỷ USD) tổng giá trị hàng hóa (GMV) trong vòng 24 giờ.

Từ góc độ kỹ thuật, thách thức không nằm ở mức trung bình hàng ngày. Alipay xử lý hàng trăm triệu khoản thanh toán thường lệ mỗi ngày. Thách thức nằm ở hình dạng của lưu lượng truy cập (traffic shape): một đợt tăng vọt gần như thẳng đứng vào lúc nửa đêm, một đợt tăng vọt thứ hai vào khoảng 8 giờ tối, và sự im lặng tương đối trong phần lớn thời gian còn lại của ngày.

Sự bất đối xứng này buộc Alipay phải thiết kế một hệ thống có thể:

• Xử lý gấp 100 lần lưu lượng đỉnh thông thường trong các khung giờ 30 phút liên tục
• Đảm bảo ngữ nghĩa thanh toán đúng một lần (exactly-once) dưới mức độ đồng thời cực cao
• Duy trì độ trễ P99 dưới 100ms trong khi hệ thống đang ở mức tải tối đa
• Tự động phục hồi sau bất kỳ sự cố nào của một khu vực hoặc trung tâm dữ liệu (datacenter) duy nhất mà không bị mất bất kỳ giao dịch nào

Giải quyết đồng thời bốn yêu cầu này — ở quy mô hành tinh — chính là bài toán kỹ thuật cần phải giải quyết.

4 Giai Đoạn Trong Hành Trình Mở Rộng Của Alipay (2009 → 2023)

Kiến trúc của Alipay không bắt đầu ở mức 583.000 TPS. Nó đã tiến hóa qua các giai đoạn rõ rệt, mỗi giai đoạn được thúc đẩy bởi việc chạm đến giới hạn cứng của phương pháp trước đó.

Giai Đoạn 1 (2009–2013): Khối Nguyên Khối (Monolith)

Hệ thống ban đầu của Alipay là một khối nguyên khối (monolith) Java được triển khai trên cơ sở dữ liệu Oracle. Nó hoạt động tốt cho đến khi sự kiện Double 11 đầu tiên vào năm 2009 làm sập toàn bộ trang web chỉ trong vòng vài phút. Lưu lượng của sự kiện đơn giản là lớn hơn vài bậc độ lớn so với những gì phần cứng có thể hấp thụ.

Giai Đoạn 2 (2013–2016): Microservices + Sharding MySQL

Phản ứng sau đó là chia nhỏ khối nguyên khối thành hàng trăm dịch vụ (microservices) và phân mảnh (shard) cơ sở dữ liệu MySQL theo chiều ngang. Điều này mang lại không gian mở rộng trong vài năm, nhưng Double 11 năm 2016 đã phơi bày điểm nghẽn tiếp theo: MySQL không thể cung cấp các đảm bảo tính nhất quán mạnh mẽ cần thiết cho các giao dịch tài chính ở quy mô này trong khi vẫn duy trì tính khả dụng khi xảy ra phân vùng mạng.

Hãy đọc bài Phân Tích Chuyên Sâu Kiến Trúc Giai Đoạn 2 của chúng tôi để biết toàn bộ câu chuyện về cách quá trình sharding MySQL chạm đến giới hạn của nó.

Giai Đoạn 3 (2016–2020): OceanBase + LDC + SOFAStack

Sự thay đổi kiến trúc mang tính quyết định đã giới thiệu đồng thời ba thành phần mới:

• OceanBase: Một cơ sở dữ liệu quan hệ phân tán được xây dựng nội bộ tại Ant Group để thay thế Oracle và MySQL
• Đơn vị hóa LDC (Local Deployment Center): Một mô hình phân vùng logic cho lưu lượng, dịch vụ và dữ liệu, cho phép cách ly ở cấp độ trung tâm dữ liệu
• SOFAStack: Một framework microservices toàn diện được xây dựng trên nền tảng Dubbo, bao gồm service mesh, circuit breakers, và distributed tracing

Giai Đoạn 4 (2020–Nay): Cloud-Native + Đơn vị hóa Toàn cầu

Kiến trúc hiện tại mở rộng các nguyên tắc của LDC sang triển khai toàn cầu đa khu vực và chạy trên hạ tầng đám mây riêng của Ant Group với các cụm Kubernetes tùy chỉnh. OceanBase 4.x đã giới thiệu một storage engine có cấu trúc log mới và các dịch vụ trọng tài độc lập đã cải thiện đáng kể thông lượng cho các khối lượng công việc tài chính có nhiều thao tác ghi.

Đơn Vị Hóa LDC (Local Deployment Center): Cách Ly Lưu Lượng Không Gây Mất Dữ Liệu

Đơn vị hóa LDC là phần đặc biệt nhất và ít được hiểu rõ nhất trong kiến trúc của Alipay. Đây là lý do chính khiến Alipay có thể chịu đựng các sự cố trung tâm dữ liệu hoàn toàn mà không mất một giao dịch nào.

Khái Niệm Cốt Lõi

Một kiến trúc tính khả dụng cao truyền thống sẽ định tuyến tất cả các yêu cầu đến một trung tâm dữ liệu chính và chuyển đổi dự phòng (failover) sang trung tâm dự phòng khi trung tâm chính gặp sự cố. Vấn đề là: quá trình failover đòi hỏi phải phát hiện sự cố, bầu chọn trung tâm chính mới và định tuyến lại lưu lượng — một quá trình mất từ vài giây đến vài phút. Trong các hệ thống tài chính, đây là những giây phút của các giao dịch bị mất.

LDC áp dụng một phương pháp tiếp cận cơ bản khác. Thay vì chính/dự phòng, nó phân vùng không gian người dùng thành các đơn vị (units) logic. Mỗi unit là một phần tự chứa của hệ thống bao gồm:

• Một tập hợp con người dùng (được phân vùng theo hash của User ID)
• Các dịch vụ cần thiết để xử lý giao dịch của những người dùng đó
• Một shard (mảnh) của cơ sở dữ liệu chứa dữ liệu tài khoản của những người dùng đó

graph TD
    A[Lưu Lượng Người Dùng] --> B[Bộ Cân Bằng Tải Toàn Cầu]
    B -->|User ID % 100 < 20| C[Unit A - Khu Vực Đông]
    B -->|User ID % 100 < 40| D[Unit B - Khu Vực Đông]
    B -->|User ID % 100 < 60| E[Unit C - Khu Vực Tây]
    B -->|User ID % 100 < 80| F[Unit D - Khu Vực Tây]
    B -->|User ID % 100 >= 80| G[Vùng Cốt Lõi - Đa Khu Vực]
    
    C --> C1[(OceanBase Shard A)]
    D --> D1[(OceanBase Shard B)]
    E --> E1[(OceanBase Shard C)]
    F --> F1[(OceanBase Shard D)]
    G --> G1[(OceanBase Cốt Lõi - Nhất Quán Mạnh)]

Các Giao Dịch Xuyên Unit và Vùng Cốt Lõi (Core Zone)

Không phải tất cả các giao dịch đều khép kín trong dữ liệu của một người dùng duy nhất. Một khoản thanh toán giữa hai người dùng ở các unit khác nhau phải vượt qua ranh giới của unit. Alipay xử lý điều này bằng cách định tuyến tất cả quá trình hoàn thiện giao dịch xuyên unit thông qua một Vùng Cốt Lõi (Core Zone) chuyên dụng — một tập hợp các dịch vụ tính khả dụng cao được triển khai đồng thời trên tất cả các khu vực với quá trình sao chép đồng bộ.

Vùng Cốt Lõi sử dụng OceanBase ở chế độ nhiều bản sao Paxos, trong đó một thao tác ghi chỉ được xác nhận khi đa số (ít nhất 2 trong 3 bản sao) đã lưu nó. Điều này đảm bảo không có giao dịch nào bị mất ngay cả khi một trung tâm dữ liệu biến mất giữa chừng quá trình ghi.

Lợi Ích Của Việc Chuyển Đổi Dự Phòng (Failover)

Khi một unit gặp sự cố, chỉ những người dùng được ánh xạ đến unit đó mới bị ảnh hưởng — và bộ cân bằng tải toàn cầu có thể ánh xạ lại những người dùng đó sang một unit dự phòng trong vòng mili-giây, chứ không phải vài phút, vì unit dự phòng đã có sẵn một bản sao “nóng” của phân mảnh dữ liệu bị ảnh hưởng. Phần còn lại của hệ thống tiếp tục xử lý với công suất tối đa.

Đây là lý do kiến trúc khiến Alipay có thể tự tin tuyên bố “mất giao dịch bằng không” trong các sự cố trung tâm dữ liệu: ranh giới lỗi là một unit, không phải toàn bộ hệ thống.

OceanBase: Cơ Sở Dữ Liệu Phân Tán Được Xây Dựng Để Chịu Đựng Mức Tải Đỉnh

OceanBase là cơ sở dữ liệu quan hệ phân tán nội bộ của Ant Group, được nguồn mở vào năm 2021. Nó là storage engine làm cho đơn vị hóa LDC khả thi, vì nó hỗ trợ tự nhiên (natively) mô hình dữ liệu đa khách hàng (multi-tenant), đa phân mảnh (multi-shard), phân tán theo vị trí địa lý mà LDC yêu cầu.

Các Quyết Định Thiết Kế Then Chốt

1. Storage Engine LSM-Tree OceanBase sử dụng một storage engine Log-Structured Merge-Tree (LSM-Tree), cùng nhóm engine được sử dụng bởi RocksDB và Cassandra. Không giống như B-tree truyền thống, LSM-Tree gộp các thao tác ghi vào bộ nhớ (MemTable), chuyển chúng (flush) thành các file không thay đổi trên đĩa (SSTables), và nén các SSTables trong nền. Điều này chuyển đổi các thao tác ghi ngẫu nhiên thành I/O tuần tự, tăng đáng kể thông lượng ghi — điều rất quan trọng đối với quá trình xử lý thanh toán, nơi tốc độ ghi là điểm nghẽn.

2. Đồng Thuận Đa Bản Sao Dựa Trên Paxos Mỗi phân vùng (tablet) của OceanBase được sao chép qua ít nhất ba bản sao trong các vùng sẵn sàng (availability zones) khác nhau. Quá trình ghi sử dụng giao thức đồng thuận Paxos: bản sao lãnh đạo (leader) đề xuất thao tác ghi, và nó được cam kết khi đa số xác nhận đã nhận được. Điều này mang lại tính nhất quán mạnh mẽ mà không phụ thuộc vào một master duy nhất.

3. Cách Ly Đa Khách Hàng (Multi-Tenant Isolation) OceanBase chạy nhiều đơn vị kinh doanh (sổ cái thanh toán, tài khoản người dùng, tài khoản người bán, v.v.) dưới dạng các tenant riêng biệt trên một cụm (cluster) vật lý dùng chung. Các tài nguyên (CPU, bộ nhớ, I/O) được phân bổ trên cơ sở từng tenant với các giới hạn cứng, ngăn chặn sự tăng đột biến trong một domain không gây ảnh hưởng đến domain khác.

4. OceanBase 4.x: Dịch Vụ Trọng Tài (Arbitration Service) OceanBase 4.x đã giới thiệu một Dịch Vụ Trọng Tài độc lập — một quy trình gọn nhẹ tham gia vào các cuộc bầu cử Paxos mà không lưu trữ dữ liệu. Điều này cho phép một cụm gồm 2 bản sao đạt được đa số (quorum) cho các thao tác ghi mà không yêu cầu phải có đầy đủ bản sao thứ ba, giảm chi phí cơ sở hạ tầng trong khi vẫn duy trì các đảm bảo về tính khả dụng.

Cách OceanBase So Sánh Với TiDB Và CockroachDB

Để có một so sánh chi tiết với TiDB trong bối cảnh mở rộng quy mô sổ cái thanh toán dựa trên MySQL, hãy xem bài viết của chúng tôi về Mở Rộng Cơ Sở Dữ Liệu MySQL: Sharding và Kiến Trúc TiDB.

RocketMQ 5.x: Xử Lý Hàng Tỷ Sự Kiện Tài Chính Mỗi Ngày

Mỗi khoản thanh toán tại Alipay tạo ra một chuỗi các sự kiện hạ nguồn (downstream): mục nhập vào sổ cái, chấm điểm rủi ro, thanh toán cho người bán, thông báo cho người dùng, tích điểm thưởng và hồ sơ thuế. Chúng phải được xử lý bền bỉ và theo đúng thứ tự được đảm bảo — nhưng chúng không được chặn (block) phản hồi của khoản thanh toán.

RocketMQ là trụ cột (backbone) phát trực tuyến sự kiện của Alipay (và của Alibaba). Nó là sự thay thế ở cấp độ tài chính cho Apache Kafka, với một số khả năng làm cho nó phù hợp hơn cho việc xử lý sự kiện thanh toán.

Tại Sao Lại Là RocketMQ Thay Vì Kafka Cho Các Khoản Thanh Toán

Giao Thức Thông Điệp Giao Dịch (Transactional Message Protocol): Giao thức thông điệp giao dịch gốc của RocketMQ triển khai một cơ chế chuẩn bị-sau đó-cam kết (prepare-then-commit) hai giai đoạn. Một nhà sản xuất (producer) gửi một thông điệp “đã được chuẩn bị” (vô hình đối với người tiêu thụ), thực thi giao dịch cơ sở dữ liệu cục bộ, và sau đó gửi một tín hiệu “cam kết”. Nếu nhà sản xuất gặp sự cố giữa chuẩn bị và cam kết, broker của RocketMQ sẽ truy vấn lệnh gọi lại (callback) checkLocalTransaction của nhà sản xuất để xác định xem giao dịch có thành công hay không và quyết định xem có nên cam kết hoặc hoàn tác (rollback) thông điệp đó hay không. Điều này đảm bảo việc chuyển phát sự kiện diễn ra đúng một lần phù hợp với kết quả của giao dịch cơ sở dữ liệu.

Kafka, ngược lại, cung cấp các producer idempotent và các giao dịch, nhưng ngữ nghĩa của giao dịch lại bị giới hạn trong chính Kafka — chúng không phối hợp với các giao dịch cơ sở dữ liệu bên ngoài mà không có logic hai giai đoạn ở tầng ứng dụng.

Thông Điệp Hẹn Giờ (Timer Messages): RocketMQ hỗ trợ phân phối các thông điệp với độ trễ lên đến 40 ngày. Alipay sử dụng tính năng này cho:

• Lời nhắc hết hạn thanh toán (ví dụ: “Mã QR của bạn sẽ hết hạn sau 5 phút”)
• Kích hoạt quyết toán hoãn lại (ví dụ: giải phóng quỹ ký quỹ sau thời hạn đổi trả 7 ngày)
• Giám sát SLA (ví dụ: nếu người bán không giao hàng sau 48 giờ, hãy thông báo)

Theo Dõi Thông Điệp (Message Tracing): RocketMQ 5.x cung cấp tính năng theo dõi thông điệp tích hợp sẵn (built-in) ghi lại toàn bộ vòng đời của mỗi thông điệp (sản xuất, lưu trữ, phân phối, tiêu thụ, xác nhận) với tem thời gian ở mức micro-giây (microsecond timestamps). Đây là yêu cầu bắt buộc đối với các dấu vết kiểm toán tài chính.

Quy Mô Trong Ngày Double 11

Trong ngày Double 11 năm 2023, cụm RocketMQ của Alibaba đã duy trì:

• Hơn 1 nghìn tỷ lượt phân phối thông điệp trong vòng 24 giờ
• Thông lượng đỉnh đạt nhiều triệu thông điệp mỗi giây
• Độ trễ phân phối thông điệp P99 dưới 5ms đối với các topic quan trọng liên quan đến thanh toán

Để tìm hiểu sâu hơn về các mẫu (patterns) theo hướng sự kiện sử dụng kiến trúc tương tự, hãy xem Làm Chủ Kiến Trúc Hướng Sự Kiện với Dapr.

Microservices SOFAStack: Cách Ant Group Tiêu Chuẩn Hóa Service Mesh Ở Quy Mô Lớn

Với hàng trăm microservices, Alipay cần một framework tiêu chuẩn hóa cho giao tiếp dịch vụ, khám phá (discovery), khả năng phục hồi và khả năng quan sát. SOFAStack là một framework nội bộ đã nổi lên từ nhu cầu này — nay đã được nguồn mở.

Các Thành Phần Chính

SOFARPC: Một framework RPC hiệu năng cao dựa trên giao thức Bolt. Bolt là một giao thức nhị phân có tiền tố chiều dài, được tối ưu hóa cho các dịch vụ tài chính: nó bao gồm sẵn loại thông điệp, chuỗi ID, và các trường định dạng tuỳ chỉnh ở phần header, cho phép gộp các request và quản lý thời gian chờ cho mỗi request trên cùng một kết nối TCP.

SOFAMesh: Một bản cài đặt của service mesh tích hợp với Envoy và Istio nhưng mở rộng chúng với các yêu cầu cụ thể của Ant Group: chính sách gộp kết nối (connection pooling) cho SLAs của dịch vụ tài chính, quy tắc định tuyến động (dynamic routing) dành cho điều hướng traffic theo đơn vị LDC, và việc đồng bộ hóa tình trạng của circuit breaker giữa các vùng khác nhau.

Seata: Trình điều phối giao dịch phân tán thực thi các chế độ Saga, TCC (Try-Confirm-Cancel) và AT (Automatic Transaction) để quản lý các thao tác cơ sở dữ liệu trên nhiều service. Nếu bạn đang thiết kế mẫu giao dịch phân tán với runtime khác, hãy đọc bài viết về Hướng dẫn Dapr Workflow Saga Orchestration của chúng tôi để xem một ví dụ triển khai bằng Go cho những mẫu này.

SOFATracer: Một hệ thống theo dõi phân tán chuyển tiếp dữ liệu ngữ cảnh (Trace ID, Span ID) thông qua mọi lệnh gọi SOFARPC, yêu cầu HTTP và thông báo của RocketMQ. Mọi hoạt động tài chính tại Alipay đều có thể theo dõi đầy đủ từ lệnh gọi API thanh toán ban đầu cho tới việc ghi sổ cái cuối cùng và phát hành thông báo.

Thử Nghiệm Tải Hằng Năm: Cách Alipay Luyện Tập Cho Ngày Tồi Tệ Nhất Trong Năm

Alipay không đơn giản là thêm máy chủ và hy vọng cho điều tốt đẹp nhất. Một tuần trước Double 11, đội ngũ kỹ thuật chạy một buổi diễn tập chaos engineering mô phỏng môi trường production quy mô lớn gọi là 全链路压测 (Thử Nghiệm Tải Toàn Hệ Thống - Full-Link Stress Test).

Những Gì Được Đưa Vào Thử Nghiệm Tải Toàn Hệ Thống

1. Phát Lại Shadow Traffic: Lưu lượng giao dịch thật được phát lại ở mức độ tải mong muốn gấp 2 lần đối với hạ tầng production sử dụng dữ liệu giả (độc lập với người dùng thực). Quá trình này giúp tìm ra những điểm nghẽn với phân phối truy vấn chân thật.

2. Bài Tập Failover Ở Đơn Vị LDC: Các đơn vị bị ngưng hoạt động giả định để đảm bảo việc bộ định tuyến toàn cầu chuyển lưu lượng trong giới hạn thời gian quy định (dưới 100ms), quá trình đưa bản sao OceanBase lên trạng thái hoạt động thực sự hoàn thành mà không gặp tình trạng mất mát dữ liệu, cũng như là việc phục hồi hạ bậc duyên dáng của các hệ thống ngầm bên dưới.

3. Mô Phỏng Tắc Nghẽn Consumer RocketMQ: Các nhóm tiêu thụ bị cản lại để mô tả việc hệ thống cấp thấp đang bị mắc kẹt do quá nhiều thao tác dưới cùng 1 tải. Kỹ sư cần đảm bảo rằng trạng thái phản lực ngược dòng (backpressure) điều phối chuẩn chỉnh thông qua những tầng khác của hệ thống để phòng ngừa sập dây chuyền.

4. Đo Đạc Mức Độ Chống Chịu Bổ Sung: Sau tất cả các cuộc diễn tập, một bài thử tải tối hậu ở mức độ 110% lượng truy cập mong muốn sẽ được dùng để chừa lại điểm dư. Nếu có những thao tác bão hòa hoặc quá giới hạn, chúng sẽ ngay lập tức được cải thiện.

Quá trình làm mới theo đúng bài bản như vậy đã đưa cách tiếp cận thực hành của kiến trúc tại Alipay lên quy mô hoàn toàn cách biệt và “thực tiễn” - thứ đã bị lơ là ở nhiều hệ thống. Với Kubernetes, có thể xem thêm ở bài viết GitOps Ở Quy Mô Lớn: Kubernetes Và ArgoCD Cho Microservices.

Bài Học Cho Kỹ Sư Hiện Đại: Điều Có Thể Áp Dụng Ngay Lập Tức

Kiến trúc Alipay giải quyết hệ thống ở một cấp độ độ khó cực đoan mà đa phần sẽ ít khi đối diện được. Tuy vậy, các nguyên tắc được sử dụng đằng sau quyết định có khả năng mang tính mở vô hạn trong những cấu trúc hằng chục ngàn thay vì trăm ngàn giao dịch/giây.

1. Phác Thảo Cấu Trúc Bền Vững Hóa, Thay Vì Khôi Phục Failover

Thiết kế hướng đơn vị LDC diễn giải cho chúng ta góc độ ưu việt từ việc định nghĩa giới hạn phá hủy của từng phần tử lỗi, không phải nhắm mục đích khôi phục sớm. Sẽ hợp lý khi tự nhận thấy được sự liên quan: “Nếu cái này bị tắt/dừng/hư hại thì nhóm người/kế thừa nào sẽ bị cuốn vào?”. Nếu câu trả lời là “tất cả mọi người” - thì đó là khi bạn nên xem xét về định chuẩn ranh giới phá hủy.

2. Định Hình Tính Đồng Bộ Dữ Liệu Nương Tựu Tính Chất Của Hệ Sinh Thái

OceanBase dùng thuật toán đồng thuận siêu cứng Paxos, tuy nhiên vẫn chấp nhận dùng các yếu tố độ bền trung bình khác với hệ thống điểm thưởng hay đề xuất người dùng. Tùy chỉnh những giải pháp thực thụ có lợi cho cấu trúc chính thay vì áp dụng một cách rập khuôn, từ đó sẽ giảm tổn hao băng thông hơn so với tính năng nhất quán dữ liệu đầy đủ.

3. Thông Báo Các Giao Dịch Chắc Chắn Phải Cần Thiết Cho Giao Dịch

Với những thao tác như nạp tiền/xác minh, gửi bằng Kafka thông thường dễ dàng tạo lỗ hỏng với quy mô hệ thống phân tán. Việc áp dụng những hệ thống chuẩn chuẩn tắc liên kết như Kafka hay thông báo ngoài ngữ cảnh sẽ thiết lập được độ tự chủ chính quy.

4. Diễn Tập Cường Độ Cao Cho Thời Điểm Khắc Nghiệt

Chaos engineering không hề bó buộc ở doanh nghiệp lớn. Một nhóm bé vẫn có thể tự khởi chạy mô đun mô phỏng hệ thống tiêu chuẩn với quy mô 110%. Những rủi ro mất giá sẽ lớn hơn việc dành thời gian để tự tối ưu mô hình trước ngày vận hành quy mô.

Những Câu Hỏi Thường Gặp

LDC unitization trong hệ thống cấu trúc Alipay là gì?

LDC (Local Deployment Center) là công nghệ phân rã môi trường thao tác, dịch vụ và cơ sở dữ liệu làm thành các mảnh riêng có khả năng tồn tại đồng bộ. Nó giảm rủi ro tới từng góc độ người tiêu dùng nhỏ giọt khác nhau (những phần không hỏng vẫn được cung cấp kết nối trong thời gian chớp mắt - millisec).

Sự So Sánh Giữa OceanBase với CockroachDB Hoặc TiDB

Tất thảy hệ thống phân tán đều liên đới quy trình đồng thuận mạng (Raft/Paxos). Điểm cộng lớn của OB chính là tính thích ứng Oracle SQL mạnh mẽ, chia tách tầng phân phối quy trình chuẩn chỉ, kèm cả kiến trúc lưu theo Log cho khả năng duy trì hoạt động trên tải lớn.

Có Tất Thảy Bao Nhiêu Thanh Toán Xảy Ra Năm 2023?

Thống kê lớn nhất rơi vào khoảng 583,000 thanh toán/giây (TPS) ở phút giao lúc nửa đêm. Con số thu được trong ngày lên đến nghìn tỷ và nó xử lý êm xuôi qua cơ sở chuẩn mở rộng OB cũng như chia nhánh hệ thống tự quyết định chuẩn hóa.