Đã đăng vào khoảng 22 giờ trước 9 phút đọc

🏗️🧠 Replication & Sharding: database scale lên hàng trăm triệu user thế nào? - System Design P19

Replication & Sharding: Khi "Thêm Máy" Không Còn Là Lời Giải Duy Nhất cho Bài Toán Scale

1. Mở đầu: Câu chuyện về "Bức tường" Performance

Bạn đã bao giờ đứng nhìn dashboard giám sát đỏ rực với latency ở phân vị p99 nhảy vọt, trong khi CPU của database server chạm ngưỡng 95% bất kể bạn đã nâng cấp cấu hình lên mức cao nhất hiện có trên Cloud?

Đó là kịch bản kinh điển của một hệ thống SaaS hoặc Ecommerce đang tăng trưởng nóng. Ban đầu, mọi bài toán đều được giải quyết bằng "tiền": nâng cấp CPU, thêm RAM, đổi sang ổ SSD xịn nhất (Vertical Scaling). Nhưng rồi, bạn đâm sầm vào một "Bức tường" Performance. Bạn nhận ra rằng việc ném thêm tiền vào phần cứng không còn mang lại hiệu năng tương xứng, và nhà cung cấp Cloud cũng đã hết "hàng" để bạn nâng cấp.

Cảm giác bất lực khi database "khóc" dù đang chạy trên một con server "khủng" nhất chính là lúc một kỹ sư hệ thống phải từ bỏ tư duy node đơn để bước vào thế giới của hệ thống phân tán. Đây không còn là bài toán về phần cứng, mà là bài toán về kiến trúc.

2. Phá vỡ lầm tưởng: Database Scale không phải là một nút bấm

Sự ngây thơ lớn nhất của nhiều kỹ sư là đánh đồng việc scale database với scale ứng dụng (Stateless App). Với ứng dụng, bạn chỉ cần bấm nút thêm máy (Horizontal Scaling) là xong. Nhưng database là Stateful. Dữ liệu có tính kế thừa, phụ thuộc lẫn nhau và đòi hỏi sự toàn vẹn. Việc tách dữ liệu ra nhiều nơi mà vẫn đảm bảo chúng "nhìn về một hướng" là cái giá cực kỳ đắt về cả thời gian lẫn công sức vận hành.

Trong thực tế, một hệ thống sẽ lần lượt chạm tới 3 loại "trần" (bottlenecks) mà nếu không nhận diện đúng, bạn sẽ lãng phí tài nguyên vô ích:

Read throughput: Lượng truy vấn đọc (SELECT) quá lớn.
Write throughput: Tần suất ghi (INSERT/UPDATE/DELETE) vượt quá khả năng lock và commit của một node.
Storage capacity: Dữ liệu phình to vượt quá giới hạn vật lý của một ổ đĩa, khiến việc backup/restore trở thành thảm họa.

Để phá vỡ những trần này, chúng ta có hai vũ khí: Replication và Sharding. Chúng không thay thế nhau, chúng giải quyết những vấn đề khác nhau.

3. Replication: Chiến thần "Read-Scaling" và cái bẫy "Replica Lag"

Replication (Nhân bản) là kỹ thuật sao chép dữ liệu từ một node chính ra nhiều node phụ. Dựa trên nền tảng của Episode 18: Leader Election, hệ thống sẽ bầu ra một Leader (Master) để nhận mọi yêu cầu ghi, và các Followers (Slaves) sẽ nhận nhiệm vụ phục vụ các yêu cầu đọc.

Chiến thuật này là "cứu cánh" cho các hệ thống Read-heavy (như mạng xã hội, tin tức), nơi traffic đọc gấp hàng trăm lần ghi. Nhưng, Replication không phải "phép màu" miễn phí. Vết sẹo lớn nhất của nó chính là Replica Lag.

Chuyện gì xảy ra khi user vừa cập nhật profile (ghi vào Leader), ngay lập tức refresh và request đọc lại rơi vào một Follower chưa kịp đồng bộ xong? User sẽ thấy dữ liệu cũ (Stale data). Lúc này, với tư cách Architect, bạn phải ra quyết định: Bạn thà để user thấy dữ liệu cũ trong vài giây (Stale) hay thà để hệ thống ngừng phục vụ (Downtime)? Đây là sự đánh đổi trực diện giữa Performance và Consistency.

4. Sharding: Khi dữ liệu quá lớn để nằm chung một giỏ

Khi Replication đã giúp bạn giải quyết bài toán đọc, nhưng lượng ghi vẫn quá tải hoặc ổ đĩa đã cạn kiệt, đó là lúc bạn cần đến "vũ khí hạng nặng": Sharding (Horizontal Partitioning).

Nếu Replication là "nhân bản", thì Sharding là "chia cắt". Bạn chia nhỏ một bảng dữ liệu khổng lồ thành nhiều mảnh (shards), mỗi mảnh nằm trên một server vật lý riêng biệt. Lúc này, cả Write throughput và Storage đều được scale theo chiều ngang.

Tuy nhiên, Sharding là một "cơn ác mộng vận hành" thực sự vì:

Re-balancing: Khi một shard đầy, việc chia nhỏ nó ra tiếp và di chuyển dữ liệu giữa các server đang chạy là một cực hình.
Backup/Restore phân tán: Bạn không thể snapshot toàn bộ DB cùng lúc một cách dễ dàng như trước. Việc đảm bảo bản backup của shard A khớp với shard B tại cùng một thời điểm là bài toán cực khó.

5. Nghệ thuật chọn Shard Key: Quyết định định đoạt số phận hệ thống

Shard Key là tiêu chí cốt tử để quyết định dữ liệu sẽ trôi về đâu. Chọn sai Shard Key, bạn sẽ đối mặt với Hot Shard (một máy gánh 80% traffic trong khi máy khác chơi không) hoặc Cross-shard Query (truy vấn tốn kém phải quét qua tất cả server để lấy dữ liệu).

Một yếu tố mà các kỹ sư thường bỏ qua là Cardinality (Số lượng giá trị duy nhất của Key). Nếu bạn chọn Shard Key có Cardinality thấp (ví dụ: giới tính), hệ thống sharding của bạn sẽ thất bại ngay lập tức vì dữ liệu chỉ có thể chia làm 2-3 mảnh, không thể scale thêm.

Tiêu chí	Hash-based Sharding	Range-based Sharding
Cơ chế	Dùng hàm Hash trên Shard Key	Chia dựa trên khoảng giá trị (A-M, N-Z)
Phân bổ workload	Rất đồng đều, tránh Hot Shard tốt	Dễ bị tập trung vào shard chứa dữ liệu mới nhất
Truy vấn khoảng	Rất tệ (phải fan-out tới mọi shard)	Rất tốt (dữ liệu liên quan nằm gần nhau)
Growth Potential	Thấp (thêm máy phải re-hash lại cực khổ)	Cao (dễ dàng tách/thêm khoảng giá trị mới)
Cardinality yêu cầu	Phải cao để phân tán đều	Trung bình đến cao

6. Ma trận Đánh đổi (The Trade-off Matrix)

Tư duy Senior Architect nằm ở việc nhìn thấu sự đánh đổi, không phải chọn công nghệ vì nó "ngầu".

Tiêu chí	Replication	Sharding
Mục tiêu chính	Scale Read throughput	Scale Write throughput & Capacity
Độ phức tạp ứng dụng	Thấp (chỉ cần Read/Write splitting)	Rất cao (phải xử lý routing, join dữ liệu)
Vận hành	Trung bình (quản lý lag, failover)	Rất khó (re-balancing, distributed backup)
Chi phí phần cứng	Tăng theo số lượng bản sao	Tăng theo số lượng phân mảnh
Rủi ro dữ liệu	Stale read (mất tính nhất quán tạm thời)	Mất tính nhất quán khi giao dịch chéo shard

7. Góc nhìn Senior: Đừng Sharding quá sớm

Sai lầm đắt giá nhất của các kỹ sư là "sharding hóa" hệ thống khi chưa thực sự chạm ngưỡng. Sharding làm tăng độ phức tạp kiến trúc và mở rộng Blast Radius (vùng ảnh hưởng khi có sự cố). Trước khi nghĩ đến Sharding, hãy đi theo lộ trình tiến hóa:

Optimize Query & Indexing: Đừng "giết" DB bằng những câu query không index.
Caching: Đưa 80% traffic đọc ra Redis/Memcached.
Read/Write Splitting: Sử dụng Replication để giải bài toán Read-heavy.
Vertical Scaling: Nâng cấp server đến mức chi phí bắt đầu tăng phi mã (tối ưu ROI).
Sharding: Đây là "lối thoát cuối cùng" khi tất cả các nỗ lực trên đã chạm ngưỡng vật lý.

8. Kết luận & Bài học thực tế (Key Takeaways)

Scale database là quản lý sự đánh đổi: Bạn không thể có mọi thứ. Chọn Performance hay Consistency? Low Latency hay High Reliability?
Hiểu traffic pattern là chìa khóa: Hệ thống của bạn là Read-heavy hay Write-heavy? Câu trả lời sẽ quyết định bạn cần Replication hay Sharding.
Shard Key là "sinh tử": Hãy tính toán kỹ về Cardinality và khả năng tăng trưởng (Growth Potential) trước khi đặt bút thiết kế. Thay đổi Shard Key khi hệ thống đang chạy giống như việc vừa lái xe 100km/h vừa sửa máy.

9. Open Loop: Bước đệm tới thế giới của Sự nhất quán

Khi chúng ta đã có nhiều bản sao dữ liệu (Replication) hoặc dữ liệu nằm rải rác (Sharding), một câu hỏi hóc búa xuất hiện: Làm sao để đảm bảo mọi node đều nhìn thấy một sự thật duy nhất? Tại sao dữ liệu đôi khi lại "nhảy múa" không nhất quán giữa các máy chủ?

Chúng ta sẽ cùng giải mã bí ẩn này trong Episode 20: Consistency Models và CAP Theorem. Hẹn gặp lại bạn để thấu hiểu tại sao "không bao giờ có bữa trưa miễn phí" trong hệ thống phân tán.