Module 2 — Tổng kết & cheat sheet
Recap replication: single/multi-leader/leaderless, replication lag + ba đảm bảo session, quorum, conflict resolution. Cheat sheet, glossary, self-assessment.
TL;DR: Module 2 dựng replication từ đơn giản tới phức tạp: single-leader (một nơi ghi, không xung đột), replication lag và ba đảm bảo sống chung với nó, multi-leader (ghi nhiều nơi, sinh xung đột), leaderless (quorum R+W>N, read repair, anti-entropy), và cách chọn theo workload. Trang này để bookmark trước khi vào partitioning.
Đã đi qua những gì
Bắt đầu bằng single-leader — một leader nhận mọi ghi, phát replication log; điểm căng nằm ở sync vs async và failover. Rồi replication lag: async làm follower trễ, sinh eventual consistency và ba nghịch lý cần chặn — read-your-writes, monotonic reads, consistent prefix reads. Multi-leader gỡ ràng buộc một-leader để lấy độ trễ/khả dụng, đổi bằng write conflict (giải bằng LWW/vector clock/CRDT). Leaderless bỏ hẳn leader, dùng quorum R+W>N cùng read repair và anti-entropy. Khép bằng khung bốn câu hỏi để chọn mô hình — và nhận ra một hệ thật thường trộn nhiều mô hình.
🗺️ Cheat sheet
| Khái niệm | Cốt lõi | Pitfall |
|---|---|---|
| Single-leader | Mọi ghi qua leader; follower áp log; đọc bản nào cũng được | Coi async ack là đã bền |
| Sync vs async | Sync = an toàn, chậm; async = nhanh, có thể mất ghi | Dùng async cho dữ liệu không được mất |
| Semi-sync | Một follower đồng bộ (đảm bảo ≥2 bản) | — |
| Failover | Leader chết → chọn follower thay | Mất ghi async + split-brain |
| Replication lag | Follower trễ hơn leader | Đọc từ follower lag ngay sau khi ghi |
| Read-your-writes | Thấy chính thứ mình vừa ghi | Đẩy mọi đọc sang follower |
| Monotonic reads | Không lùi thời gian giữa các lần đọc | Đọc luân phiên follower lag khác nhau |
| Consistent prefix | Không thấy hệ quả trước nguyên nhân | Bỏ qua khi partition |
| Write conflict | Hai leader ghi mâu thuẫn song song | LWW mặc định (mất dữ liệu) |
| Quorum R+W>N | Tập đọc/ghi giao nhau → thấy ghi mới | Coi quorum = linearizability |
| Read repair / anti-entropy | Sửa lúc đọc / đồng bộ nền (Merkle) | Chỉ dựa read repair (bỏ sót dữ liệu lạnh) |
📖 Glossary module
| Thuật ngữ | Định nghĩa 1 câu |
|---|---|
| Leader / follower | Node nhận ghi / node chỉ áp lại log và phục vụ đọc. |
| Replication log | Dòng thay đổi có thứ tự leader phát cho follower. |
| Sync / async replication | Leader chờ / không chờ follower ack trước khi báo thành công. |
| Failover | Quá trình nâng một follower lên làm leader khi leader chết. |
| Split-brain | Hai node cùng tin mình là leader → dữ liệu phân kỳ. |
| Replication lag | Khoảng follower trễ hơn leader. |
| Eventual consistency | Ngừng ghi thì các bản cuối cùng hội tụ (không hứa thời gian). |
| Read-your-writes / monotonic / consistent prefix | Ba đảm bảo session chống nghịch lý do lag. |
| Write conflict | Hai ghi song song mâu thuẫn lên cùng dữ liệu. |
| LWW | Last-write-wins — giữ ghi timestamp lớn nhất, vứt phần còn lại. |
| Quorum (R, W, N) | Số bản đọc / ghi / tổng; R+W>N đảm bảo giao nhau. |
| Read repair / anti-entropy | Hàn bản lệch lúc đọc / bằng tiến trình nền. |
| Sloppy quorum / hinted handoff | Nhận ghi vào bản tạm khi bản gốc lỗi, chuyển về sau. |
⚠️ Pitfall tổng hợp
- Async ack ≠ đã bền: báo "đã lưu" khi chưa follower nào có bản → mất khi failover. Đúng: sync/semi-sync cho dữ liệu quan trọng.
- Đọc follower lag ngay sau khi ghi: vi phạm read-your-writes → "lưu không ăn". Đúng: phân loại đọc theo mức nhất quán.
- LWW mặc định: mất dữ liệu im lặng + phụ thuộc clock skew. Đúng: chọn resolution theo bản chất dữ liệu (gộp/CRDT/để người dùng quyết).
- Quorum = linearizability: dùng leaderless cho check-and-set → sai. Đúng: thao tác cần đảm bảo tuyệt đối → consensus (Module 6).
- Một mô hình cho mọi dữ liệu / chọn theo hype: Đúng: bốn câu hỏi cho từng loại dữ liệu; bắt đầu single-leader.
✅ Self-assessment
Bạn đã đạt module này nếu trả lời được:
- So sánh được single-leader, multi-leader, leaderless theo trade-off nhất quán và khả dụng
- Nếu chưa: đọc lại bài 05 mục 1-2 và bảng so sánh.
- Giải thích được replication lag và các đảm bảo read-your-writes, monotonic reads, consistent prefix reads
- Nếu chưa: đọc lại bài 02 mục 2-5.
- Thiết kế được conflict resolution cho multi-leader và leaderless (LWW, vector clock, read repair)
- Nếu chưa: đọc lại bài 03 mục 4 và bài 04 mục 4.
🚀 What's next
Replication giữ cùng dữ liệu trên nhiều node. Nhưng khi dữ liệu quá lớn cho một node, ta phải chia nhỏ nó ra — đó là Module 3 — Phân mảnh (Partitioning). Replication và partitioning thường đi cùng nhau: mỗi partition lại được nhân bản. Bạn sẽ thấy consistent hashing (đã học ở track thuật toán) trở thành công cụ chính để quyết dữ liệu nằm ở đâu.
📚 Tài liệu mở rộng
- Sách: Designing Data-Intensive Applications (Kleppmann) — Chương 5 "Replication".
- Paper: DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (2007) — kiến trúc leaderless.
- Paper: Shapiro et al., "Conflict-free Replicated Data Types" (2011) — gộp không xung đột cho multi-leader/cộng tác.
Bài này có giúp bạn hiểu bản chất không?
Bài này đáng gửi cho bạn học cùng?
Copy link đã gắn nguồn — dán group, chat, hoặc LinkedIn.
Chọn mô hình replication theo workload
Bài tiếp Phân mảnh (partitioning)Module 3 — Phân mảnh (Partitioning): tổng quan
Thảo luận & góp ý
Hỏi đáp về bài này