Gossip Protocol và Failure Detection: Quản lý thành viên trong hệ thống phân tán

Một cluster không thể tự phối hợp nếu các node không biết ai đang tham gia, ai vừa rời đi và ai có thể đã mất kết nối. Nhưng trong mạng bất đồng bộ, “không trả lời” không đồng nghĩa với “đã chết”: node có thể quá tải, garbage collection tạm dừng, packet bị rơi hoặc đường mạng chỉ lỗi một chiều. Gossip protocol và failure detector giải quyết phần khó này bằng cách phát tán trạng thái theo từng bước nhỏ và đưa ra phán đoán có mức độ, thay vì bắt mọi node đồng bộ qua một danh sách trung tâm ở mỗi thay đổi.

Bài viết tập trung vào membership plane của backend phân tán: cách gossip lan truyền thông tin, SWIM tách kiểm tra lỗi khỏi phổ biến cập nhật, vai trò của trạng thái suspect, failure detector kiểu phi-accrual, incarnation number, tombstone và quy trình vận hành. Đây không phải consensus protocol. Membership cho biết tập node mà hệ thống tin là đang tồn tại; nó không tự quyết định leader, thứ tự ghi hay tính đúng của transaction.

1. Membership thực sự phải trả lời những câu hỏi nào?

Một dịch vụ chạy trên nhiều máy cần một view về thành viên để định tuyến request, phân shard, nhân bản dữ liệu hoặc phân công background job. Mỗi bản ghi thường gồm định danh node ổn định, địa chỉ liên lạc, incarnation hoặc generation, trạng thái và metadata nhỏ như zone hay vai trò. View này thay đổi khi node join, leave có chủ đích, restart với incarnation mới hoặc bị nghi ngờ đã lỗi.

Không nên gộp ba khái niệm thành một. Discovery giúp node mới tìm ít nhất một seed để vào cluster. Membership duy trì danh sách thành viên và phiên bản trạng thái. Failure detection tạo tín hiệu rằng một thành viên có thể không còn phản hồi. DNS, service registry hoặc danh sách seed có thể hỗ trợ discovery nhưng không thay thế giao thức cập nhật membership liên tục.

2. Gossip lan truyền trạng thái như thế nào?

Trong một vòng gossip, mỗi node chọn một hoặc vài peer rồi trao đổi một phần trạng thái. Peer tiếp tục chuyển thông tin trong các vòng sau. Nếu chọn peer đủ ngẫu nhiên và mạng còn kết nối, một cập nhật có thể lan tới phần lớn cluster sau số vòng tăng theo logarit của số thành viên. Không cần một coordinator nhận mọi heartbeat, nên tải truyền thông được phân tán và hệ thống tránh một điểm nghẽn rõ ràng.

Gossip mang tính xác suất. Một cập nhật không có cam kết rằng tất cả node nhận cùng lúc, và hai node có thể tạm thời nhìn thấy hai membership view khác nhau. Payload vì vậy cần phiên bản để phân biệt dữ liệu mới/cũ, quy tắc merge xác định và giới hạn kích thước. Gửi toàn bộ bảng membership ở mỗi vòng dễ triển khai nhưng tốn băng thông khi cluster lớn; digest, delta hoặc piggyback cập nhật giúp giảm chi phí nhưng cần cơ chế chống bỏ sót.

every protocol_period:
  peer = choose_random_alive_member()
  send(peer, probe + bounded_recent_updates)
  merge(response.membership_updates)
  retransmit_updates_with_remaining_budget()

Random selection không có nghĩa bỏ qua topology. Giao tiếp xuyên vùng có độ trễ và chi phí khác nội vùng; chỉ gossip nội vùng lại có thể khiến các nhóm hội tụ chậm hoặc bị tách. Thiết kế thực tế thường kết hợp peer ngẫu nhiên với nhận thức zone/rack và một tỷ lệ trao đổi xuyên miền lỗi.

3. Heartbeat tập trung gặp giới hạn gì?

Một monitor trung tâm nhận heartbeat từ mọi node có ưu điểm dễ hiểu và cho một view thuận tiện. Nhưng khi cluster lớn, monitor chịu tải tuyến tính, trở thành điểm nóng và cần cơ chế HA của riêng nó. Nếu monitor mất mạng với một rack, nó có thể tuyên bố cả rack chết dù các node vẫn liên lạc với nhau. Chuyển sang nhiều monitor lại đặt ra bài toán hợp nhất quan sát.

Gossip không loại bỏ chi phí; nó phân bổ chi phí và chấp nhận hội tụ dần. Mỗi node thực hiện một lượng probe gần ổn định theo chu kỳ, trong khi xác suất phát hiện và phổ biến lỗi không phụ thuộc vào một máy duy nhất. Đánh đổi là operator phải hiểu false positive, thời gian hội tụ và view không đồng nhất. Với cluster nhỏ, registry hoặc control plane đáng tin cậy có thể đơn giản hơn; gossip có giá trị khi yêu cầu scale, chịu partition và tự tổ chức biện minh cho độ phức tạp.

4. SWIM tách failure detection khỏi dissemination

SWIM là một thiết kế membership nổi tiếng, tách hai chức năng: probe một thành viên để phát hiện khả năng lỗi và phát tán cập nhật membership qua giao tiếp protocol định kỳ. Ở mỗi chu kỳ, node chọn một target và gửi ping trực tiếp. Nếu target không trả lời đúng hạn, node nhờ một số peer gửi ping gián tiếp. Cách này kiểm tra liệu đường trực tiếp có lỗi trong khi target vẫn truy cập được qua đường khác.

A -> B: ping
if no ack before direct_timeout:
  A -> {C, D, E}: ping-req(B)
  {C, D, E} -> B: ping
  B -> A (through helper): ack
if still no ack:
  mark B as suspect, do not evict immediately

Indirect probe giảm false positive do packet loss hoặc lỗi đường truyền cục bộ, nhưng không chứng minh target khỏe hoàn toàn. Target có thể trả gói protocol nhỏ trong khi request nghiệp vụ bị treo; ngược lại, CPU pause ngắn có thể làm lỡ cả direct và indirect deadline. Vì thế health của membership plane và readiness của data plane nên là hai tín hiệu riêng.

5. Suspect trước, dead sau

Nếu timeout đầu tiên lập tức xóa node, một đợt packet loss ngắn có thể gây mass eviction, tái cân bằng dữ liệu và tăng tải đúng lúc mạng đang yếu. Trạng thái suspect tạo khoảng đệm: cập nhật nghi ngờ được gossip để các observer khác cùng biết, nhưng node chưa bị coi là dead cho tới khi suspicion timeout kết thúc hoặc có thêm bằng chứng.

Node bị nghi ngờ có thể tự refute bằng cách phát hành trạng thái alive với incarnation number cao hơn. Phiên bản lớn hơn thắng thông tin suspect cũ đang trôi trong mạng. Incarnation phải tăng qua lifecycle đúng cách; nếu restart làm mất counter và dùng lại định danh cũ với generation thấp, các peer có thể tiếp tục coi node mới là phiên bản cũ đã chết.

• Dùng node ID ổn định cùng incarnation tăng đơn điệu trong một danh tính logic.
• Phân biệt graceful leave với failure để tránh node rời có chủ đích tự quay lại do gossip cũ.
• Không rút suspicion timeout xuống chỉ để dashboard cập nhật nhanh hơn.
• Giới hạn tốc độ hành động hậu quả như replica repair hoặc shard movement sau eviction.

6. Phi-accrual biến lịch sử heartbeat thành mức nghi ngờ

Timeout cố định đưa ra quyết định nhị phân: phản hồi trước mốc T là khỏe, sau T là lỗi. Phi-accrual failure detector thay vào đó theo dõi phân bố thời gian đến giữa các heartbeat và xuất một giá trị nghi ngờ phi. Phi càng cao thì khoảng im lặng hiện tại càng khó xảy ra theo lịch sử quan sát. Ứng dụng đặt threshold phù hợp với mức chấp nhận false positive của mình.

Điểm mạnh là detector thích ứng với nhịp thực tế thay vì dùng một timeout cho mọi môi trường. Điểm yếu là mô hình chỉ tốt khi sample đủ đại diện. Deploy, autoscaling, network jitter hoặc stop-the-world pause có thể làm phân bố thay đổi nhanh. Cần giới hạn cửa sổ sample, xử lý giai đoạn warm-up và tránh xem phi là xác suất node đã chết. Nó là thước đo mức bất thường theo mô hình quan sát tại một peer.

7. Membership không phải consensus

Hai node nhận gossip ở thời điểm khác nhau nên có thể bất đồng tạm thời về ai đang alive. Điều đó phù hợp cho discovery, routing mềm, cache topology hoặc chọn peer để probe. Nó không đủ để đảm bảo duy nhất một leader, cấp một lease độc quyền hoặc commit transaction. Những invariant đó cần consensus, fencing token, conditional write hoặc authority có thứ tự rõ ràng.

Một lỗi phổ biến là chọn “node có ID nhỏ nhất trong membership view” làm leader rồi cho leader thực hiện side effect không có fencing. Trong partition, hai phía có view khác nhau và cùng chọn leader. Gossip có thể giúp consensus layer tìm peer, nhưng không thay thế quorum và term của consensus. Tương tự, consistent hashing dựa trên membership cần xử lý giai đoạn các node chưa đồng ý ring; replica owner không nên âm thầm ghi đè dữ liệu chỉ vì nhận một view mới hơn cục bộ.

Membership trả lời “tôi đang thấy những ai”; consensus trả lời “nhóm đã thống nhất quyết định nào trong một thứ tự được bảo vệ”.

8. Tombstone, leave và nguy cơ node sống lại

Khi xóa hoàn toàn thông tin về một member quá sớm, một peer bị cô lập lâu ngày có thể quay lại với bản ghi alive cũ và làm node đã rời “sống lại”. Tombstone hoặc trạng thái dead/left được giữ đủ lâu để lấn át update cũ. Thời gian giữ phải lớn hơn cửa sổ mà stale peer có thể tái kết nối, nhưng giữ vô hạn làm membership table phình ra.

Graceful leave nên tạo version không thể bị incarnation cũ refute, sau đó node dừng tham gia. Force remove là thao tác nguy hiểm: nếu process thật vẫn chạy trong partition, nó có thể tiếp tục phục vụ hoặc phát gossip. Runbook cần yêu cầu fencing ở data plane, thu hồi credential/lease khi phù hợp và chỉ tái sử dụng node ID sau khi đã xử lý generation.

Bootstrap cũng cần seed đa dạng theo failure domain. Seed chỉ là điểm vào, không nên là authority vĩnh viễn; nếu toàn bộ seed cùng chết, member hiện tại vẫn có thể gossip nhưng node mới không join được. Theo dõi riêng availability của đường bootstrap và health của membership đang hoạt động.

9. Chọn tham số từ SLO và failure mode

Các tham số liên quan lẫn nhau: protocol period quyết định tần suất probe; direct và indirect timeout quyết định tốc độ một attempt; số helper ảnh hưởng xác suất tìm được đường tốt; suspicion timeout tạo thời gian refute; retransmit budget ảnh hưởng tốc độ phổ biến. Giảm mọi timeout cùng lúc có thể phát hiện nhanh trong lab nhưng tạo false positive hàng loạt ở production.

1. Đo RTT p50, p95, p99 và packet loss theo cặp zone trong cả giờ cao điểm.
2. Xác định thời gian phát hiện tối đa mà nghiệp vụ chấp nhận, thay vì bắt đầu từ con số tùy ý.
3. Đặt deadline có khoảng thở cho jitter và scheduler pause đã quan sát.
4. Mô phỏng xác suất probe trúng node lỗi và thời gian dissemination theo kích thước cluster.
5. Giới hạn hành động sau failure để tránh rebalancing storm.
6. Canary thay đổi tham số và giữ cấu hình rollback.

Cluster rất lớn hoặc nhiều vùng có thể cần hierarchy, local membership và bridge giữa vùng. Một cấu hình phẳng gửi metadata cho hàng chục nghìn member có thể không còn phù hợp dù số message mỗi node nhìn có vẻ nhỏ. Đo bytes, CPU serialize/merge và queue delay, không chỉ đếm packet.

10. Bảo mật membership plane

Nếu kẻ tấn công có thể join hoặc giả mạo gossip, họ có thể thêm endpoint độc hại, khai tử node thật hoặc làm phình bảng trạng thái. Traffic membership cần authentication và integrity; encryption cần cân nhắc theo threat model. Key rotation phải cho phép cửa sổ chuyển tiếp có kiểm soát để không tự chia cluster thành hai nhóm dùng khóa khác nhau.

• Chỉ cho phép identity đã cấp quyền join, không tin địa chỉ IP như danh tính.
• Xác thực message, chống replay bằng version/nonce phù hợp và giới hạn kích thước payload.
• Rate limit join, state sync và message không hợp lệ theo nguồn.
• Không gossip secret hoặc metadata nghiệp vụ nhạy cảm chỉ vì protocol đã mã hóa.
• Ghi audit cho force remove, key rotation và thay đổi cấu hình cluster.

UDP thường được chọn vì nhẹ, nhưng có giới hạn MTU, fragmentation và chính sách firewall khác TCP. Payload piggyback tăng dần có thể vượt MTU rồi bị drop không đều. Theo dõi kích thước datagram, tránh fragmentation và kiểm thử đúng network path production.

11. Observability phải đo chất lượng phán đoán

Dashboard không chỉ đếm số member alive. Cần đo probe success theo direct/indirect, RTT, timeout, số suspect, thời gian suspect tới refute/dead, update queue, tuổi update chưa phát tán và độ lệch membership view. False positive có thể ước lượng từ node bị suspect rồi refute mà không restart; false negative cần đối chiếu failure injection hoặc nguồn sự thật vận hành.

• Protocol rounds trễ hoặc bị bỏ vì event loop/CPU pause.
• Direct ACK, indirect ACK, probe timeout và helper timeout theo zone.
• Số lần incarnation tăng để refute suspicion.
• Thời gian từ kill process đến phần trăm peer đánh dấu dead.
• Kích thước membership table, tombstone và retransmit queue.
• Bytes gửi/nhận, packet vượt MTU, decode error và message bị từ chối xác thực.

Log cần node ID, incarnation, observer, target, transition cũ/mới và reason code nhưng không ghi bí mật. Trace sampling có thể nối failure decision với hậu quả như bỏ endpoint khỏi load balancer. Cảnh báo nên dựa trên tốc độ suspect/refute và divergence, không chỉ một node suspect đơn lẻ vốn có thể là hành vi bình thường.

12. Kiểm thử failure mode và rollout

Test happy path join/leave chưa đủ. Môi trường staging nên tạo packet loss, delay bất đối xứng, partition giữa zone, CPU starvation, process pause, duplicate/reordered packet và restart mất state. Kiểm tra cả thời gian phát hiện lẫn tác động sau khi phát hiện: routing có dừng gửi traffic đúng lúc, shard có bị di chuyển quá mức, và node quay lại có nhận state hiện tại hay không.

1. Kill một node và đo distribution thời gian peer chuyển từ alive qua suspect tới dead.
2. Chặn riêng đường A-B nhưng giữ A-C-B để xác minh indirect probe.
3. Pause target ngắn hơn và dài hơn suspicion timeout để đo false positive.
4. Partition cluster thành hai phía rồi nối lại; kiểm tra merge theo incarnation.
5. Graceful leave, giữ một peer offline, sau đó bật peer để thử chống resurrection.
6. Rotate key theo quy trình và chứng minh không tạo hai membership island.
7. Tăng cluster size và metadata để kiểm tra bandwidth, MTU và convergence.

Rollout nên bắt đầu ở nhóm canary không giữ invariant duy nhất. So sánh detector mới với tín hiệu hiện tại ở chế độ shadow trước khi cho phép eviction thật. Có kill switch để ngừng hành động hậu quả nhưng vẫn thu thập quan sát. Gossip và failure detection tốt không hứa biết chắc một node đã chết; chúng tạo ra một phán đoán đủ nhanh, có thể định lượng và an toàn khi sai. Thành công nằm ở việc kết hợp detector với suspicion, versioning, fencing và giới hạn blast radius.

Tài liệu tham khảo

• Cornell University: SWIM - Scalable Weakly-consistent Infection-style Process Group Membership Protocol
• JAIST Repository: The Phi Accrual Failure Detector
• Lifeguard: Local Health Awareness for More Accurate Failure Detection
• HashiCorp memberlist: Gossip-based membership library