Partial failure & fencing token — chống split-brain

TL;DR: Trên một máy đơn, lỗi thường là "tất cả hoặc không". Hệ phân tán có chế độ lỗi nham hiểm hơn: partial failure — một phần chết trong khi phần khác vẫn chạy, không phần nào có bức tranh đầy đủ. Điều này sinh ra split-brain: một node bị tưởng đã chết (do timeout, thường vì process pause như GC dừng dài) nhưng còn sống, và khi "thức dậy" vẫn tưởng giữ quyền, ghi đè lên node đã thay thế nó. Lời giải kinh điển là lease (khoá có hạn) cộng fencing token: một số tăng dần cấp quyền ghi, tài nguyên từ chối token cũ hơn token đã thấy — chặn "zombie" cơ học.

Ba bài trước cho bạn các mảnh: mạng không tin cậy (01), đồng hồ không tin cậy (02), và cách suy thứ tự bằng nhân quả (03). Bài này ghép chúng vào một sự cố thực tế đắt giá — split-brain — và trình bày một cơ chế phòng thủ hoạt động được ngay cả khi bạn không thể biết node nào còn sống. Đây là bài "independent": sau khi đọc cơ chế, bạn sẽ tự thiết kế fencing cho một tình huống mới trước khi xem đáp án mẫu.

1. Analogy — chìa khoá phòng họp và người bị tưởng đã về

Một phòng họp chỉ cho một người dùng mỗi lúc; ai giữ chìa thì được vào. An đang giữ chìa và ở trong phòng. Quản lý gọi An mãi không thấy trả lời (An đang đeo tai nghe, không nghe điện) → quản lý kết luận An đã về, cấp một chìa mới cho Bình vào dùng phòng. Vấn đề: An chưa về — chỉ là không nghe điện. Giờ cả hai cùng ở trong phòng, cùng "tin mình có quyền". Nếu cả hai cùng ghi lên bảng, nội dung loạn.

Làm sao chặn? Đánh số thứ tự lên mỗi chìa: chìa của An số 33, chìa mới của Bình số 34. Ổ khoá của cái bảng chỉ chấp nhận số lớn nhất từng thấy. Khi Bình (số 34) ghi bảng, ổ ghi nhận "đã thấy 34". Lúc An (số 33) định ghi, ổ thấy 33 < 34 → từ chối. An bị chặn mà không cần ai xác nhận An còn sống hay đã chết — chỉ nhờ so số.

2. Partial failure là gì và vì sao nó khó hơn lỗi máy đơn?

Trên một máy, phần lớn lỗi là tất-định và toàn phần: hoặc chương trình chạy, hoặc nó crash — và khi crash thì cả nó dừng. Bạn không có tình huống "một nửa RAM còn tin được, một nửa thì không". Đó là một thế giới có thể suy luận: hoặc ổn, hoặc hỏng hẳn.

Partial failure là chế độ lỗi đặc trưng của hệ phân tán: một phần hệ hỏng trong khi phần khác vẫn chạy bình thường, và — tệ nhất — không phần nào biết bức tranh đầy đủ. Node A có thể chạy hoàn hảo trong khi node B chết; hoặc mạng giữa A và B đứt trong khi cả hai đều sống (network partition); hoặc B chạy nhưng đĩa của nó đầy nên chỉ một số thao tác lỗi. Ghép với sự thật ở bài 01 — A không phân biệt được B chết, B chậm, hay chỉ mạng A–B đứt — ta có một hệ nơi mỗi node chỉ thấy một góc, và các góc đó mâu thuẫn nhau: A tin "B chết", B tin "tôi vẫn sống".

flowchart LR
  A["Node A: 'B da chet'<br/>(timeout)"] -.->|"mang dut hoac B pause"| B["Node B: 'toi van song,<br/>van giu quyen'"]
  A --> C["Cap quyen cho node C"]
  B --> W1["B van ghi du lieu"]
  C --> W2["C cung ghi du lieu"]
  W1 --> SB["SPLIT-BRAIN:<br/>hai node cung ghi"]
  W2 --> SB

Chính sự mâu thuẫn giữa các góc nhìn — chứ không phải bản thân việc một node chết — mới là thứ khó. Một node chết hẳn và mọi node đồng ý "nó chết" thì dễ xử lý (chuyển việc). Nguy hiểm là khi các node bất đồng về việc ai còn sống.

3. Process pause — vì sao một node "sống" lại bị tưởng chết

Split-brain nghe như phải cần một lỗi hiếm, nhưng nguyên nhân phổ biến nhất lại rất đời thường: process pause. Một tiến trình đang chạy có thể bị đóng băng vô hình trong hàng trăm mili-giây tới nhiều giây, mà bản thân nó không hề biết mình đã dừng:

• GC stop-the-world: bộ dọn rác của runtime (JVM, Go, .NET) có thể dừng toàn bộ tiến trình để dọn heap — với heap lớn, một lần dừng có thể kéo dài hàng giây.
• Swap / page fault: OS đẩy bộ nhớ tiến trình ra đĩa; khi tiến trình chạm vào, nó phải chờ đọc lại từ đĩa — chậm hàng nghìn lần.
• VM bị treo (live migration, host quá tải): máy ảo có thể bị "đông cứng" khi hypervisor bận, rồi chạy tiếp như không có gì xảy ra.

Điểm chí mạng: từ bên trong, tiến trình bị pause không cảm nhận được thời gian đã trôi. Nó thực thi dòng lệnh A, bị pause 10 giây ngay sau đó, rồi thực thi dòng B như thể chỉ vừa mới xong A. Trong 10 giây đó, các node khác đã timeout, kết luận nó chết, và cấp quyền cho node khác. Khi nó "thức dậy" ở dòng B, nó vẫn tin mình đang giữ lock/leader — nhưng thực tế quyền đã bị thu hồi. Nó trở thành zombie: sống, hoạt động, nhưng làm việc dựa trên một sự thật đã lỗi thời.

Đây cũng là lý do không thể dựa "tôi vừa kiểm tra là mình còn giữ lock" để an toàn: giữa lúc kiểm tra và lúc ghi, một GC pause có thể chen vào, và lock đã đổi chủ mà tiến trình không hay. Kiểm tra thời gian (bài 02) cũng không cứu được: đồng hồ có thể đã nhảy trong lúc pause.

4. Lease + fencing token — chặn zombie một cách cơ học

Vì không thể phát hiện zombie đáng tin, ta vô hiệu hoá nó. Hai mảnh:

Lease — một lock có hạn dùng. Thay vì "giữ lock tới khi trả", node thuê quyền trong một khoảng (ví dụ 10 giây) và phải gia hạn liên tục. Nếu node chết/pause, lease hết hạn và hệ tự do cấp cho node khác. Nhưng lease một mình không đủ: node pause vẫn có thể thức dậy sau khi lease hết mà vẫn tưởng mình còn giữ (nó đâu biết đã pause). Cần mảnh thứ hai.

Fencing token — mỗi lần cấp quyền, bộ cấp phát (lock service) kèm một số nguyên tăng dần đơn điệu. Node phải đính token này vào mọi thao tác ghi tới tài nguyên. Tài nguyên (storage) nhớ token lớn nhất từng thấy và từ chối mọi ghi mang token nhỏ hơn:

sequenceDiagram
  participant C1 as Client 1 (token 33)
  participant L as Lock service
  participant S as Storage
  C1->>L: xin lock
  L-->>C1: cap lock + token 33
  Note over C1: GC pause dai...
  L-->>L: lease het han
  L-->>C1: (client 2 xin, cap token 34)
  Note over C1: thuc day, van tuong giu lock
  C1->>S: ghi X (token 33)
  Note over S: da thay token 34 > 33
  S-->>C1: TU CHOI (token cu)

Cơ chế này đẹp ở chỗ không cần biết ai còn sống. Storage không hỏi "client 1 còn sống không?" — câu hỏi bất khả trả lời. Nó chỉ so số: token 33 nhỏ hơn 34 đã thấy → từ chối. Zombie tự vô hại vì token của nó chắc chắn cũ hơn token của kẻ thay thế (token chỉ tăng). Đây là ý tưởng cốt lõi: dời trách nhiệm an toàn từ "phát hiện chết chính xác" (bất khả) sang "so sánh số tăng dần" (tầm thường) — và điểm enforce phải nằm ở tài nguyên (storage), không phải ở client, vì client zombie không thể tự biết để lùi bước.

Lưu ý token phải do một nguồn duy nhất, tăng đơn điệu cấp — đúng loại đảm bảo mà một dịch vụ consensus (ZooKeeper, etcd — Module 6) cung cấp. Đó là một trong những lý do consensus tồn tại: sinh ra một dãy số mà mọi node đồng ý về thứ tự.

5. Đến lượt bạn — tự thiết kế fencing

Bạn đã có cơ chế. Giờ tự áp vào một tình huống mới trước khi xem đáp án mẫu. Đọc kỹ, tự phác giải pháp ra giấy (hoặc trong đầu) rồi mới mở <SelfCheck>.

Tình huống. Một hệ lưu file dùng lock để đảm bảo chỉ một worker ghi vào file report.pdf mỗi lúc. Worker xin lock từ một lock service, ghi file lên một object storage (ví dụ S3), rồi trả lock. Gần đây đội gặp sự cố: thỉnh thoảng report.pdf bị hỏng (nội dung của hai worker trộn vào nhau), dù lock "hoạt động đúng". Điều tra thấy các worker chạy JVM heap lớn, đôi khi GC pause 8–12 giây.

Hãy tự trả lời trước khi mở đáp án:

1. Giải thích chính xác chuỗi sự kiện khiến file hỏng dù lock service không có bug.
2. Thiết kế cơ chế fencing token cho hệ này: token do ai cấp, đính vào đâu, và object storage cần làm gì để chặn ghi cũ?
3. Nếu object storage không hỗ trợ so sánh token (chỉ ghi đè mù), bạn còn cách nào để vẫn fence được không?

6. Pitfall — tin "tôi vừa kiểm tra là mình còn giữ lock"

❌ if (lockService.stillHolding(me)) {   // kiem tra: dung, con giu
       // <-- GC PAUSE 10s chen vao day; lock da doi chu
       storage.write(data);              // hanh dong: da la zombie
   }

✅ token = lockService.acquire();        // nhan token tang dan
   storage.write(data, token);           // storage tu choi neu token cu
   // -> an toan DU cho process pause chen giua

Hướng đúng: đừng bao giờ tách "kiểm tra quyền" khỏi "thực hiện ghi" bằng một khoảng có thể bị pause. Gắn token vào chính thao tác ghi và để tài nguyên phán xử tại thời điểm ghi — đó là điểm duy nhất có bức tranh đúng, và là điểm zombie không lách qua được.

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

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

• Bài 01 — Mạng không tin cậy: "không phân biệt được chậm với chết" là gốc của split-brain — timeout đánh dấu nhầm một node đang pause là chết.
• Bài 02 — Đồng hồ không tin cậy: trong một process pause, đồng hồ có thể nhảy; nên không thể dùng thời gian để tự kiểm "mình còn giữ lock" — fencing bằng số tăng dần né hẳn thời gian.
• Bài 03 — Causal order: fencing token là một dãy tăng đơn điệu — họ hàng với logical clock; cả hai dùng "số tăng dần" thay cho thời gian vật lý để áp một thứ tự đáng tin.
• Module 6 — Consensus & Raft: nguồn cấp token tăng đơn điệu, duy nhất, mà mọi node đồng ý chính là thứ consensus tạo ra — bài này cho một động lực cụ thể vì sao cần consensus.

9. Tóm tắt

• Partial failure: một phần hệ chết trong khi phần khác chạy, không node nào có bức tranh đầy đủ — khác hẳn máy đơn "all-or-nothing"; cái khó là các node bất đồng về ai còn sống.
• Process pause (GC stop-the-world, swap, VM freeze) đóng băng một tiến trình vài giây mà nó không hay → bị node khác timeout coi là chết.
• Split-brain: node bị tưởng chết thức dậy, vẫn tưởng giữ quyền → hai node cùng ghi → hỏng dữ liệu.
• Lease (lock có hạn) tự thu quyền khi node im lặng, nhưng một mình không đủ (zombie thức dậy vẫn tưởng giữ).
• Fencing token: quyền ghi kèm số tăng đơn điệu; tài nguyên từ chối token nhỏ hơn số lớn nhất đã thấy → zombie tự vô hại mà không cần biết ai còn sống. Điểm enforce phải ở storage, token phải do nguồn duy nhất tăng dần (consensus) cấp.
• Nguyên lý: dời an toàn từ "phát hiện chết chính xác" (bất khả) sang "so sánh số tăng dần" (tầm thường).

10. Tự kiểm tra

Bài tiếp theo: Module 5 — Tổng kết & cheat sheet