TiDB

Mục lục Series | Chương tiếp theo: Phần 1 — Nền tảng: Microservices & GitOps (2026) → Answer-first: Nền tảng thanh toán PayPay Nhật Bản mở rộng phục vụ hơn 70 triệu người dùng và hàng nghìn TPS nhờ kiến trúc microservices trên Kubernetes, cơ chế Event-Driven với Apache Kafka, cơ sở dữ liệu phân tán TiDB và nền tảng AI-Native LLM Hub. Tổng Quan Hệ Thống PayPay ra mắt năm 2018 và nhanh chóng thống trị thị trường thanh toán di động Nhật Bản, một phần nhờ các chiến dịch marketing mạnh tay như chiến dịch “Tặng 10 Tỷ Yên”. Những chiến dịch này tạo ra các đợt tăng vọt traffic khổng lồ, không thể đoán trước, làm sập các hệ thống monolithic và đồng bộ truyền thống. ...

← Chương trước: Phần 1: Double-Entry Ledger Schema | Mục lục Series | Chương tiếp theo: Phần 3: Event Sourcing & CQRS → Answer-first: Giao dịch ACID phân tán trong Core Banking đòi hỏi lựa chọn kỹ lưỡng giữa Google Spanner (TrueTime commit-wait 2-14ms), TiDB (Percolator TSO 1-3ms) và CockroachDB (Hybrid Logical Clock), cân bằng giữa tính nhất quán nghiêm ngặt và độ trễ ghi P99. Distributed SQL Transaction Latency Là Gì? Các distributed SQL databases như TiDB, Spanner, và CockroachDB sinh ra độ trễ mạng (network latency overheads) cho ACID transactions do quá trình distributed consensus và đồng bộ thời gian. Two-phase commit (2PC) và timestamp oracles thường cộng thêm 1-3ms độ trễ cho mỗi transaction — con số nhỏ nhưng có tác động đáng kể khi nhân với hàng triệu giao dịch/giây. ...

← Chương trước: Chiến Lược Caching & Bệnh Đàn Voi Giẫm Đạp (Cache Stampede) — Singleflight, XFetch & Redis LFU | Mục lục Series | Chương tiếp theo: Kiến Trúc Hướng Sự Kiện (Event-Driven Architecture) & Kafka — Worker Pool, Backpressure & Exactly-Once → Answer-first: Mở rộng cơ sở dữ liệu quy mô lớn đòi hỏi phân mảnh (Sharding) theo Range/Hash hoặc chuyển dịch sang NewSQL phân tán như TiDB (Percolator 2PC). Đồng thời, tối ưu hóa Connection Pool cho PostgreSQL và Go database/sql giúp ngăn ngừa cạn kiệt tài nguyên bộ nhớ dưới tải cao. ...

← Chương trước: Phần 2 — Xử lý tải đột biến: Event-Driven & Kafka (2026) | Mục lục Series | Chương tiếp theo: Phần 4 — Vận hành: SRE & Chaos Engineering (2026) → Answer-first: PayPay chuyển đổi tầng dữ liệu từ Amazon Aurora sang TiDB (Distributed SQL) để giải quyết giới hạn mở rộng ghi và loại bỏ nhu cầu sharding thủ công, đạt khả năng co giãn ngang với độ trễ thấp và tuân thủ chuẩn ACID. ...

← Chương trước: Bài 3: Tấm khiên bảo vệ — Message Queue và Graceful Degradation | Mục lục Series | Chương tiếp theo: Bài 5: Tai mắt của hệ thống — Distributed Tracing với ClickHouse → Answer-first: Để vượt qua giới hạn của MySQL Sharding truyền thống (nghẽn resharding và thiếu ACID phân tán), Shopee chuyển dịch sang TiDB NewSQL. TiDB tách biệt stateless computing (TiDB Server) và stateful storage (TiKV via Raft), hỗ trợ mở rộng ngang tự động và truy vấn phân tán quy mô lớn. ...

← Chương trước: Phần 4: MariaDB vs. MySQL | Mục lục Series | Chương tiếp theo: Phần 6: Apache Kafka vs. NATS JetStream → Sharded MySQL (Vitess) vs. TiDB NewSQL: ACID Phân Tán & Thuế Độ Trễ Mạng Answer-first: Sharded MySQL (Vitess) áp đảo về độ trễ ghi (sub-2ms) và cô lập lỗi (Blast Radius) cho hệ thống E-commerce / SaaS có Sharding Key sạch. Ngược lại, TiDB NewSQL là giải pháp cứu cánh cho schema phức tạp nhờ cơ chế tự động chia tách Region 96MB, chấp nhận mức sàn độ trễ ghi 8–15ms do Percolator 2PC. ...

← Chương trước: Phase 5: Bài Học & Khung Kiến Trúc | Mục lục Series Answer-first: So sánh đối chiếu toàn diện giữa hệ sinh thái Alipay (OceanBase, RocketMQ, SOFARPC, MOSN) với các giải pháp Cloud-Native hiện đại (TiDB, CockroachDB, Kafka, gRPC, Istio), đưa ra khung ma trận quyết định công nghệ tối ưu cho từng quy mô doanh nghiệp. So Sánh Alipay Stack với Công Nghệ Hiện Đại Tổng Quan So Sánh Alipay Stack Modern Equivalent Key Difference LDC + RZone Kubernetes + Multi-cluster LDC: Business-driven sharding; K8s: Infrastructure abstraction OceanBase CockroachDB/TiDB/YugabyteDB OceanBase: 10+ years prod, custom FPGA; Newer: Cloud-native first RocketMQ Apache Kafka/Apache Pulsar RocketMQ: LSM-tree + rich msg types; Kafka: Log-centric; Pulsar: Tiered storage SOFARPC gRPC/Envoy Proxy SOFARPC: Java-centric, financial features; gRPC: Cross-platform, protobuf SOFAMesh (MOSN) Istio/Linkerd MOSN: Go-based, X-protocol; Istio: Envoy C++, standard mesh CTU & AI (2025+) Modern ML Platforms CTU: Custom fraud-specific; 2025+ adds LLMs & AI Pay; Modern: GenAI/MLOps PouchContainer containerd/cri-o Pouch: Alibaba-specific; containerd: CNCF standard 1. LDC Architecture vs Kubernetes Multi-Cluster Kiến Trúc So Sánh ┌─────────────────────────────────────────────────────────────────────────────┐ │ LDC (Alipay) vs Kubernetes Multi-Cluster │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ LDC Architecture (Business-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ RZone 1 RZone 2 RZone N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Users │ │Users │ │Users │ │ │ │ │ │1-1M │ │1M-2M │ │N-M │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │Apps │ │Apps │ │Apps │ │ │ │ │ │DB │ │DB │ │DB │ │ │ │ │ │Cache │ │Cache │ │Cache │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: User ID-based │ │ │ │ • Self-contained units │ │ │ │ • Cross-unit = Distributed txn │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ Kubernetes Multi-Cluster (Infrastructure-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Cluster 1 Cluster 2 Cluster N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Region: │ │Region: │ │Region: │ │ │ │ │ │us-west │ │eu-west │ │ap-south │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │K8s Pods │ │K8s Pods │ │K8s Pods │ │ │ │ │ │Services │ │Services │ │Services │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: Infrastructure/region-based │ │ │ │ • Shared global services │ │ │ │ • Cross-cluster = Service mesh │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ Detailed Comparison Aspect LDC (Alipay) K8s Multi-Cluster Recommendation Sharding Strategy User ID / Business key Node/Region labels LDC approach cho data-intensive apps Unit Boundary App + Data + Cache Pods + Services LDC: true isolation; K8s: shared storage Cross-Unit Traffic Explicit ( costly ) Transparent via mesh LDC: intentional design; K8s: hide complexity Failover Manual/Scripted (RZone switch) Automatic (health checks) K8s wins cho automation Scaling Add RZone (complex) Add nodes (simple) K8s wins cho ops simplicity Data Consistency Strong (Paxos in unit) Eventual (cross-cluster) LDC wins cho financial data Khi Nào Dùng Cái Nào? Use LDC-style khi: ...

MySQL Scalability & Sharding: Vitess vs TiDB (10k+ TPS) Answer-first: Scaling MySQL requires a phased architectural progression: optimizing InnoDB buffer pools (100–500 TPS), implementing ProxySQL read/write splitting (500–3,000 TPS), and migrating to horizontal sharding or TiDB Distributed SQL (3,000–10,000+ TPS). TiDB serves as the premier MySQL sharding alternative, eliminating manual application-level partitioning through stateless SQL compute nodes and Raft-replicated distributed TiKV storage. MySQL scalability is the ability to increase database throughput — reads per second, writes per second, or data volume — without rewriting your application. The critical distinction: read scaling (adding replicas) and write scaling (sharding or distributed SQL) require completely different architectural approaches. Choosing the wrong path creates technical debt that takes months to unwind. ...

Answer-first: Để xử lý 7.8 tỷ giao dịch/năm cho 70 triệu người dùng, PayPay chuẩn hóa hơn 200 microservices trên Kubernetes qua GitOps (ArgoCD), phân mảnh Kafka topic theo User ID kết hợp Redis SETNX bảo đảm idempotency tài chính, và thay thế MySQL bằng TiDB NewSQL phân tán hỗ trợ ACID đa node cùng TiFlash HTAP. 🇬🇧 Read the English version of this article on tanhdev.com PayPay vừa bấm nút chạy hồi tháng 10 năm 2018 thì đã đạt 10 triệu người dùng chỉ trong vỏn vẹn 3 tháng — tốc độ tăng trưởng kỷ lục chưa từng có tại thị trường fintech Nhật Bản. Đến năm 2025, nền tảng này đã cán mốc 70 triệu user đăng ký và xử lý 7.8 tỷ lượt thanh toán mỗi năm. Hỗ trợ cho sự tăng trưởng vượt bậc đó là một đội ngũ kỹ sư không chỉ mở rộng hạ tầng mà còn tái cấu trúc văn hóa kỹ thuật: từ chuẩn hóa dịch vụ (service standardization) và triển khai GitOps (GitOps-driven deployments) cho đến kiểm thử độ bền (chaos engineering) và ứng dụng AI phát hiện lừa đảo (fraud detection). ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Scaling a relational database is one of the most demanding challenges in system design. As applications grow from thousands to millions of active users, the database ceases to be a simple storage engine and becomes the primary bottleneck of the entire system architecture. In this technical guide, we explore the architectural progression of scaling MySQL—beginning with replication topologies, stepping through the complexities and operational hazards of manual database sharding (including proxy middleware like Vitess), and evaluating NewSQL alternatives, specifically the distributed architecture of TiDB. ...