Lời mở đầu

Những điều cần cân nhắc trước khi áp dụng Sharding

• Sử dụng cấu trúc Master-Slave (hoặc Master-Master) để phân tách lưu lượng đọc (Read) và ghi (Write).
• Hầu hết các tải (load) thường đến từ việc đọc dữ liệu, nên việc mở rộng Read Replica thường giải quyết được phần lớn vấn đề hiệu năng.
  2. Phân vùng bảng (Table Partitioning)

• Chia nhỏ một bảng lớn thành các phân vùng (partition) dựa trên thời gian hoặc phạm vi dữ liệu.
• Giúp giảm kích thước index và tăng tốc độ truy vấn trên các tập dữ liệu con.

Cốt lõi của cấu trúc Sharding

• Đây là yếu tố quan trọng nhất. Shard Key quyết định dữ liệu sẽ nằm ở node nào.
• Cần chọn key sao cho dữ liệu được phân bố đều (tránh hot-spot) và các truy vấn thường xuyên nhất có thể định tuyến trực tiếp đến một shard cụ thể.
  2. Cách xác định Shard (Shard Decision)

• Algorithmic (Ví dụ: Modulo): id % số_lượng_shard. Đơn giản, phân bố đều, nhưng khó mở rộng số lượng shard sau này (cần re-sharding).
• Dynamic (Directory-based): Lưu bảng ánh xạ (lookup table) xem ID nào nằm ở shard nào. Linh hoạt, dễ mở rộng, nhưng bảng ánh xạ có thể trở thành điểm nghẽn (SPOF).
  3. Phương thức định tuyến (Routing Implementation)

• Client-side: Ứng dụng tự biết phải kết nối đến DB nào.
• Proxy-side: Ứng dụng kết nối qua một Proxy (như ProxySQL, ShardingSphere), Proxy sẽ lo việc định tuyến.

Khi nào thì cần Sharding?

• Dữ liệu vượt quá dung lượng lưu trữ của một node đơn lẻ.
• Lượng ghi (Write throughput) vượt quá khả năng xử lý của Master node.
• Chỉ số IOPS hoặc kết nối mạng bị bão hòa.
  Ví dụ cấu hình và mã nguồn (Kotlin/Spring)

Ví dụ định tuyến Sharding dựa trên Kotlin + Coroutine

// (Mã giả định tuyến)
suspend fun <T> withShard(shardKey: Long, block: suspend () -> T): T {
    val shardIndex = shardKey % 2 // Ví dụ dùng Modulo
    return withContext(ShardContext(shardIndex)) {
        block()
    }
}

Spring + AbstractRoutingDataSource (Cách tiếp cận JDBC)

Transaction trong môi trường Sharding

// Ví dụ: Chỉ cập nhật dữ liệu user trên 1 shard
transactionalOperator.executeAndAwait { tx ->
    // Logic update user...
    // Update count...
    // Tất cả đều nằm trên cùng 1 shard dựa trên userId
}

suspend fun transferBalance(senderId: Long, receiverId: Long, amount: Long): Boolean {
    // 1. Trừ tiền người gửi (Shard A)
    // 2. Cộng tiền người nhận (Shard B)
    // Nếu bước 2 lỗi -> Phải hoàn lại tiền cho người gửi (Bước bù trừ)
}

Mối quan hệ giữa MSA và Sharding

Chiến lược Vertical Slicing + Kết nối DB

• base-db-client → Dành cho các domain dùng Single DB.
• sharded-db-client → Dành cho domain cần Sharding (có logic định tuyến).
• Sử dụng chung interface UserRepository và dùng Dependency Injection (DI) để phân chia.

Vượt ra khỏi MSA: Cấu trúc Nano Service + BFF

• Số lượng service tăng -> Vận hành phức tạp.
• Logic tổng hợp dữ liệu bị phân tán -> API cho UI bị chậm.
• Giải pháp có thể là Nano Service + BFF (Backend for Frontend).

• Nano Service: Chỉ chịu trách nhiệm nguyên tử (atomic), ví dụ: user-profile, user-preference.
• BFF: Chịu trách nhiệm gọi và tổng hợp dữ liệu từ các nano service để trả về định dạng tối ưu cho Client.
• Việc Sharding hay không được ẩn bên dưới Nano Service, BFF không cần quan tâm.

Tổng kết

• Sharding không phải là tính năng "phải có", mà là lựa chọn cuối cùng.
• Hãy thử Cấu hình MMM + Partitioning + Tuning trước.
• Khi áp dụng Sharding, cần thiết kế kỹ về: Shard Key, Chiến lược định tuyến, Transaction, và Tự động hóa vận hành.
• Trong MSA, quyết định Sharding nên nằm ở phạm vi từng Service riêng biệt.
• Sử dụng cấu trúc Vertical Slice để tách biệt độ phức tạp.
• Đẩy việc tổ hợp dữ liệu phức tạp lên BFF hoặc Client.