Mạng không tin cậy — timeout, retry, 8 fallacies

TL;DR: Trong hệ phân tán, các node chỉ nói chuyện qua mạng bất đồng bộ — gói tin có thể trễ tuỳ ý, mất hẳn, hoặc tới sai thứ tự. Hệ quả nghiệt ngã nhất: khi gửi request mà không nhận được trả lời, bạn không thể phân biệt node kia đã chết, đang chậm, hay chỉ gói trả lời bị mất. Công cụ duy nhất để đoán một node đã chết là timeout — một phỏng đoán, không phải sự thật. Bài này giải thích vì sao retry an toàn cần idempotency, và điểm lại 8 fallacies of distributed computing — giả định sai lập trình viên hay mang từ máy đơn lên.

Ở Module 4 bạn thấy 2PC "blocking" vì coordinator có thể chết giữa chừng và participant không biết chờ tới bao giờ. Gốc rễ của "không biết chờ tới bao giờ" nằm ở đây: mạng không cho bạn một tín hiệu rõ ràng nào để biết bên kia còn sống hay đã chết. Cả module này xoay quanh đúng một sự thật khó chịu đó, và bài đầu tiên đặt nền: mạng là thứ không tin cậy mà mọi node buộc phải dựa vào.

1. Analogy — gửi thư mà không có hồi báo

Hình dung bạn gửi một lá thư yêu cầu ("chuyển giúp 100k cho C") tới một người bạn ở xa, qua một bưu điện không có dịch vụ báo phát. Bạn bỏ thư vào hòm rồi chờ thư hồi âm ("đã chuyển xong"). Một tuần trôi qua, không có hồi âm. Chuyện gì đã xảy ra? Có thể lá thư đi bị thất lạc (bạn kia chưa từng nhận). Có thể bạn kia đã nhận, đã chuyển tiền, nhưng lá thư hồi âm thất lạc. Có thể bạn kia đang ốm, thư nằm chờ trên bàn cả tuần. Từ phía bạn — người gửi — cả ba khả năng trông giống hệt nhau: chỉ là "không có hồi âm".

Đó chính xác là tình cảnh một node gửi request qua mạng và chờ response.

2. Vì sao không phân biệt được "node chậm" với "node chết"?

Đây là câu hỏi trung tâm của cả module. Khi node A gửi request tới node B rồi chờ, có bốn điểm mà mọi thứ có thể hỏng — và A không quan sát được điểm nào đã hỏng:

flowchart LR
  A["Node A<br/>(gui request)"] -->|"1. request co the mat"| B["Node B"]
  B -->|"2. B co the cham (GC, tai cao)"| B2["Node B<br/>(dang xu ly?)"]
  B2 -->|"3. B co the chet giua chung"| X["(khong response)"]
  B2 -->|"4. response co the mat"| A

Từ phía A, cả bốn trường hợp cho cùng một quan sát: "gửi đi, không thấy response trong thời hạn". A không có cách nào nhìn xuyên mạng để biết B đang ở trạng thái nào. Mạng chỉ chuyển bit; nó không kèm theo một "báo cáo sức khoẻ" trung thực về B.

Điểm mấu chốt là phi đối xứng: A biết chắc nó đã gửi, nhưng A không biết B có nhận hay có xử lý hay không. Thông tin chỉ chảy một chiều rõ ràng (A biết hành động của chính A); chiều ngược lại (trạng thái của B) bị mạng che. Bạn không thể xây một "máy dò node chết" hoàn hảo trên một mạng bất đồng bộ — đây không phải hạn chế kỹ thuật tạm thời mà là một giới hạn nền tảng.

3. Timeout — một phỏng đoán, không phải sự thật

Nếu không có tín hiệu trung thực, làm sao một hệ quyết định "coi B là đã chết" để chuyển việc sang node khác? Câu trả lời thực dụng duy nhất: timeout. Đặt một mốc thời gian; quá mốc mà chưa có response thì coi như B chết và hành động tiếp (retry, failover, báo lỗi).

Nhưng timeout là một phỏng đoán dựa trên giả định "nếu B còn sống thì đã trả lời trong khoảng này". Giả định đó có thể sai, vì mạng bất đồng bộ không có giới hạn trên cho độ trễ. Và chọn giá trị timeout là một đánh đổi không có lời giải hoàn hảo:

Tệ hơn: timeout ngắn có thể tạo hiệu ứng dây chuyền. Giả sử B chỉ đang chậm vì tải cao. A timeout, coi B chết, chuyển toàn bộ tải của B sang node C. Giờ C quá tải và chậm theo, bị node khác timeout, tải lại dồn tiếp sang D... Một node chậm thoáng qua biến thành sự cố lan rộng chỉ vì timeout đặt quá nhạy. Đây là lý do timeout thường đi kèm cơ chế thích ứng (đo RTT thực tế, backoff) thay vì một hằng số cứng.

4. Retry cần idempotency — worked example

Khi timeout, phản ứng tự nhiên là retry (gửi lại). Nhưng nhớ mục 2: một request "tưởng thất bại" có thể đã chạy thành công, chỉ là response bị mất trên đường về. Retry lúc đó = chạy lần hai. Với thao tác đọc thì vô hại; với thao tác thay đổi trạng thái (trừ tiền, tạo đơn) thì retry mù có thể gây hậu quả kép.

Đi qua một ví dụ cụ thể. Client gửi "trừ 100k từ tài khoản X":

Lan 1:
  Client -> Server: POST /withdraw {acct: X, amount: 100k}
  Server: tru 100k thanh cong, so du 500k -> 400k
  Server -> Client: 200 OK        <-- goi tin nay BI MAT
  Client: timeout, tuong that bai

Lan 2 (retry mu):
  Client -> Server: POST /withdraw {acct: X, amount: 100k}
  Server: tru them 100k nua! so du 400k -> 300k   <-- TRU HAI LAN

Client tưởng trừ một lần, thực tế trừ hai lần. Lỗi này chỉ xuất hiện khi response đầu bị mất — nên nó hiếm, khó tái hiện, và rất khó debug.

Cách sửa đúng là làm thao tác idempotent (chạy lại nhiều lần cho cùng một kết quả như chạy một lần). Kỹ thuật phổ biến: client sinh một idempotency key duy nhất cho ý định giao dịch, gửi kèm mỗi lần (kể cả retry). Server nhớ key đã xử lý:

Lan 1:
  Client -> Server: POST /withdraw {key: "abc-123", acct: X, amount: 100k}
  Server: key "abc-123" chua thay -> tru 100k, ghi lai key da xu ly
  Server -> Client: 200 OK        <-- van BI MAT

Lan 2 (retry, CUNG key):
  Client -> Server: POST /withdraw {key: "abc-123", acct: X, amount: 100k}
  Server: key "abc-123" DA xu ly -> KHONG tru lai, tra ve ket qua cu
  Server -> Client: 200 OK        <-- lan nay ve duoc

Retry giờ an toàn: dù client gửi lại bao nhiêu lần với cùng key, tiền chỉ trừ đúng một lần. Đây chính là lý do idempotency là điều kiện tiên quyết của retry — điều bạn đã gặp ở bài tránh distributed transaction khi saga cần idempotency để chịu được retry.

❌ catch (timeout) { retry(request); }   // request tru tien / tao don
   -> neu response dau bi mat, thao tac chay HAI lan

✅ Sinh idempotency key cho moi y dinh; server khu trung theo key
✅ Hoac thiet ke thao tac tu no idempotent (PUT ghi de, khong INCREMENT)

5. 8 fallacies of distributed computing

Nhiều lỗi hệ phân tán bắt nguồn từ việc lập trình viên mang giả định của máy đơn lên mạng. L. Peter Deutsch và đồng nghiệp ở Sun Microsystems đúc kết thành 8 fallacies of distributed computing — 8 điều mà người mới ngầm tin là đúng nhưng thực tế đều sai:

Hai fallacy đầu (đáng tin, độ trễ 0) trực tiếp là nội dung bài này: mạng không đáng tin, và độ trễ không bằng 0, không có trần. Bốn thước đo ở Module 1 (nhất là tail latency) và cả module này tồn tại chính vì những ngộ nhận đó phải bị gỡ bỏ khi thiết kế hệ thật.

6. Pitfall — lập trình phân tán như gọi hàm cục bộ

❌ result = remoteService.charge(order);  // coi nhu goi ham cuc bo
   // -> khong xu ly timeout, khong retry, khong idempotency
   // -> khi mang loi: treo vo han, hoac mat/trung giao dich

✅ Moi loi goi mang: dat timeout tuong minh; retry co backoff;
   thao tac thay doi trang thai phai idempotent; xu ly ca 3 ket cuc
   (thanh cong / that bai / KHONG BIET)

Hướng đúng: coi mọi ranh giới mạng là nơi có thể hỏng, và thiết kế cho nhánh "không biết" ngay từ đầu — timeout tường minh, retry idempotent, và ở tầng cao hơn là các cơ chế bạn sẽ gặp sau (fencing token ở bài 04, consensus ở Module 6) để hệ vẫn đúng đắn dù từng lời gọi không đáng tin.

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

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

• Bài 02 — Đồng hồ không tin cậy: mạng không tin cậy khiến bạn muốn dựa vào thời gian để suy luận thứ tự — nhưng bài sau cho thấy đồng hồ cũng không đáng tin, đóng luôn lối thoát đó.
• Bài 04 — Partial failure & fencing token: "không phân biệt được chậm với chết" ở bài này chính là gốc của split-brain — một node bị coi là chết (timeout) nhưng thực ra còn sống và vẫn ghi dữ liệu.
• Module 4 — Tránh distributed transaction: idempotency ở mục 4 là điều kiện để saga chịu được retry — cùng một nguyên lý, áp ở tầng giao dịch.
• Module 6 — Consensus & Raft: vì không có máy dò chết hoàn hảo, hệ cần một cách để đa số thống nhất "ai còn sống, giá trị nào đúng" — đó là consensus.

9. Tóm tắt

• Mạng phân tán là bất đồng bộ: gói tin có thể trễ tuỳ ý (không có trần), mất, hoặc đến sai thứ tự.
• Khi không có response, bạn không phân biệt được node chết, node chậm, hay response bị mất — thông tin về bên kia bị mạng che, phi đối xứng.
• Timeout là cách duy nhất để "đoán" node đã chết, nhưng chỉ là phỏng đoán: ngắn thì báo chết oan (và gây dây chuyền), dài thì phát hiện lỗi chậm.
• Retry cần idempotency vì request "tưởng thất bại" có thể đã chạy — dùng idempotency key hoặc thiết kế thao tác tự idempotent.
• 8 fallacies of distributed computing liệt kê các giả định máy-đơn sai lầm; hai cái đầu (mạng đáng tin, độ trễ 0) chính là nội dung bài này.
• Lời gọi mạng có ba kết cục (thành công / thất bại / không biết) — bỏ quên nhánh "không biết" là nguồn của phần lớn bug phân tán.

10. Tự kiểm tra

Bài tiếp theo: Đồng hồ không tin cậy — clock skew, monotonic vs wall clock