Database Architecture 2: Replication - Đánh Đổi Giữa Nhất Quán Và Tốc Độ
Product Decode
•
1. Nút Thắt Khả Năng Đọc (The Read Bottleneck)
Ở bài trước, chúng ta đã thiết lập một node "Standby" chỉ để dự phòng (Failover) khi Primary chết. Nhưng trong thế giới thực, việc để một server cấu hình khủng chỉ "ngồi chơi xơi nước" chờ ngày Primary sập là một sự lãng phí tài nguyên khổng lồ.
Hơn nữa, phần lớn các sản phẩm công nghệ (E-commerce, Social Media, SaaS) đều có tỷ lệ Đọc/Ghi (Read/Write Ratio) cực kỳ lệch. Shopee hay Facebook có thể có tỷ lệ Đọc/Ghi lên tới 100:1 — cứ 1 người đăng bài/đặt hàng thì có 100 người lướt xem.
Khi hệ thống chạm ngưỡng 10,000 Requests/giây (RPS), Primary DB sẽ bốc khói vì cạn kiệt IOPS. Giải pháp thực chiến của các Senior Engineer không phải là mua một server to hơn, mà là kích hoạt Read Replication (Single-leader Model): Biến các node Standby thành các Replicas để gánh vác toàn bộ traffic Đọc (Read Traffic).
The PM Trade-off: Việc tách biệt Read/Write mang lại khả năng mở rộng (Scalability) gần như vô hạn cho trải nghiệm lướt/xem. Tuy nhiên, nó đưa chúng ta vào một bài toán đánh đổi kinh điển của Hệ thống phân tán: Chọn Tốc độ hay Chọn Sự Nhất Quán?
2. Bài Toán Đánh Đổi Lớn Nhất: Sync vs. Async Replication
Khi Primary nhận một lệnh Write, nó phải chuyển dữ liệu đó sang các Replicas. Cách nó thực hiện việc này quyết định sinh mệnh của Business.
Anti-Pattern: Nhất quán mù quáng
Newbie PM: "Hệ thống của chúng ta không được phép sai lệch dữ liệu. Hãy yêu cầu team Tech cấu hình đồng bộ (Sync) 100% cho mọi tính năng để đảm bảo tính nhất quán!"
Thực tế tàn khốc: Nếu áp dụng Sync Replication cho nút "Like" hoặc "View", thời gian phản hồi (Latency) sẽ tăng từ 15ms lên 300ms+. Trải nghiệm ứng dụng sẽ giật lag, và khi lượng truy cập tăng vọt, toàn bộ hệ thống sập vì các tiến trình Write bị treo (Blocked) chờ Replicas xác nhận.
Các hệ thống trưởng thành luôn chia nhỏ mức độ ưu tiên theo Business Domain:
Chiến lược
Cơ chế hoạt động
Tác động Business / Metrics
Use Case Điển Hình
Synchronous (Đồng bộ)
Primary phải đợi Replica xác nhận đã ghi xong mới báo thành công cho User.
Latency cao (xấu). Consistency tuyệt đối. Không mất 1 đồng nào nếu hệ thống sập.
Giao dịch lõi (Core Payment), Chuyển tiền ngân hàng.
Asynchronous (Bất đồng bộ)
Primary ghi xong báo thành công ngay lập tức. Đẩy dữ liệu qua Replica sau dưới dạng background.
Latency cực thấp (tốt). Nguy cơ mất dữ liệu (Data Loss) nếu Primary sập trước khi kịp đồng bộ.
Nút Like, Lướt Feed, Load danh mục sản phẩm.
3. Hệ Lụy Của Tốc Độ: Thảm Họa Replication Lag
Nếu bạn chọn Async (và 90% hệ thống ngoài kia chọn Async cho các tính năng phi tài chính), bạn sẽ phải đối mặt với Replication Lag (Độ trễ sao chép).
Replication Lag xảy ra khi Replica không theo kịp tốc độ Ghi của Primary. Hậu quả trực diện nhất đến User UX là lỗi "Stale Data" — người dùng thực hiện một hành động, nhưng ngay sau đó lại không thấy kết quả của hành động đó.
Kịch bản gây bực bội:
Khách hàng cập nhật ảnh đại diện mới (Write -> Primary: Thành công).
Họ được chuyển hướng về trang cá nhân và ứng dụng tự động load lại thông tin (Read -> Replica).
Do Replica đang bị lag 2 giây, nó trả về ảnh đại diện cũ.
Khách hàng nghĩ app bị lỗi, nhấn đổi ảnh thêm 3 lần nữa, tạo ra ticket phàn nàn chửi bới lên CSKH.
4. Giải Pháp Thực Chiến: Cứu Vãn UX Với "Read-Your-Own-Writes"
Để giải quyết tình trạng trên mà không cần phải hi sinh tốc độ của Async Replication, chúng ta không dùng cách "ép toàn bộ hệ thống phải Sync". Thay vào đó, ta áp dụng một Business Rule ở tầng Application (Code) gọi là: Read-your-own-writes (Đọc dữ liệu vừa ghi).
Cơ chế cực kỳ tinh tế: Chúng ta ưu tiên sự nhất quán cho chính người vừa thực hiện thao tác, còn những người khác trên mạng lưới vẫn có thể nhìn thấy dữ liệu cũ trong vài giây (Eventual Consistency).
Bằng cách này, khách hàng vừa đổi ảnh sẽ luôn thấy ảnh mới, trong khi 1 triệu người dùng khác đang lướt profile của họ vẫn chỉ đang truy vấn từ Replicas, giúp Primary DB không bị quá tải.
5. Audit Hệ Thống Với Framework PEUF
Khả năng mở rộng càng cao, điểm mù vận hành càng lớn. Dưới đây là cách dùng PEUF để rà soát rủi ro của kiến trúc Replication:
[P] Permission (Cấu trúc phân quyền & Write ngầm):
Rủi ro: Kỹ sư Data/BI lén chạy các script dọn dẹp dữ liệu (Clean-up jobs) với cờ force_write trực tiếp lên một Replica. Điều này phá vỡ tính đồng nhất của Replication topology, khiến dữ liệu giữa Primary và Replica vĩnh viễn sai lệch.
Giải pháp: Cấu hình phần quyền cứng (Hard Config) ở mức độ Database: Biến mọi Replicas thành trạng thái READ_ONLY = ON. Mọi tài khoản, dù là Admin, cũng không thể thực hiện lệnh INSERT/UPDATE/DELETE trên Replica.
Rủi ro: Đội Marketing yêu cầu chạy một chiến dịch "Cộng 10 điểm thưởng cho 5 triệu user" vào lúc nửa đêm (1 lệnh Update cực lớn). Lệnh này chạy trên Primary mất 30 phút. Hậu quả: Replication bị kẹt 30 phút, mọi Replica đều trả về dữ liệu cũ, hệ thống báo động đỏ.
Giải pháp: Không bao giờ chạy Massive Batch Update trong mô hình Replication. Phải có quy tắc Chunking: Chia 5 triệu rows thành 50,000 batch nhỏ, mỗi batch nghỉ (sleep) 50ms để cho phép Replication "thở" và đồng bộ kịp thời.
[U] Unavailability (Primary chết đột ngột trong Async mode):
Rủi ro: Primary bị cháy ổ cứng vật lý. Chế độ Failover tự động kích hoạt đưa Replica lên thay. Tưởng chừng êm đẹp, nhưng hệ thống bị mất vĩnh viễn 2 giây dữ liệu giao dịch cuối cùng (do chưa kịp Async qua).
Giải pháp: Chấp nhận rủi ro mất mát này (RPO > 0) cho các luồng non-critical. Nhưng với luồng Core Payment, bắt buộc thiết kế cơ chế Reconciliation (Đối soát) tự động với Gateway thanh toán (như Stripe/VNPay) để quét và đắp lại các transaction bị thất lạc.
[F] Fraud / Abuse (Tấn công làm kiệt quệ Replica):
Rủi ro: Đối thủ dùng Botnet để Scrape (cào) toàn bộ danh mục sản phẩm. Hàng triệu request Đọc ập vào các Replicas, đẩy CPU Replicas lên 100%. Replication Lag tăng phi mã, người dùng thật bị từ chối phục vụ.
Giải pháp: Sử dụng Load Balancer thông minh. Nếu phát hiện một Replica bị Lag quá mức cho phép (VD: Replica_Lag > 5s), tự động rút Replica đó ra khỏi pool nhận traffic để nó có thời gian bắt kịp Primary, thay vì tiếp tục dồn traffic vào đánh chết nó.
6. Lời Kết: Sự Ảo Tưởng Về Tính An Toàn Tuyệt Đối
Với Replication và chiến lược "Read-your-own-writes", chúng ta đã giải quyết trọn vẹn bài toán mở rộng tải trọng Đọc (Read Scalability) đồng thời che giấu được độ trễ hệ thống khỏi trải nghiệm người dùng.
Đến bước này, nhiều PM thường rơi vào một ảo tưởng chết người: *"Hệ thống đã có 3 bản sao chép dữ liệu liên tục, chúng ta không bao giờ lo mất dữ liệu nữa"*. Thực tế, Replication chỉ bảo vệ bạn khỏi lỗi phần cứng. Nếu một kỹ sư lỡ tay chạy lệnh xóa nhầm, Replication sẽ "nhân bản" thảm họa đó ra toàn bộ cụm server chỉ trong vài mili-giây, xóa sạch mọi thứ. Để thực sự cứu vãn sinh mệnh doanh nghiệp trước thảm họa do con người và mã độc, bạn cần một cỗ máy thời gian. Hãy tiếp tục với Bài 3: Backup & PITR: Làm Chủ RPO, RTO Và Khôi Phục Thảm Họa.
System ConceptApr 20, 2026
Database Architecture 4: Sharding: Phá Vỡ Giới Hạn Vật Lý & Nỗi Đau Vận Hành
Khi hệ thống chạm ngưỡng giới hạn Ghi (Write limit), Replication trở nên vô dụng. Khám phá chiến lược chọn Shard Key, cách né thảm họa Hotspot và những mặt tối đắt đỏ của Sharding.
