Phase 2: Kiến Trúc Kỹ Thuật LDC & OceanBase

Phiên bản đa ngôn ngữ: Bài viết này có phiên bản tiếng Anh chuẩn quốc tế tại Phase 2: LDC Cellular Architecture & OceanBase Consensus (tanhdev.com).

📖 Bản tiếng Anh (English Edition)

← Chương trước: Phase 1: Lịch Sử & Tiến Trình 2009-2026 | Mục lục Series | Chương tiếp theo: Phase 3: Quy Trình Vận Hành & Stress Testing →

Answer-first: Kiến trúc LDC (Logical Data Center) phân chia hệ thống thành các tế bào chuyên biệt: RZone (tự trị theo người dùng), GZone (dữ liệu dùng chung) và CZone (sổ cái kế toán trung tâm), kết hợp thuật toán đồng thuận Multi-Paxos trên OceanBase giúp mở rộng ngang không giới hạn và bảo đảm RPO=0, RTO<2s.

Điều kiện tiên quyết: Nắm vững nguyên lý sharding dữ liệu, mô hình đồng thuận phân tán Paxos/Raft và kiến trúc trung tâm dữ liệu active-active đa vùng.

Phase 2: Kiến Trúc Kỹ Thuật Sâu - Alipay Double 11

2.1 Logical Data Center (LDC) & Unitization Architecture

graph TB
    subgraph LDC ["Logical Data Center — cell tự chứa theo user_id"]
        RZ1["RZone 1<br/>(user shard A: app + DB)"]
        RZ2["RZone 2<br/>(user shard B: app + DB)"]
        GZ["GZone<br/>(dịch vụ toàn cục)"]
        CZ["CZone<br/>(đọc latency thấp,<br/>đặt gần RZone)"]
    end
    UA["User A"] --> RZ1
    UB["User B"] --> RZ2
    RZ1 -.->|"đọc gần"| CZ
    RZ2 -.-> CZ
    RZ1 --> GZ
    RZ2 --> GZ

    style GZ fill:#e8f4f8,stroke:#2a7da0

Core Concept: “Unit”

Định nghĩa: Unit là một tập hợp self-contained có thể hoàn thành toàn bộ business operations. Đây là phiên bản thu nhỏ của toàn bộ hệ thống:

• Có đầy đủ: Tất cả services và applications
• Không đầy đủ: Chỉ chứa một phần dữ liệu (data sharding)

Ba Loại Zone trong LDC

┌─────────────────────────────────────────────────────────────┐
│                    LDC Architecture                          │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐       │
│   │   RZone 1   │   │   RZone 2   │   │   RZone N   │       │
│   │  (Region)   │   │  (Region)   │   │  (Region)   │       │
│   ├─────────────┤   ├─────────────┤   ├─────────────┤       │
│   │ • App Layer │   │ • App Layer │   │ • App Layer │       │
│   │ • Data Shard│   │ • Data Shard│   │ • Data Shard│       │
│   │ • Full Svcs │   │ • Full Svcs │   │ • Full Svcs │       │
│   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘       │
│          │                 │                 │              │
│          └─────────────────┼─────────────────┘              │
│                            │                                │
│                   ┌──────────┴──────────┐                     │
│                   │                     │                     │
│            ┌──────┴──────┐      ┌──────┴──────┐              │
│            │   GZone     │      │   CZone     │              │
│            │  (Global)   │      │  (City)     │              │
│            ├─────────────┤      ├─────────────┤              │
│            │ • Config    │      │ • User Info │              │
│            │ • CIF       │      │ • Login     │              │
│            │ • Shared    │      │ • Frequent  │              │
│            └─────────────┘      └─────────────┘              │
└─────────────────────────────────────────────────────────────┘

RZone (Region Zone)

• Tự chủ hoàn toàn: Có đủ data và services để xử lý business
• Data sharding: Mỗi RZone chỉ chứa một phần dữ liệu (ví dụ: user ID 1-1M ở RZone 1, 1M-2M ở RZone 2)
• Horizontal scaling: Thêm RZone = thêm capacity
• Multi-active: Nhiều RZone active đồng thời ở các region khác nhau

GZone (Global Zone)

• Chỉ 1 instance toàn cục
• Chứa dữ liệu không thể chia nhỏ (inseparable):
  • Config center
  • CIF (Customer Information File)
  • Shared global data
• Read/Write: Được tất cả RZones truy cập (tần suất thấp)

CZone (City Zone)

• Giải quyết latency giữa các cities
• Chứa dữ liệu/services được RZone truy cập thường xuyên
• Mỗi business access ít nhất một lần
• Khác GZone: CZone được truy cập liên tục bởi RZone

Lợi Ích LDC Architecture

Kết quả:

• 99.99% availability (financial-grade)
• Theoretical unlimited capacity (thêm RZone = scale out)
• Hundreds of thousands TPS trong promotion

2.2 Database Layer - OceanBase

graph LR
    C["Client commit"] --> L["Leader (Paxos group)"]
    L -->|"quorum write"| F1["Follower 1 ✓"]
    L -->|"quorum write"| F2["Follower 2 ✓"]
    L -->|"chậm/bị cách ly"| F3["Follower 3 ✗"]
    F1 --> ACK{"Đa số xác nhận?<br/>2/3 ✓"}
    F2 --> ACK
    ACK -->|"CÓ — commit"| OK["Trả client<br/>RPO=0 theo giao thức"]
    F3 -.->|"phục hồi sau"| F1

    style OK fill:#e8f8e8,stroke:#2a7da0
    style F3 fill:#f8f8e8,stroke:#a0a02a

Lịch Sử Evolution

Oracle (commercial) → MySQL (open source) → OceanBase (distributed)
        ↓                     ↓                      ↓
    2010-2012             2012-2014               2014+
   Limits hit        Still bottlenecks       Auto-scaling

Kiến Trúc OceanBase

┌──────────────────────────────────────────────────────────────┐
│                    OceanBase Cluster                          │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│   Zone 1          Zone 2          Zone 3         (Regions)   │
│   ┌────────┐     ┌────────┐     ┌────────┐                  │
│   │ OBS 1  │     │ OBS 2  │     │ OBS 3  │                  │
│   │ (Leader)│◄──►│(Follower)│◄──►│(Follower)│   Paxos Sync  │
│   └────────┘     └────────┘     └────────┘                  │
│      │               │               │                       │
│      └───────────────┼───────────────┘                       │
│                      │                                        │
│   ┌──────────────────┴──────────────────┐                    │
│   │         Table Partitions              │                    │
│   │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐    │                    │
│   │  │ P1  │ │ P2  │ │ P3  │ │ P4  │    │  Paxos per partition│
│   │  └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘    │                    │
│   │     └───────┴───────┴───────┘       │                    │
│   └─────────────────────────────────────┘                    │
└──────────────────────────────────────────────────────────────┘

Key Components

1. Paxos Protocol cho Consistency

• RPO = 0 (Recovery Point Objective): Zero data loss
• RTO < 8 seconds (Recovery Time Objective)
• Multi-replica strong synchronization: Majority consensus
• Automatic failover: Server, rack, AZ, hoặc entire region failure

2. Partitioning Strategy

• Tables được partitioned explicitly bởi user
• Partition = đơn vị cơ bản cho:
  • Data distribution
  • Load balancing
  • Paxos synchronization
• Thường 1 Paxos group per partition

3. Transaction Processing

Local Transaction:

SQL → Compile → Execution Plan → Local Execution

Distributed Transaction (2PC + Paxos):

SQL → Compile → Distributed Plan → 2PC Coordinator
                                  ↓
                    ┌─────────────┼─────────────┐
                    ↓             ↓             ↓
                  Paxos 1       Paxos 2       Paxos N
                    │             │             │
                    └─────────────┴─────────────┘
                           Commit OK

OceanBase 2PC vs Traditional 2PC:

• Traditional: Coordinator single point of failure
• OceanBase: Paxos-based 2PC - coordinator replicated

4. Storage Engine

• LSM-tree (Log-Structured Merge Tree) architecture
• Compaction: Offload đến FPGA (custom hardware) để xử lý nhanh hơn
• Row caches + Block caches: Multi-level caching
• Replica types:
  • Full replica (data + log)
  • Data replica (data only)
  • Log replica (log only)

OceanBase Scale Numbers

Lessons Learned từ OceanBase Paper

1. Application layer: Không dùng database như key-value store → dùng advanced features
2. Stored procedures: Vẫn có giá trị lớn cho OLTP
3. Timeouts: Mọi transaction và SQL phải có timeout (distributed systems có failure rate cao hơn)

2.3 Distributed Systems Patterns

Remote Multi-Active Architecture (2013+)

┌─────────────────────────────────────────────────────────────┐
│              Multi-Active Deployment                         │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   Hangzhou          Shanghai         Beijing               │
│   ┌────────┐        ┌────────┐       ┌────────┐            │
│   │Unit A  │◄──────►│Unit B  │◄─────►│Unit C  │            │
│   │(Active)│        │(Active)│       │(Active)│            │
│   └────────┘        └────────┘       └────────┘            │
│      │                  │                │                   │
│      └──────────────────┼────────────────┘                   │
│                         │                                   │
│                    ┌────┴────┐                              │
│                    │  GZone  │                              │
│                    │ (Shared)│                              │
│                    └─────────┘                              │
└─────────────────────────────────────────────────────────────┘

Đặc điểm:

• Mỗi city có complete transaction unit
• Regional scaling: Thêm city = thêm capacity
• Disaster recovery: Một city down → traffic chuyển sang city khác

Service Mesh & Inter-Service Communication

Message Queue (RocketMQ)

• Async processing cho non-critical path
• Peak shaving: Buffer traffic bursts
• Decoupling giữa các services

Circuit Breaker, Throttling, Degrade

Throttling (Rate Limiting)

• AHAS (Application High Availability Service)
• Giới hạn request rate để bảo vệ downstream services

Degrade

• Graceful degradation: Tắt non-essential features khi quá tải
• Prioritization: Quan trọng nhất được bảo vệ đầu tiên

Circuit Breaker

• Fail fast: Không đợi timeout
• Auto-recovery: Tự động thử lại sau cooldown

2.4 Cloud-Native Evolution (2020+)

Containerization với PouchContainer

┌─────────────────────────────────────────────────────────────┐
│                    Cloud-Native Stack                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   Application Layer                                          │
│   ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐         │
│   │  App 1  │ │  App 2  │ │  App 3  │ │ App N   │         │
│   └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘         │
│        │           │           │           │              │
│   ┌────┴───────────┴───────────┴───────────┴────┐         │
│   │           Kubernetes (ACK)                   │         │
│   │    Scheduling, Auto-scaling, Recovery      │         │
│   └────────────────┬──────────────────────────────┘         │
│                    │                                        │
│   ┌────────────────┴──────────────────────┐                │
│   │      PouchContainer Runtime            │                │
│   │  • OCI compatible                      │                │
│   │  • Kubernetes CRI                      │                │
│   │  • Enterprise features                 │                │
│   └────────────────────────────────────────┘                │
│                                                              │
│   ┌──────────────────────────────────────────┐               │
│   │        Alibaba Cloud Infrastructure      │               │
│   │  • ECS, Bare Metal, GPU, FPGA           │               │
│   └──────────────────────────────────────────┘               │
└─────────────────────────────────────────────────────────────┘

PouchContainer

• OCI compatible: Tuân thủ Open Container Initiative
• Kubernetes CRI: Native Kubernetes integration
• Enterprise features: Bảo mật, isolation cao

Elastic Architecture

Normal State                     Peak State (Double 11)
┌──────────────┐                ┌──────────────┬──────────────┐
│  RZone 1     │                │  RZone 1     │ Elastic Unit │
│  (Daily)     │                │  (Daily)     │  (Cloud)     │
├──────────────┤      ─────►    ├──────────────┼──────────────┤
│  RZone 2     │                │  RZone 2     │ Elastic Unit │
│  (Daily)     │                │  (Daily)     │  (Cloud)     │
└──────────────┘                └──────────────┴──────────────┘

Elastic Units:

• Một số RZones biến thành elastic units
• Peak period: Pop up lên cloud để scale nhanh
• Post-peak: Bounce back về daily data center
• Insensible elasticity: Business layer không biết đang chạy ở đâu

Co-location: Online + Big Data

┌─────────────────────────────────────────────────────────────┐
│                    Co-location Cluster                       │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌──────────────────────────────────────────────────────┐  │
│   │                 Shared Resources                    │  │
│   │  ┌─────────────┐              ┌─────────────────┐   │  │
│   │  │ Online Svc  │   Idle time  │  Big Data Task  │   │  │
│   │  │ (Real-time) │◄────────────►│  (Batch)        │   │  │
│   │  └─────────────┘              └─────────────────┘   │  │
│   └──────────────────────────────────────────────────────┘  │
│                                                              │
│   Resource Pool: Online peak sử dụng, idle dùng cho Big Data │
│   Cost saving: ~50% giảm chi phí                             │
└─────────────────────────────────────────────────────────────┘

Sigma + Fuxi Scheduling:

• Sigma: Online service scheduling
• Fuxi: Big data task scheduling
• Unified: Một cluster cho cả hai loại workload

Cost Efficiency 2020

2.5 Agentic Commerce & Next-Gen AI (2025-2026)

Hệ Sinh Thái AI & Agentic Commerce

Đến năm 2025-2026, kiến trúc hệ thống Alipay đã dịch chuyển mạnh mẽ để hỗ trợ các Autonomous AI Agents.

• AI-Driven Infrastructure: Sử dụng mô hình Ling-3.0-Flash (native hybrid-reasoning) tối ưu hóa tốc độ và tiết kiệm chi phí, cho phép các AI Agents tự động xử lý đặt chỗ, mua sắm và thanh toán thay cho người dùng.
• Alipay Tap!: Ra mắt 2024 và bùng nổ 2025, công nghệ thanh toán tiệm cận không cần mở ứng dụng đã yêu cầu kiến trúc phải xử lý latency ở mức cực thấp, giảm tải quá trình mở app và xác thực thông qua mã QR truyền thống.
• Microservices for AI: Các API mới được thiết kế đặc biệt cho M2M (Machine-to-Machine) commerce, cho phép doanh nghiệp cung cấp cổng thanh toán trực tiếp cho AI Agent.

Key Architectural Insights

1. Evolution Path

2008: Distributed architecture (break monolithic)
  ↓
2013: LDC + Multi-active (horizontal scale)
  ↓
2014: Automated testing (predictable reliability)
  ↓
2016: Elastic architecture (cloud integration)
  ↓
2020: Cloud-native (efficiency & cost)
  ↓
2025-2026: Agentic Commerce & Next-Gen AI Integration

2. Design Principles

• Unitization: Chia nhỏ để scale
• Self-containment: Mỗi unit độc lập
• Automation: Không manual intervention
• Testing: Verify trước production

3. Trade-offs

• Consistency: Paxos = strong consistency nhưng latency
• Sharding: Scale tốt nhưng cross-shard query phức tạp
• Elasticity: Cost tốt nhưng architecture phức tạp

Next: Phase 3 - Quy Trình Vận Hành & Stress Testing ➔

🔗 Đọc thêm các chuyên đề liên quan:

• Kiến trúc Microservices Golang & DDD
• Triển khai Agentic AI Swarm trong Production với OpenClaw & LiteLLM
• Kiến trúc Microservices Golang gRPC: Protobuf, TLS & Middleware

Phân Tích Chuyên Sâu: Cơ Chế Đồng Thuận Multi-Paxos và Kỹ Thuật Sharding Tài Khoản Nóng CZone

Answer-first: Để vượt qua giới hạn độ trễ mạng liên vùng khi xử lý 544.000 TPS, Alipay triển khai mô hình đa trung tâm 3DC2C với cơ chế commit đa số cục bộ của OceanBase Multi-Paxos, kết hợp giải thuật chia nhỏ tài khoản thương nhân nóng thành các tài khoản ảo tại CZone nhằm triệt tiêu hoàn toàn hiện tượng nghẽn khóa hàng kế toán.

1. Phân Tách Vai Trò Thực Tế: RZone vs CZone

Trong các hệ thống thương mại điện tử quy mô cực lớn, sai lầm phổ biến nhất là cố gắng phân mảnh toàn bộ thực thể theo một khóa duy nhất. Alipay giải quyết triệt để sự xung đột này bằng sự phân vai giữa RZone và CZone:

• Nguyên lý Tự Trị RZone: Khi người mua thực hiện đặt hàng và thanh toán, luồng xử lý chỉ đọc và ghi dữ liệu thuộc phạm vi user_id của chính họ (trừ tiền ví, cập nhật trạng thái đơn hàng cá nhân). Do đó, toàn bộ lệnh SQL chỉ chạm tới shard cơ sở dữ liệu OceanBase cục bộ nằm ngay trong cell RZone đó. Không có bất kỳ truy vấn nào phải gửi qua mạng WAN sang thành phố khác.
• Thách thức Tài Khoản Nóng tại CZone: Số dư người mua có thể phân mảnh theo user_id, nhưng tài khoản thụ hưởng của người bán (như gian hàng Apple, Nike hay Uniqlo) thì không thể. Nếu 50.000 người mua cùng thanh toán cho một thương nhân trong 1 giây, cơ sở dữ liệu truyền thống buộc phải thực hiện khóa hàng (Row Lock) trên đúng dòng ghi số dư của thương nhân đó, biến toàn bộ sức mạnh xử lý song song thành hàng đợi tuần tự.
• Kỹ thuật Virtual Sub-Account Sharding: Alipay chia tài khoản của mỗi thương nhân lớn thành $M$ tài khoản phụ (thường là $M = 100$, định danh từ merchant_sub_00 đến merchant_sub_99). Khi đơn hàng hoàn tất, hệ thống chọn tài khoản phụ dựa trên mã băm đơn hàng hash(order_id) % M. Nhờ đó, 50.000 giao dịch đồng thời được rải đều vào 100 dòng ghi khác nhau trong database CZone, giảm áp lực tranh chấp khóa xuống 100 lần. Vào cuối ngày, tiến trình đối soát ngầm sẽ tổng hợp số dư từ các tài khoản phụ về tài khoản mẹ.

2. Thuật Toán Đồng Thuận Multi-Paxos Trong Cấu Hình 3DC2C

OceanBase không sử dụng giải pháp lưu trữ chia sẻ (SAN) mà hoạt động trên mô hình Shared-Nothing gồm các máy chủ x86 tiêu chuẩn, đồng bộ dữ liệu qua thuật toán Multi-Paxos:

• Phân Bổ Vị Trí Địa Lý:
  • Hàng Châu - IDC 1: Bản sao đầy đủ (Full Replica) + Nhóm ứng dụng RZone 1.
  • Hàng Châu - IDC 2: Bản sao đầy đủ (Full Replica) + Nhóm ứng dụng RZone 2.
  • Thượng Hải - IDC 3: Bản sao đầy đủ (Full Replica) + Nhóm ứng dụng RZone 3.
• Tối Ưu Hóa Commit Đa Số Cục Bộ: Khoảng cách cáp quang nội đô giữa hai IDC tại Hàng Châu cho độ trễ cực thấp (< 1.5ms RTT), trong khi độ trễ đường truyền WAN giữa Hàng Châu và Thượng Hải dao động từ 20ms đến 25ms. Khi một giao dịch được ghi tại Hàng Châu IDC 1, log giao dịch (CLog) được phát đồng thời tới IDC 2 và IDC 3. Vì thuật toán Paxos chỉ yêu cầu đa số bản sao (2 trên 3 bản sao) xác nhận trước khi commit, giao dịch được xác nhận thành công ngay khi Hàng Châu IDC 2 phản hồi ghi đĩa NVMe xong (chỉ mất ~2-3ms). Hệ thống không bao giờ phải chờ phản hồi từ Thượng Hải IDC 3 để hoàn tất giao dịch.
• Cam Đoan RPO=0 Không Đánh Đổi: Dữ liệu luôn được bảo toàn tuyệt đối. Trong trường hợp thảm họa thiên tai khiến toàn bộ thành phố Hàng Châu mất điện hoàn toàn, bản sao tại Thượng Hải IDC 3 kết hợp cùng một node trọng tài (Witness Node) trên đám mây sẽ bầu chọn Paxos Leader mới và tiếp quản xử lý trong vòng dưới 2 giây (RTO < 2s) mà không làm mất một byte giao dịch nào đã commit (RPO = 0).

❓ Câu Hỏi Thường Gặp (FAQ)

📚 Nguồn nghiên cứu (verification anchors)

Bản nghiên cứu: reports/research-alipay-executive-summary-100-rounds.{md,json} (ledger Ch1) + research-alipay-phases-consolidated-100-rounds.md (dossier hợp nhất Ch2–Ch9), mirror cả 2 repo. Ghi chú grounding: các con số đỉnh là Ant-reported (hệ thống đóng); TPC-C là con số duy nhất được audit độc lập.