Đồng hồ không tin cậy — clock skew, monotonic vs wall clock

TL;DR: Ở bài trước, mạng không cho bạn suy luận thứ tự sự kiện đáng tin. Lối thoát tự nhiên: gắn timestamp cho mỗi sự kiện rồi so cái nào lớn hơn thì xảy ra sau. Bài này cho thấy lối thoát đó vỡ, vì đồng hồ cũng không tin cậy: mỗi node có đồng hồ riêng chạy lệch nhau (clock skew), và wall clock (time-of-day) còn có thể nhảy — kể cả nhảy lùi — khi NTP đồng bộ lại. Ta phân biệt wall clock (đo mấy giờ, có thể nhảy) với monotonic clock (chỉ tăng, đo khoảng thời gian), rồi xem chiến lược Last-Write-Wins dựa timestamp đứng trên giả định gì khi đồng hồ lệch.

Bạn đã học ở bài 01 rằng không thể tin mạng để biết cái gì tới trước. Câu hỏi tiếp theo rất tự nhiên: "Vậy gắn đồng hồ cho mỗi sự kiện, rồi so giờ thì sao?". Cả bài này là câu trả lời "không được" — và hiểu vì sao không được là điều kiện để bài 03 giới thiệu một cách suy luận thứ tự không cần đồng hồ vật lý.

1. Analogy — một phòng đầy đồng hồ treo tường lệch giờ

Tưởng tượng một toà nhà mỗi phòng treo một đồng hồ, và không phòng nào chỉ đúng cùng một giờ: phòng A chỉ 10:00:03, phòng B chỉ 09:59:58, phòng C chỉ 10:00:01. Giờ hai người ở hai phòng khác nhau cùng ghi lại "tôi hành động lúc mấy giờ" rồi so xem ai làm trước. Con số họ ghi không so sánh được, vì mỗi cái đo bằng một đồng hồ lệch riêng. Tệ hơn: thỉnh thoảng bảo vệ đi chỉnh lại từng đồng hồ cho "đúng giờ chuẩn" — nên một đồng hồ có thể đột ngột nhảy vài giây tới hoặc lùi ngay giữa lúc bạn đang dùng nó.

Đó chính là đồng hồ trong một cụm máy chủ.

2. Hai loại đồng hồ: wall clock và monotonic clock khác nhau thế nào?

Mọi máy tính hiện đại có hai loại đồng hồ, phục vụ hai mục đích khác hẳn nhau:

• Wall clock (time-of-day clock): trả lời "bây giờ là mấy giờ" theo lịch thực (ví dụ số mili-giây kể từ mốc 1970 — Unix epoch). Nó được đồng bộ với giờ chuẩn qua NTP (Network Time Protocol). Vì được chỉnh, nó có thể nhảy: nếu đồng hồ máy đang chạy nhanh 200ms, NTP có thể kéo lùi nó → thời điểm đọc sau nhỏ hơn thời điểm đọc trước.
• Monotonic clock: trả lời "đã trôi qua bao lâu" tính từ một mốc tuỳ ý (thường là lúc máy khởi động). Nó được đảm bảo chỉ tăng, không bao giờ nhảy lùi. Giá trị tuyệt đối của nó vô nghĩa khi so sánh giữa hai máy (mốc khác nhau), nhưng hiệu hai lần đọc trên cùng một máy cho khoảng thời gian đáng tin.

flowchart TD
  Q1["Cau hoi: 'may gio roi?'<br/>(timestamp su kien, log, lich)"] --> WC["WALL CLOCK<br/>dong bo NTP, CO THE nhay"]
  Q2["Cau hoi: 'bao lau da troi qua?'<br/>(timeout, do hieu nang)"] --> MC["MONOTONIC CLOCK<br/>chi tang, khong nhay lui"]
  WC -.->|"KHONG dung de do khoang"| BUG["Bug: khoang am neu NTP keo lui"]
  MC -.->|"KHONG dung de so 2 may"| BUG2["Vo nghia: moc khac nhau"]

Quy tắc rút ra: đo khoảng thời gian (timeout ở bài 01, đo latency một thao tác) → dùng monotonic. Ghi mốc thời gian tuyệt đối (một sự kiện xảy ra lúc mấy giờ, để hiển thị/log) → dùng wall clock, nhưng đừng tin nó để so sánh thứ tự giữa các máy.

3. Clock skew và NTP: vì sao wall clock nhảy

Đồng hồ máy tính dựa vào một bộ dao động thạch anh — không hoàn hảo. Nó chạy nhanh hoặc chậm hơn thời gian thật một chút, và mức lệch thay đổi theo nhiệt độ. Sai số điển hình cỡ vài chục phần triệu; nghe nhỏ, nhưng tích luỹ có thể lệch nhiều mili-giây tới vài giây mỗi ngày. Hai node khởi động cùng lúc, sau một ngày đồng hồ đã lệch nhau — đó là clock skew.

Để chống trôi, các máy chạy NTP: định kỳ hỏi một máy chủ thời gian rồi chỉnh đồng hồ local về gần giờ chuẩn. Chính hành động chỉnh này khiến wall clock nhảy:

• Nếu đồng hồ local đang chậm, NTP đẩy nó tới → có một khoảng thời gian bị "nhảy cóc" qua (một số mốc thời gian không bao giờ được đọc).
• Nếu đồng hồ local đang nhanh, NTP kéo nó lùi → thời gian lặp lại hoặc đi giật lùi. Đây là trường hợp nguy hiểm: code đọc wall clock hai lần liên tiếp có thể thấy lần sau nhỏ hơn lần trước.

Vì vậy wall clock không phải một dòng thời gian tăng đều. Nó là một con số được chỉnh liên tục để bám giờ chuẩn, và mỗi lần chỉnh là một lần nó nói dối về "trôi đều".

4. Vì sao Last-Write-Wins dựa timestamp lại mong manh?

Nhớ lại bài multi-leader ở Module 2: khi hai ghi xung đột, một chiến lược giải quyết là Last-Write-Wins (LWW) — gán mỗi ghi một wall-clock timestamp, giữ ghi có timestamp lớn nhất, vứt phần còn lại. Chiến lược này giả định "timestamp lớn hơn = xảy ra sau". Bài này vừa cho thấy giả định đó sai vì clock skew. Trước khi đọc tiếp, hãy thử lần theo một tình huống cụ thể.

Lần theo: theo thời gian thật, ghi x = "Bình" xảy ra sau (t=50ms so với t=0ms), nên trực giác "giữ cái mới nhất" phải giữ "Bình". Nhưng LWW chỉ nhìn con số timestamp: ghi "An" mang timestamp 100, ghi "Bình" mang 50. Vì 100 vượt 50, LWW giữ "An" và vứt "Bình" — đúng ngược với thứ tự thật. Kết quả cuối x = "An", và ghi "Bình" (hợp lệ, mới hơn) biến mất âm thầm: không lỗi, không cảnh báo, chỉ là dữ liệu người dùng lặng lẽ mất.

Đây là mặt nguy hiểm của LWW-timestamp: nó trông đúng và chạy đúng khi đồng hồ trùng khớp, nhưng chỉ cần clock skew — thứ luôn tồn tại — là nó vứt nhầm ghi. Và vì đồng hồ lệch chỉ vài chục mili-giây, lỗi chỉ xảy ra với các ghi xung đột rất gần nhau về thời gian — hiếm, không tái hiện ổn định, cực khó debug. Bài học: timestamp vật lý không phải một thứ tự đáng tin trong hệ phân tán. Đó chính là động lực để bài 03 tìm một cách suy luận thứ tự không dựa đồng hồ.

5. Pitfall — tin wall clock để đo khoảng hoặc so thứ tự

❌ start = wallClock();
   ... lam viec ...
   duration = wallClock() - start;   // NTP keo lui giua chung
   // -> duration co the AM, hoac sai lech vai giay

✅ start = monotonicClock();
   duration = monotonicClock() - start;   // luon >= 0, dang tin

❌ if (writeA.wallTimestamp > writeB.wallTimestamp) keep(writeA);
   // -> clock skew giua node -> giu nham ghi, mat du lieu

✅ Dung logical clock / vector clock (bai 03) de suy thu tu nhan qua
✅ Hoac chap nhan LWW nhung HIEU no co the mat du lieu (chi dung khi
   mat mot ghi la chap nhan duoc)

Hướng đúng: tách bạch hai loại đồng hồ theo câu hỏi cần trả lời. Khi cần thứ tự sự kiện đáng tin, đừng tìm một đồng hồ "chuẩn hơn" — hãy đổi công cụ: dùng đồng hồ logic (bài 03). Nếu buộc dùng LWW, hãy tài liệu hoá rõ rằng nó có thể mất dữ liệu và chỉ áp cho dữ liệu chấp nhận được điều đó.

6. 📚 Đào sâu — nguồn gốc & tài liệu

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

• Bài 01 — Mạng không tin cậy: bài này đóng nốt lối thoát mà bài 01 mở ra — không tin mạng để biết thứ tự, cũng không tin đồng hồ để biết thứ tự.
• Bài 03 — Causal order: vì đồng hồ vật lý bất khả tín, bài 03 dùng đồng hồ logic (happened-before, vector clock) để suy thứ tự nhân quả mà không cần đồng bộ thời gian.
• Module 2 — Multi-leader replication: LWW là một chiến lược giải xung đột ở đó; bài này giải thích vì sao nó mong manh, còn vector clock (bài 03) là lựa chọn không mất dữ liệu.
• Bài 04 — Partial failure & fencing token: process pause (GC) có thể khiến một node "ngủ" lâu rồi thức dậy với đồng hồ đã lệch — một biểu hiện khác của việc không tin được thời gian trên một node.

8. Tóm tắt

• Mỗi node có đồng hồ thạch anh riêng, trôi nhanh/chậm khác nhau → clock skew: timestamp hai node không so sánh trực tiếp được.
• Wall clock (time-of-day) trả lời "mấy giờ", đồng bộ NTP nên có thể nhảy — kể cả nhảy lùi. Không dùng để đo khoảng thời gian.
• Monotonic clock chỉ tăng, không nhảy lùi → đúng để đo khoảng (timeout, latency) trên một máy; giá trị tuyệt đối vô nghĩa khi so hai máy.
• NTP chỉnh đồng hồ định kỳ; hành động chỉnh chính là lúc wall clock nhảy tới/lùi.
• Last-Write-Wins dựa wall-clock timestamp mong manh: clock skew có thể khiến nó vứt nhầm một ghi mới hơn, mất dữ liệu âm thầm — chỉ dùng khi mất một ghi là chấp nhận được.
• Kết luận: timestamp vật lý không phải thứ tự đáng tin trong hệ phân tán → cần đồng hồ logic (bài 03).

9. Tự kiểm tra

Bài tiếp theo: Causal order — happened-before và vector clock