Replication lag — sống chung với độ trễ giữa các bản

TL;DR: Với async replication, follower luôn trễ hơn leader một nhịp — khoảng trễ đó là replication lag. Đọc từ một follower đang lag có thể trả về dữ liệu cũ (stale). Nếu lag luôn cuối cùng bắt kịp (không có ghi mới), các bản hội tụ — gọi là eventual consistency (nhất quán rốt cuộc). Vấn đề là "rốt cuộc" có thể là vài giây, và trong khoảng đó người dùng gặp ba loại nghịch lý cần đảm bảo riêng để chặn: read-your-writes (đọc phải thấy chính thứ mình vừa ghi), monotonic reads (không thấy thời gian đi lùi), và consistent prefix reads (không thấy hệ quả trước nguyên nhân). Ba đảm bảo này không xoá lag — chúng là cách sống chung với nó mà không làm người dùng bối rối.

Bài trước dựng single-leader và chỉ ra async replication nhanh nhưng tạo khoảng trễ. Bài này đào đúng khoảng trễ đó: nó gây ra những nghịch lý gì cho người dùng, và ta chặn từng nghịch lý thế nào. Đây là kiến thức bạn dùng lại ở mọi hệ có bản sao async — kể cả leaderless ở bài sau.

1. Analogy — tin nhắn nhóm tới không đều

Trong một nhóm chat, tin nhắn tới điện thoại mỗi người trễ khác nhau tuỳ mạng. Bạn gửi "Đặt bàn 7h nhé", rồi vài giây sau mở một thiết bị khác chưa nhận kịp — và không thấy tin mình vừa gửi. Khó chịu: bạn biết mình đã gửi mà màn hình như chưa có (thiếu read-your-writes).

Tệ hơn: bạn F5 trang hai lần, lần đầu (trúng bản mới) thấy tin của An, lần sau (trúng bản cũ hơn) tin An biến mất — như thời gian đi lùi (thiếu monotonic reads). Hoặc bạn thấy câu trả lời "Ừ đồng ý" hiện trước câu hỏi "Đi ăn không?" — hệ quả trước nguyên nhân (thiếu consistent prefix reads).

2. Replication lag là gì, và vì sao "eventual" là đảm bảo yếu?

Với async, leader không chờ follower — nên tại một thời điểm, follower đã áp tới một điểm cũ hơn trong log so với leader.

flowchart LR
  L["Leader<br/>da ghi X=5"] -->|"replicate (tre)"| F["Follower<br/>con X=4 (dang lag)"]
  C["Client doc tu follower"] --> F
  F --> S["Tra ve X=4 (STALE)<br/>-> se dung khi follower bat kip"]

Khoảng cách đó là replication lag, đo bằng thời gian hoặc số thao tác. Lag bình thường vài mili-giây, nhưng khi tải cao hoặc mạng trục trặc có thể vọt lên vài giây, đôi khi phút.

Đọc từ follower đang lag trả về stale read (dữ liệu cũ). Nếu hệ ngừng nhận ghi, mọi follower cuối cùng áp hết log và hội tụ về cùng trạng thái — tính chất này gọi là eventual consistency. Nhưng chữ "eventual" (rốt cuộc) cố tình mơ hồ: không có đảm bảo về việc "rốt cuộc" là bao lâu. Với hệ tải liên tục, follower có thể luôn trễ. Eventual consistency là một đảm bảo yếu — đủ cho nhiều trường hợp, nhưng để giao diện không làm người dùng bối rối, ta cần thêm ba đảm bảo dưới đây.

3. Read-your-writes — thấy chính mình vừa ghi

Lần theo cơ chế: follower vừa bị đọc còn đang lag — nó chưa áp ghi đổi ảnh (ghi mới chỉ vào tới leader), nên trả về ảnh cũ. Người dùng thấy như thao tác lưu của mình vừa bốc hơi, dù dữ liệu thật vẫn nằm an toàn ở leader. Đảm bảo chặn đúng cảnh này là read-your-writes (đọc-thấy-ghi-của-mình): sau khi một người dùng ghi gì đó, mọi lần họ đọc lại sẽ thấy đúng thứ đó — dù có thể chưa thấy ghi mới của người khác. Nó chỉ nói về dữ liệu của chính người ghi, không phải toàn hệ — nên nó lo được ảnh của chính bạn kể cả khi follower vẫn lag với ghi của người khác.

Cách hiện thực (agnostic): với dữ liệu mà người dùng có thể tự sửa, đọc từ leader (hoặc từ follower đủ mới) trong một khoảng sau khi họ ghi; hoặc theo dõi thời điểm ghi gần nhất của người dùng và chỉ đọc từ follower đã áp qua điểm đó. Không có read-your-writes, người dùng "lưu" xong lại thấy như chưa lưu — cảm giác hệ mất dữ liệu.

4. Monotonic reads — không đi lùi thời gian

Monotonic reads đảm bảo: nếu một người dùng đọc nhiều lần, mỗi lần sau không lùi về trạng thái cũ hơn lần trước. Không cấm thấy dữ liệu cũ — chỉ cấm thấy mới rồi lại thấy cũ hơn.

Vi phạm xảy ra khi hai lần đọc trúng hai follower có lag khác nhau: lần đầu trúng follower gần bắt kịp (thấy tin mới), lần sau trúng follower lag nặng (tin mới biến mất) — như du hành ngược thời gian. Cách chặn đơn giản: cho mỗi người dùng luôn đọc từ cùng một follower (chọn theo hash user-id), để họ chỉ tiến chứ không lùi. Monotonic reads yếu hơn "luôn thấy mới nhất" nhưng đủ để trải nghiệm không phi lý.

5. Consistent prefix reads — không đảo nhân quả

Consistent prefix reads đảm bảo: nếu chuỗi ghi có quan hệ nhân quả (A trước B), thì ai đọc cũng thấy A trước B, không bao giờ thấy B mà chưa thấy A. Vi phạm cho ra cảnh "thấy câu trả lời trước câu hỏi".

Lần theo cơ chế: bản sao của P2 (chứa câu trả lời) đã tới người đọc, còn bản sao của P1 (chứa câu hỏi) vẫn đang lag — nên họ thấy câu trả lời hiện ra trước khi câu hỏi xuất hiện, đúng cảnh đảo nhân quả mà consistent prefix reads cấm. Nghịch lý này đặc biệt hay xuất hiện khi dữ liệu bị phân mảnh (partition — Module 3): các partition replicate độc lập với lag khác nhau, nên thứ tự nhân quả xuyên partition có thể bị đảo khi đọc. Chặn nó cần đảm bảo các ghi có quan hệ nhân quả đi qua đường giữ được thứ tự, hoặc theo dõi quan hệ nhân quả tường minh — chính là chỗ vector clock (bạn học ở track thuật toán) vào cuộc, và ta sẽ dùng lại nó ở bài multi-leader.

6. Pitfall — mặc định eventual consistency cho dữ liệu người dùng tự sửa

❌ User sua ho so -> ghi qua leader -> trang reload -> doc tu follower dang lag
   -> thay ho so CU -> user tuong sua that bai -> sua lai -> ghi trung/loan

❌ Feed doc luan phien nhieu follower lag khac nhau
   -> F5 thay post moi roi lai mat -> tuong bug

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Single-leader: async replication (bài 01) chính là nguồn của lag; bài này xử lý hệ quả của nó.
• Bài 03 — Multi-leader: nhiều leader làm lag và thứ tự phức tạp hơn — consistent prefix + vector clock trở thành trung tâm.
• Bài 04 — Leaderless: quorum R+W>N là một cách giảm stale read thay vì chỉ sống chung với nó.
• Module 6 — Consistency & consensus: các đảm bảo yếu ở đây đối lập với linearizability (nhất quán mạnh) — hiểu cái yếu để thấy giá của cái mạnh.

9. Tóm tắt

• Replication lag: follower async trễ hơn leader; đọc từ follower đang lag → stale read (dữ liệu cũ).
• Eventual consistency: ngừng ghi thì hội tụ, nhưng "rốt cuộc" không có mốc thời gian — đảm bảo yếu.
• Read-your-writes: người dùng luôn thấy chính thứ mình vừa ghi (đọc từ leader/follower đủ mới).
• Monotonic reads: đọc lần sau không lùi trước lần trước (ghim một follower theo user).
• Consistent prefix reads: không thấy hệ quả trước nguyên nhân; hay vỡ khi dữ liệu phân mảnh — cần theo dõi nhân quả (vector clock).
• Anti-pattern: đẩy mọi đọc sang follower lag kể cả ngay sau khi user ghi → "lưu không ăn", dữ liệu loạn. Phân loại đọc theo mức nhất quán cần.

10. Tự kiểm tra

Bài tiếp theo: Multi-leader — ghi ở nhiều nơi và bài toán xung đột