Mọi thứ khó trong hệ thống phân tán bắt đầu từ một câu nghe tầm thường: gọi hàm qua mạng không giống gọi hàm trong tiến trình. Gọi hàm trong tiến trình có đúng hai kết quả: trả về, hoặc ném lỗi. Gọi qua mạng có kết quả thứ ba: không biết. Request có thể chưa tới, có thể tới và server đã làm nhưng phản hồi không về, có thể đang trên đường. Mọi kỹ thuật trong sê-ri này — idempotency, đồng thuận, khoá phân tán, phát hiện lỗi — đều là cách sống chung với kết quả thứ ba đó.

Bài này không nói lý thuyết. Nó làm hỏng mạng giữa hai container bằng tc netem rồi đo xem "không biết" trông như thế nào bằng số.

Làm hỏng mạng có chủ đích

Ảnh chụp đoạn mã nền tối làm hỏng mạng có chủ đích tc netem giữa hai container với dist-lab golang 1.23 cap-add NET_ADMIN gọi sang go-lab server Go cổng 8094 cùng mạng Docker netem trên eth0 chiều đi, một lệnh mạng thật trở thành mạng xấu gồm tc qdisc add dev eth0 root netem delay 50ms 20ms là trễ 50 ms cộng trừ 20 ms jitter cho mọi gói đi ra, netem loss 15 phần trăm vứt ngẫu nhiên 15 phần trăm gói, netem loss 100 phần trăm là phân vùng không gói nào qua, tc qdisc del dev eth0 root trả lại mạng bình thường, client kết nối mới mỗi request để mất gói chạm cả bắt tay TCP gồm http.Client Timeout 1 giây Transport DisableKeepAlives true giống client thật mở kết nối mới, vòng lặp 200 lần đo time.Since nếu Get thành công, câu hỏi thật sự lỗi xảy ra trước hay sau khi server đã làm gồm donHang atomic.Int64, handler /orders tăng bộ đếm và trả order_id tức server đếm số đơn thật sự đã tạo, client POST 200 lần dưới loss 30 phần trăm timeout 300 ms đếm thành công theo cách client thấy rồi so với bộ đếm của server chênh lệch là số request client tưởng lỗi nhưng server đã làm

Hình 1: tc netem thêm trễ, jitter, mất gói hoặc cắt hẳn trên giao diện mạng của container client. Server đếm số đơn thật sự tạo để so với thứ client nhìn thấy.

Hai container trên cùng mạng Docker: dist-lab chạy client Go và có quyền NET_ADMIN để dùng tc; go-lab chạy server Go với ba endpoint — /ping nhỏ, /orders tạo đơn và đếm, /big trả 1 MB. RTT nền giữa hai container là 0,2 ms, tức là mọi con số bên dưới gần như hoàn toàn do netem gây ra.

Client cố ý mở kết nối mới cho mỗi request. Giữ kết nối sống (keep-alive) che được phần lớn mất gói lúc bắt tay; client thật — trình duyệt mở tab mới, service vừa khởi động, pool kết nối vừa bị dọn — thì không có may mắn đó.

Đo thật: trễ cộng dồn, mất gói thành độ trễ

Ảnh chụp output thật nền tối loss 30 phần trăm 137 trên 200 OK 10 đơn tạo mà client tưởng lỗi với Go 1.23 dist-lab tc netem tới go-lab cùng mạng Docker RTT nền 0,2 ms, mục 1 200 GET /ping kết nối mới mỗi request timeout 1 giây cho thấy không có netem 200 trên 200 p50 0.2 ms p99 0.3 ms tối đa 1 ms, delay 50ms 200 trên 200 p50 107.4 ms p99 111.2 ms tối đa 114 ms tức 50 ms nhân 2 lượt SYN và request, delay 50ms jitter 20ms 200 trên 200 p50 107.5 ms p99 140.6 ms tối đa 142 ms, loss 5 phần trăm 194 trên 200 p50 0.6 ms p99 209.4 ms tối đa 417 ms, loss 15 phần trăm 163 trên 200 p50 0.9 ms p99 413.1 ms tối đa 418 ms với ghi chú truyền lại 200 400 800 ms, loss 30 phần trăm 137 trên 200 p50 1.7 ms p99 419.7 ms tối đa 829 ms, mục 2 loss 30 phần trăm 200 lần POST /orders timeout 300 ms cho thấy client thấy 125 thành công 75 lỗi hoặc timeout còn server đếm đã tạo 135 đơn tức 10 đơn được tạo mà client tưởng là lỗi retry mù ở đây là đơn đôi, mục 3 tải 1 MB TCP truyền lại thay bạn nhưng tính bằng thời gian cho thấy loss 0 phần trăm p50 1.3 ms tối đa 2.2 ms, loss 2 phần trăm p50 1.0 ms tối đa 1.3 ms, loss 5 phần trăm p50 1.6 ms tối đa 210.3 ms, loss 15 phần trăm p50 208.7 ms tối đa 1031.3 ms không có lỗi nào chỉ có chậm gấp 160 lần, mục 4 phân vùng loss 100 phần trăm từ t bằng 1,0 giây đến 4,0 giây ping liên tục với timeout 500 ms cho thấy t 0.00 giây OK, t 1.52 giây lỗi context deadline exceeded tức cắt lúc 1,0 giây biết sau đúng một timeout, t 4.35 giây OK tức nối lại lúc 4,0 giây request đang treo phải hết hạn đã, nói thẳng mất gói không làm request lỗi TCP đổi nó thành độ trễ 200 400 800 ms mỗi lần truyền lại cho tới khi vượt timeout của bạn và timeout không nói lỗi xảy ra trước hay sau khi server làm 10 trên 75 lần lỗi ở trên server đã làm xong

Hình 2: Bốn phép đo. Mục 2 là phép đo mà cả sê-ri này xoay quanh.

Trễ 50 ms một chiều thành 107 ms mỗi request. Không phải 50, không phải 100: bắt tay TCP tốn một lượt đi (SYN), request tốn một lượt nữa, cộng vài mili-giây xử lý. Với keep-alive, con số này về gần 50 — nhưng request đầu tiên của mỗi kết nối luôn trả giá gấp đôi. Jitter 20 ms không đổi p50 nhưng kéo p99 lên 140 ms: độ trễ đuôi là jitter cộng dồn qua nhiều lượt.

Mất gói 5% không làm 5% request lỗi — nó làm p99 nhảy từ 0,3 lên 209 ms. 194/200 vẫn thành công, vì TCP tự truyền lại gói mất. Nhưng lần truyền lại đầu tiên chờ khoảng 200 ms (RTO tối thiểu của Linux), lần hai 400, lần ba 800 — các cột "tối đa" 417 và 829 ms ở mất gói 15% và 30% chính là chuỗi đó. TCP đổi mất gói thành độ trễ, và độ trễ đó không tỉ lệ với RTT thật (0,2 ms) mà với hằng số 200 ms của kernel. Request "lỗi" chỉ xuất hiện khi chuỗi truyền lại vượt timeout 1 giây của client: 6, 37, rồi 63 lần.

Mục 2 — câu hỏi thật sự. Dưới mất gói 30%, client POST tạo đơn 200 lần với timeout 300 ms: nó thấy 125 thành công và 75 lỗi. Server đếm 135 đơn. Mười request client xếp vào "lỗi" thực ra đã tới server, server đã tạo đơn, chỉ có phản hồi (hoặc ACK của nó) bị vứt trên đường về. Client không có cách nào phân biệt 10 request đó với 65 request thật sự chưa tới. Nếu client retry cả 75 — điều mọi client "làm đúng" đều làm — thì 10 đơn thành 20. Đây là lý do khoá idempotency tồn tại, và là lý do câu "exactly-once" trong hệ phân tán luôn phải đi kèm một dấu hoa thị: mạng chỉ cho at-least-once hoặc at-most-once, exactly-once là thứ ứng dụng tự xây ở trên.

Mục 3 — không có lỗi, chỉ có chậm gấp 160 lần. Tải 1 MB dưới mất gói 15%: không request nào lỗi, p50 là 208,7 ms thay vì 1,3 ms, tối đa hơn một giây. Ứng dụng không thấy mất gói; nó thấy một đường truyền đột nhiên chậm. Biểu đồ độ trễ tăng vọt mà tỉ lệ lỗi vẫn 0% là dấu hiệu kinh điển của mất gói ở tầng dưới — và là lý do giám sát phải có p99 chứ không chỉ tỉ lệ lỗi.

Mục 4 — phân vùng. Cắt mạng hoàn toàn từ giây 1,0 đến 4,0. Client biết có chuyện ở giây 1,52 — đúng sau một timeout 500 ms. Nó biết mạng đã trở lại ở giây 4,35 — vì request đang treo phải hết hạn trước đã. Không có tín hiệu "mạng vừa đứt"; chỉ có "request này chưa về", và thời gian phát hiện bằng đúng timeout bạn đặt. Timeout ngắn phát hiện nhanh nhưng báo động giả nhiều (jitter 20 ms đã kéo p99 lên 140); timeout dài thì ngược lại. Phần 10 về phát hiện lỗi sẽ đo đánh đổi đó.

Vì sao cả sê-ri bắt đầu từ đây

Mọi kỹ thuật tiếp theo là câu trả lời cho một trong ba điều vừa đo:

  • Request không về không có nghĩa là server chưa làm (mục 2) → idempotency, khoá phân tán có fencing, giao dịch phân tán phải có pha "hỏi lại".
  • Mất gói thành trễ, trễ thành timeout, timeout thành "node chết" (mục 1, 3, 4) → phát hiện lỗi là xác suất chứ không phải chắc chắn; bầu chủ và đồng thuận phải sống được với "tôi tưởng nó chết nhưng nó còn sống".
  • Hai bên có thể cùng sống mà không nói chuyện được với nhau (mục 4) → split-brain, quorum, CRDT.

Đánh đổi cần cân nhắc

Netem ở đây chỉ chiều đi. tc trên eth0 của client chỉ làm hỏng gói client → server; gói server → client đi đường sạch. Đó là lý do mục 3 (tải 1 MB về) ở mất gói 2% gần như không ảnh hưởng — chỉ ACK bị mất, và TCP dung thứ mất ACK tốt hơn mất dữ liệu. Mạng thật hỏng cả hai chiều, nên con số thật xấu hơn. Muốn mô phỏng đủ thì đặt netem ở cả hai container, hoặc trên cầu nối Docker.

Hằng số 200 ms là của Linux. RTO tối thiểu (TCP_RTO_MIN) là 200 ms trong kernel Linux mặc định; nhiều trung tâm dữ liệu hạ xuống vài mili-giây cho mạng nội bộ, và lúc đó mất gói trở thành độ trễ nhỏ hơn nhiều. Tỉ lệ (truyền lại nhân đôi mỗi lần) thì không đổi.

Kết nối mới mỗi request là trường hợp xấu. Với keep-alive và HTTP/2, bắt tay chỉ trả giá một lần, và mất gói trên kết nối đang mở được TCP xử lý mượt hơn (fast retransmit thay vì RTO). Số đo ở đây là sàn của trải nghiệm xấu — nhưng là sàn mà client mới khởi động nào cũng chạm.

Netem là mô hình, không phải mạng thật. Mất gói thật thường theo cụm (burst) chứ không độc lập từng gói; netem có tham số loss 15% 25% cho tương quan và mô hình Gilbert-Elliott cho burst. Kết luận định tính (mất gói → trễ bậc thang → timeout → "không biết") không đổi; con số p99 thì đổi theo mô hình.

Ba ý mang về

  1. Gọi qua mạng có kết quả thứ ba là "không biết", và nó có thật bằng số: dưới mất gói 30%, 10 trong 75 request client xếp vào "lỗi" đã được server thực hiện. Retry mù ở đó là tạo đôi — mọi thứ trong sê-ri này bắt đầu từ chỗ đó.
  2. TCP đổi mất gói thành độ trễ theo bậc 200/400/800 ms, không tỉ lệ với RTT thật: mất 5% làm p99 nhảy từ 0,3 lên 209 ms mà tỉ lệ lỗi gần như không đổi; tải 1 MB ở mất 15% chậm gấp 160 lần với 0 lỗi. Giám sát p99, không chỉ tỉ lệ lỗi.
  3. Phát hiện mạng đứt bằng đúng timeout bạn đặt — 0,5 giây sau khi cắt, 0,35 giây sau khi nối — và không có tín hiệu nào khác. Timeout là đánh đổi giữa phát hiện nhanh và báo động giả, không phải một hằng số đúng.

Nguồn

Phần sau bỏ mạng sang một bên và nhìn vào thứ còn đáng ngờ hơn: đồng hồ. Hai máy không bao giờ cùng giờ, và "sự kiện A xảy ra trước B" cần một định nghĩa không dựa vào đồng hồ tường — Lamport và vector clock, đo trên nhiều tiến trình thật.