🇬🇧 Read the English version of this article on tanhdev.com

Thay Thế MySQL Sharding Bằng TiDB: Hướng Dẫn Kiến Trúc Distributed SQL Toàn Diện

Answer-first: TiDB là giải pháp NewSQL mã nguồn mở hàng đầu thay thế MySQL Sharding truyền thống, loại bỏ sự phức tạp của proxy bằng kiến trúc phân vùng tự động. Bằng cách phân tán các Raft Region 96MB qua TiKV và giao thức Percolator, TiDB đảm bảo mở rộng ghi ngang, ACID phân tán và online DDL không downtime.

Điều kiện tiên quyết: Hiểu biết cơ bản về mô hình nhân bản MySQL, kỹ thuật sharding và kết nối cơ sở dữ liệu trong Go.

Khi một hệ thống phần mềm tăng trưởng từ vài ngàn lên hàng chục triệu người dùng hoạt động, cơ sở dữ liệu quan hệ (RDBMS) không còn là một nơi lưu trữ thụ động mà trở thành điểm nghẽn nghiêm trọng nhất của toàn bộ kiến trúc.

Trong thế giới MySQL truyền thống, lộ trình mở rộng thường diễn ra qua các bước: Nâng cấp phần cứng máy chủ (Vertical Scaling) $\rightarrow$ Phân tách Đọc/Ghi qua Read Replicas $\rightarrow$ Phân mảnh thủ công (Manual Sharding / Vitess). Tuy nhiên, khi chạm tới ngưỡng Sharding, các kỹ sư phải đối mặt với một cơn ác mộng vận hành: Mã nguồn ứng dụng bị ô nhiễm bởi logic định tuyến Sharding Key, các câu lệnh JOIN chéo shard bị vô hiệu hóa, và giao dịch phân tán 2PC (Two-Phase Commit) làm suy giảm nghiêm trọng thông lượng ghi.

Sự trỗi dậy của công nghệ NewSQL — đại diện tiêu biểu là TiDB — mở ra một kỷ nguyên mới: Cung cấp khả năng mở rộng ghi theo chiều ngang không giới hạn (Horizontal Scalability) trong khi vẫn duy trì 100% giao thức MySQL Wire Protocol và tính toàn vẹn giao dịch ACID phân tán.

Bài viết này là một tài liệu chuyên sâu về kiến trúc: So sánh bản chất giữa Sharded MySQL (Vitess) và TiDB, giải phẫu kiến trúc 3 tầng phân tách (Stateless SQL, Placement Driver, TiKV Raft Group), cơ chế phân tích dữ liệu thời gian thực HTAP (Hybrid Transactional/Analytical Processing) với TiFlash, và cung cấp mã nguồn Golang kết nối chuẩn Production.

⚡ Tóm Tắt Kiến Trúc Cốt Lõi (Executive BLUF)

• Giải phóng tầng ứng dụng: TiDB thay thế toàn bộ middleware sharding phức tạp. Ứng dụng Go/Node.js chỉ cần kết nối tới một endpoint MySQL tiêu chuẩn duy nhất; tầng tính toán của TiDB tự động phân bổ dữ liệu thành các dải khóa liên tục 96MB (Raft Regions) trên cụm TiKV.
• Đồng thuận phân tán Multi-Raft: Mỗi Region dữ liệu được nhân bản thành 3 hoặc 5 bản sao trên các node TiKV độc lập thông qua thuật toán đồng thuận Raft. Sự cố hỏng hóc phần cứng của một node lưu trữ không gây mất mát dữ liệu và tự động bầu Leader mới trong vòng 3 giây.
• Giao dịch phân tán Percolator: TiDB triển khai mô hình Two-Phase Commit phân tán dựa trên thuật toán Google Percolator kết hợp dấu thời gian đơn điệu (Timestamp Oracle - TSO) từ Placement Driver (PD), loại bỏ hoàn toàn bộ quản lý khóa tập trung.
• Đột phá HTAP với TiFlash: Dữ liệu dòng (Row-based) từ TiKV được đồng bộ ngầm sang TiFlash (Column-based) qua cơ chế Raft Learner (không tham gia biểu quyết Quorum, zero-impact lên giao dịch OLTP). Cho phép chạy báo cáo tài chính hàng tỷ dòng trong vài trăm mili-giây trên dữ liệu sống.

1. So Sánh Kiến Trúc Toàn Diện: Primary-Replica vs Sharded MySQL (Vitess) vs TiDB

Bảng ma trận đánh giá chi tiết sự đánh đổi giữa các chiến lược mở rộng cơ sở dữ liệu quy mô lớn:

2. Giới Hạn Vật Lý Của Mô Hình MySQL Primary-Replica Truyền Thống

Trong giai đoạn đầu phát triển, giải pháp phổ biến nhất là triển khai cụm Master-Slave (Primary-Replica) để phân tách lưu lượng đọc và ghi:

flowchart TD
    APP["Tầng Ứng Dụng (Application Pods)"] -->|"Lưu lượng Ghi (INSERT/UPDATE/DELETE)"| MASTER["MySQL Primary (Master Single-Writer)"]
    APP -->|"Lưu lượng Đọc (SELECT)"| R1["MySQL Read Replica 01"]
    APP -->|"Lưu lượng Đọc (SELECT)"| R2["MySQL Read Replica 02"]
    
    MASTER -->|"Sao Chép Binlog Bất Đồng Bộ"| R1
    MASTER -->|"Sao Chép Binlog Bất Đồng Bộ"| R2

    subgraph "Điểm Nghẽn Không Thể Vượt Qua"
        BOTTLENECK["1. Giới hạn IOPS ghi của 1 ổ cứng Master\n2. Độ trễ sao chép (Replication Lag) khi chạy câu lệnh lớn\n3. Tranh chấp khóa bảng khi chạy Online DDL"]
    end

    MASTER -.-> BOTTLENECK

3 Nút Thắt Cổ Chai Của Kiến Trúc Primary-Replica

1. Nghẽn Ghi Tại Điểm Đơn Lẻ (Single Writer Bottleneck): Mọi thao tác ghi bắt buộc phải tập trung về một máy chủ Master duy nhất để bảo đảm tuần tự hóa InnoDB. Khi số lượng đơn hàng vượt quá khả năng IOPS của ổ cứng NVMe cao cấp nhất, hệ thống không thể nâng cấp thêm được nữa.
2. Độ Trễ Bản Sao (Replication Lag): Tiến trình sao chép SQL Thread trên Replicas thường xử lý chậm hơn Master khi có các câu truy vấn xóa theo lô lớn (DELETE FROM logs WHERE created_at < ...). Sự chậm trễ này khiến khách hàng vừa thanh toán thành công nhưng tải lại trang web lại thấy trạng thái đơn hàng vẫn là “Chờ thanh toán”, phát sinh hàng ngàn yêu cầu hỗ trợ giả.
3. Chi Phí Tái Phân Mảnh Thủ Công (Resharding Agony): Khi một shard bị đầy, việc chia đôi một shard MySQL cũ thành hai shard mới đòi hỏi hàng tháng trời chuẩn bị script di trú dữ liệu, đối soát hash key và tiềm ẩn nguy cơ sai lệch dữ liệu khôn lường.

3. Kiến Trúc Phân Tách 3 Tầng Của TiDB (The 3-Tier Architecture)

TiDB giải quyết triệt để sự bế tắc của mô hình cũ bằng cách phân rã hệ thống thành 3 tầng chức năng độc lập:

graph TD
    subgraph "Tầng Ứng Dụng & Client"
        CLIENTS["Go Microservices / Web Storefront"]
    end

    subgraph "Tầng 1: TiDB Server (Tầng Tính Toán Vô Trạng Thái - Stateless SQL)"
        TIDB1["TiDB Node 1 (:4000)"]
        TIDB2["TiDB Node 2 (:4000)"]
        TIDB3["TiDB Node 3 (:4000)"]
    end

    subgraph "Tầng 2: Placement Driver (Bộ Não Điều Phối & TSO)"
        PD1["PD Leader (Timestamp Oracle)"]
        PD2["PD Follower"]
        PD3["PD Follower"]
    end

    subgraph "Tầng 3: Tầng Lưu Trữ Phân Tán (Storage Tier)"
        subgraph "TiKV Cluster (Lưu Trữ Dòng - Row-based OLTP)"
            TIKV1["TiKV Node A\n(Region 1 Leader, Region 2 Follower)"]
            TIKV2["TiKV Node B\n(Region 2 Leader, Region 3 Follower)"]
            TIKV3["TiKV Node C\n(Region 3 Leader, Region 1 Follower)"]
        end

        subgraph "TiFlash Cluster (Lưu Trữ Cột - Columnar HTAP)"
            TIFLASH1["TiFlash Node 1\n(Raft Learner Asynchronous Replica)"]
        end
    end

    CLIENTS -->|MySQL Wire Protocol| TIDB1 & TIDB2 & TIDB3
    TIDB1 & TIDB2 & TIDB3 <-->|Xin cấp TSO & Bản đồ định tuyến| PD1
    TIDB1 & TIDB2 & TIDB3 <-->|gRPC Range Queries| TIKV1 & TIKV2 & TIKV3
    TIDB1 & TIDB2 & TIDB3 -.->|Chuyển tiếp câu truy vấn OLAP| TIFLASH1

    TIKV1 & TIKV2 & TIKV3 ===|Đồng thuận Multi-Raft| TIKV1 & TIKV2 & TIKV3
    TIKV1 -.->|Sao chép ngầm không biểu quyết| TIFLASH1

Chi Tiết Hoạt Động Của 3 Tầng Kiến Trúc

1. TiDB Server (Tầng Tính Toán Vô Trạng Thái):
   • Đóng vai trò như một máy chủ MySQL thông thường, lắng nghe cổng mặc định :4000.
   • Tiếp nhận kết nối từ client, phân tích cú pháp cú pháp SQL (Parser), tối ưu hóa cây thực thi (Cost-Based Optimizer) và chuyển đổi các câu lệnh SQL thành các truy vấn Key-Value dạng khoảng (Range Scans) gửi xuống TiKV.
   • Do hoàn toàn vô trạng thái (Stateless), các node TiDB có thể đặt sau một bộ cân bằng tải (HAProxy/AWS NLB) và mở rộng hàng ngang trong vài giây khi có tải đột biến.
2. Placement Driver (PD - Bộ Não Trung Tâm):
   • Quản lý toàn bộ cấu trúc liên kết mạng và siêu dữ liệu (Metadata) của cụm.
   • Đóng vai trò là Timestamp Oracle (TSO): Cấp phát các dấu thời gian logic tăng đơn điệu trên toàn cầu để phục vụ mô hình giao dịch phân tán Percolator.
   • Tự động giám sát kích thước của các Region trên TiKV: Khi một Region vượt ngưỡng 96MB - 144MB, PD sẽ phát lệnh chia đôi Region (Region Split) và tự động di chuyển bản sao sang các node TiKV đang rảnh tài nguyên để triệt tiêu các điểm nóng (Hotspots).
3. TiKV & TiFlash (Tầng Lưu Trữ Đa Mô Hình):
   • TiKV: Lưu trữ dữ liệu dạng dòng trên nền tảng RocksDB (LSM-Tree). Dữ liệu được băm nhỏ thành các đoạn liên tục gọi là Regions. Mỗi Region được bảo vệ bởi một nhóm Multi-Raft Group gồm 3 bản sao.
   • TiFlash: Lưu trữ dữ liệu dạng cột (Columnar Storage). TiFlash kết nối vào nhóm Raft của TiKV dưới vai trò Raft Learner — nó nhận dữ liệu sao chép bất đồng bộ nhưng không tham gia bỏ phiếu quorum, đảm bảo các câu truy vấn phân tích nặng nề trên TiFlash hoàn toàn không làm suy giảm hiệu năng giao dịch của TiKV.

4. Giao Dịch Phân Tán ACID: Thuật Toán Google Percolator

TiDB không sử dụng cơ chế khóa phân tán tập trung (như Zookeeper hay etcd) để khóa bảng vì sẽ tạo ra điểm nghẽn hiệu năng. Thay vào đó, TiDB triển khai biến thể tối ưu của thuật toán Percolator Two-Phase Commit:

sequenceDiagram
    autonumber
    participant Client as Ứng Dụng Go
    participant TiDB as TiDB Server
    participant PD as Placement Driver (TSO)
    participant TiKV_Pri as TiKV (Primary Lock Region)
    participant TiKV_Sec as TiKV (Secondary Lock Region)

    Client->>TiDB: Bắt đầu giao dịch: BEGIN, UPDATE...,
    TiDB->>PD: Xin cấp thời gian bắt đầu: get_start_ts()
    PD-->>TiDB: Trả về start_ts = 1000
    
    rect rgb(235, 245, 255)
        Note over TiDB, TiKV_Sec: GIAI ĐOẠN 1: PREWRITE (GHI TẠM & KHÓA)
        Note over TiDB: Chọn 1 khóa làm Primary Lock, các khóa khác là Secondary Locks
        TiDB->>TiKV_Pri: Prewrite(PrimaryKey, start_ts=1000, value, Lock=Primary)
        TiKV_Pri-->>TiDB: ✅ Ghi thành công vào RocksDB Lock CF
        TiDB->>TiKV_Sec: Prewrite(SecondaryKey, start_ts=1000, value, LockTrỏTớiPrimary)
        TiKV_Sec-->>TiDB: ✅ Ghi thành công
    end

    Client->>TiDB: Cam kết giao dịch: COMMIT,
    
    rect rgb(235, 255, 235)
        Note over TiDB, TiKV_Sec: GIAI ĐOẠN 2: COMMIT (XÁC NHẬN NGUYÊN TỬ)
        TiDB->>PD: Xin cấp thời gian cam kết: get_commit_ts()
        PD-->>TiDB: Trả về commit_ts = 1005
        TiDB->>TiKV_Pri: Commit(PrimaryKey, commit_ts=1005)
        TiKV_Pri-->>TiDB: ✅ Xóa Lock CF, ghi commit marker vào Write CF
        Note over TiDB: ĐIỂM CAM KẾT LOGIC THÀNH CÔNG! Trả về 200 OK cho Client
        TiDB-->>Client: Transaction Committed!
        
        Note over TiDB, TiKV_Sec: Mở khóa các Secondary Keys diễn ra bất đồng bộ ngầm
        TiDB-.->TiKV_Sec: AsyncCommit(SecondaryKey, commit_ts=1005)
    end

Nhờ mô hình này, chỉ cần Primary Lock được cam kết thành công trên TiKV, toàn bộ giao dịch phân tán được coi là thành công tuyệt đối. Nếu một tiến trình đọc khác gặp phải một Secondary Lock chưa kịp mở, nó chỉ cần tra cứu ngược về trạng thái của Primary Lock để quyết định đọc dữ liệu mới hay cũ mà không bao giờ bị nghẽn deadlock.

5. Cài Đặt Mã Nguồn Production: Go Connection Pool Kết Nối TiDB

Do tính chất phân tán, các giao dịch trong TiDB có thể gặp hiện tượng xung đột phiên bản ghi (Write Conflict) nếu hai luồng cùng cố gắng cập nhật một bản ghi. Mã nguồn Golang 1.24+ dưới đây thiết lập kết nối chuẩn mực, cấu hình Connection Pooling tối ưu cho TiDB và cài đặt Transaction Retry Handler có độ trễ lùi ngẫu nhiên:

// Package database triển khai kết nối cơ sở dữ liệu phân tán TiDB chuẩn Production.
// Hỗ trợ cấu hình tối ưu connection pool và cơ chế tự động thử lại khi gặp xung đột phân tán.
package database

import (
	"context"
	"database/sql"
	"errors"
	"fmt"
	"log"
	"math/rand"
	"time"

	_ "github.com/go-sql-driver/mysql"
)

// TiDBConfig cấu hình kết nối tới cụm TiDB
type TiDBConfig struct {
	Host         string
	Port         int
	User         string
	Password     string
	Database     string
	MaxOpenConns int
	MaxIdleConns int
}

// TiDBManager quản lý kết nối và thực thi giao dịch phân tán an toàn
type TiDBManager struct {
	db *sql.DB
}

func NewTiDBManager(cfg TiDBConfig) (*TiDBManager, error) {
	// TiDB yêu cầu các tham số tối ưu hóa kết nối MySQL driver:
	// - interpolateParams=true: Tăng tốc độ chuẩn bị câu lệnh trên TiDB
	// - parseTime=true: Tự động chuyển đổi kiểu ngày tháng
	dsn := fmt.Sprintf("%s:%s@tcp(%s:%d)/%s?charset=utf8mb4&parseTime=true&interpolateParams=true&timeout=5s&readTimeout=10s&writeTimeout=10s",
		cfg.User, cfg.Password, cfg.Host, cfg.Port, cfg.Database)

	db, err := sql.Open("mysql", dsn)
	if err != nil {
		return nil, fmt.Errorf("không thể mở kết nối TiDB: %w", err)
	}

	// Tinh chỉnh thông số Connection Pool cho kiến trúc phân tán
	db.SetMaxOpenConns(cfg.MaxOpenConns)
	db.SetMaxIdleConns(cfg.MaxIdleConns)
	db.SetConnMaxLifetime(30 * time.Minute)
	db.SetConnMaxIdleTime(5 * time.Minute)

	ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
	defer cancel()

	if err := db.PingContext(ctx); err != nil {
		return nil, fmt.Errorf("ping kiểm tra cụm TiDB thất bại: %w", err)
	}

	log.Println("✅ Kết nối thành công tới cụm Distributed SQL TiDB!")
	return &TiDBManager{db: db}, nil
}

// ExecuteWithRetry thực thi một hàm giao dịch với cơ chế tự động thử lại khi gặp xung đột phân tán
func (m *TiDBManager) ExecuteWithRetry(ctx context.Context, maxRetries int, fn func(tx *sql.Tx) error) error {
	var err error
	for attempt := 1; attempt <= maxRetries; attempt++ {
		err = m.runTransaction(ctx, fn)
		if err == nil {
			return nil
		}

		// Kiểm tra xem lỗi có phải do xung đột ghi phân tán (Error 9007 / Error 1105)
		if isTiDBRetryableError(err) {
			jitter := time.Duration(rand.Intn(20)) * time.Millisecond
			backoff := time.Duration(1<<attempt)*25*time.Millisecond + jitter
			log.Printf("⚠️ Gặp xung đột giao dịch TiDB (Lần %d/%d). Thử lại sau %v... Lỗi: %v",
				attempt, maxRetries, backoff, err)

			select {
			case <-ctx.Done():
				return ctx.Err()
			case <-time.After(backoff):
				continue
			}
		}

		// Lỗi logic nghiệp vụ không thể thử lại
		return err
	}

	return fmt.Errorf("giao dịch thất bại sau %d lần thử lại: %w", maxRetries, err)
}

func (m *TiDBManager) runTransaction(ctx context.Context, fn func(tx *sql.Tx) error) error {
	tx, err := m.db.BeginTx(ctx, &sql.TxOptions{
		Isolation: sql.LevelRepeatableRead,
	})
	if err != nil {
		return err
	}

	defer func() {
		if p := recover(); p != nil {
			_ = tx.Rollback()
			panic(p)
		}
	}()

	if err := fn(tx); err != nil {
		_ = tx.Rollback()
		return err
	}

	return tx.Commit()
}

// isTiDBRetryableError nhận diện các mã lỗi có thể thử lại trong hệ thống phân tán
func isTiDBRetryableError(err error) bool {
	if err == nil {
		return false
	}
	errStr := err.Error()
	// Các mã lỗi đặc trưng của TiDB: Write Conflict, Lock Wait Timeout, Region Unavailable
	return errors.Is(err, sql.ErrTxDone) ||
		contains(errStr, "Write conflict") ||
		contains(errStr, "Lock wait timeout") ||
		contains(errStr, "Region is unavailable") ||
		contains(errStr, "try again later")
}

func contains(s, substr string) bool {
	return len(s) >= len(substr) && (s == substr || len(substr) > 0 && s[:len(substr)] == substr)
}

6. Lộ Trình Di Trú Không Downtime (Zero-Downtime Migration Playbook)

Quy trình chuyển đổi an toàn từ cơ sở dữ liệu MySQL nguyên khối sang cụm TiDB NewSQL:

flowchart LR
    subgraph Giai_o_n_1_ng_B_L_ch_S_ ["Giai Đoạn 1: Đồng Bộ Lịch Sử"]
        SRC["MySQL Đang Chạy (Source)"] -->|Dumpling Export| DUMP["Tệp SQL / CSV Snapshots"]
        DUMP -->|"TiDB Lightning (Physical Mode)"| TARGET["Cụm TiDB Mới (Target)"]
    end

    subgraph Giai_o_n_2_ng_B_Th_i_Gian_Th_c ["Giai Đoạn 2: Đồng Bộ Thời Gian Thực"]
        SRC -->|Đọc MySQL Binlog| DM["TiDB Data Migration (DM Engine)"]
        DM -->|"Replicate Liên Tục (<100ms lag)"| TARGET
    end

    subgraph Giai_o_n_3_Chuy_n_i_L_u_L_ng_Cutover_ ["Giai Đoạn 3: Chuyển Đổi Lưu Lượng (Cutover)"]
        GW["API Gateway / ProxySQL"] -->|1. Trỏ 10% lưu lượng Đọc| TARGET
        GW -->|2. Trỏ 100% lưu lượng Đọc| TARGET
        GW -->|"3. Đổi DNS lưu lượng Ghi (Downtime < 10s)"| TARGET
    end

1. Bước 1: Tải dữ liệu ban đầu bằng TiDB Lightning: Sử dụng chế độ Physical Import Mode để phân tích tệp dump và ghi trực tiếp các tệp SST vào tầng TiKV, đạt tốc độ nhập liệu lên tới 250 GiB/giờ trên mỗi node.
2. Bước 2: Bắt kịp dữ liệu thời gian thực bằng TiDB Data Migration (DM): DM kết nối như một Slave đọc MySQL binlog, đồng bộ liên tục các giao dịch phát sinh trong quá trình nhập liệu ban đầu cho đến khi độ trễ sao chép giảm về 0.
3. Bước 3: Chuyển đổi lưu lượng từng bước (Canary Cutover): Định tuyến các truy vấn đọc nặng của hệ thống phân tích sang TiFlash trước; khi hệ thống vận hành ổn định trong 14 ngày, tiến hành chuyển đổi cổng ghi tại API Gateway.

7. Benchmark Tải Đỉnh Đọc/Ghi 100 Triệu Bản Ghi (Sysbench OLTP & TPC-C)

Dưới đây là kết quả kiểm thử thực nghiệm tải đỉnh bằng công cụ chuẩn công nghiệp Sysbench và TPC-C trên tập dữ liệu 100 triệu bản ghi giao dịch thương mại điện tử:

8. Các Câu Hỏi Thường Gặp (FAQ)

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

• Hướng Dẫn Toàn Diện Mở Rộng Cơ Sở Dữ Liệu MySQL — Chiến lược từ Index B+Tree đến Sharding.
• MySQL Horizontal Scaling: Vitess & GORM Sharding — Kỹ thuật băm dữ liệu và định tuyến shards.
• Kiến Trúc Mở Rộng Hệ Thống PayPay Nhật Bản — Cách PayPay xử lý hàng trăm ngàn TPS thanh toán trên TiDB.
• Database Impact on Programming Languages — Tác động của kiến trúc dữ liệu đối với thiết kế hệ thống.
• Đồng Bộ Tồn Kho Thời Gian Thực Với Kafka, Debezium & Redis — CDC đồng bộ dữ liệu giao dịch đa tầng.