Giao thức Gossip để lan truyền trạng thái phân tán

1. Tổng quan

A. Định nghĩa

Giao thức Gossip là giao thức truyền thông phân tán có tính xác suất, trong đó một node trao đổi trạng thái, sự kiện hoặc membership với một số peer rồi các peer tiếp tục chuyển tiếp thông tin sang những peer khác.

Tên gọi xuất phát từ cách một tin đồn lan truyền giữa nhiều người. Một người nói cho vài người, người nghe lại nói cho vài người khác. Sau đủ nhiều round, phần lớn thành viên biết cùng một sự kiện dù không có broadcast hoàn hảo. Trong hệ thống phân tán, mô hình này được dùng cho phát hiện lỗi, membership, metadata, vô hiệu hóa cache và lan truyền sự kiện.

Gossip không cần coordinator trung tâm hay cây broadcast nối mọi node. Vì vậy nó giảm bottleneck và single point of failure. Đổi lại, nó không bảo đảm mọi node nhận thông tin ngay lập tức hoặc theo cùng một thứ tự. Kỹ sư chuyên nghiệp phải cân bằng thời gian hội tụ, lưu lượng, nhất quán tạm thời và cô lập lỗi.

B. Bối cảnh và nhu cầu

Một dịch vụ trạng thái trung tâm đơn giản khi cluster nhỏ, nhưng giới hạn về thông lượng và phục hồi ảnh hưởng đến toàn hệ thống. Trao đổi all-to-all cũng tăng nhanh số kết nối và message khi số node tăng. Gossip cho phép mỗi node chỉ chọn một số peer, nhờ đó chi phí được phân tán.

Trạng thái phân tán thay đổi liên tục vì node tham gia hoặc rời đi, network partition và update đến theo thứ tự khác nhau. Trong nhiều trường hợp, hội tụ sau khi communication phục hồi thực tế hơn là yêu cầu mọi node thấy cùng một giá trị ở mọi thời điểm. Gossip là kỹ thuật lan truyền để đạt eventual convergence, không phải thay thế cho consensus giao dịch.

C. Đặc trưng

Các đặc trưng chính là phân tán, lan truyền xác suất, dư thừa, quan sát cục bộ và hội tụ cuối cùng. Nhiều đường truyền giúp hệ thống chịu được mất một phần packet. Vì một event có thể đến nhiều lần, update phải idempotent và mang event ID hoặc version.

2. Mô hình hoạt động

A. Thành phần

Một hệ thống cần node identity, bộ chọn peer, trạng thái cần lan truyền, event hoặc version và chu kỳ gửi. Nên kết hợp identity với generation để process khởi động lại không bị nhầm với process cũ. Bộ chọn peer chọn số lượng fanout từ danh sách node khỏe, có thể ngẫu nhiên hoặc nhận biết topology.

Có thể dùng Lamport clock, vector clock, hybrid logical clock, revision hoặc sequence theo domain. Lựa chọn phụ thuộc vào việc có cần phát hiện update đồng thời và hàm merge hay không. Phải định nghĩa trước Last-Write-Wins có an toàn không, có giữ nhiều version không và đâu là source of truth.

B. Một round

Node đưa thay đổi cục bộ vào queue. Khi timer phát sinh, nó chọn một số peer rồi trao đổi summary hoặc danh sách event. Peer loại bỏ version đã xử lý, lưu thông tin mới và đưa thông tin đó vào candidate của round sau.

flowchart LR
    A[Node A đổi trạng thái] --> Q[Đưa vào queue và gán version]
    Q --> S[Chọn k peer]
    S --> B[Trao đổi với node B]
    S --> C[Trao đổi với node C]
    B --> M[Loại trùng và merge]
    C --> M
    M --> R[Cập nhật trạng thái cục bộ]
    R --> N[Candidate của round sau]
    N --> S

Trạng thái membership nhỏ có thể gửi toàn bộ, còn tập event lớn nên dùng digest hoặc version vector để so sánh trước. Sau khi phát hiện khác biệt, hai bên chỉ lấy các mục còn thiếu. Summary vẫn cần được kiểm tra chính xác ở bước đồng bộ cuối vì có thể có collision hoặc false positive.

C. Push, Pull và Push-Pull

Push là node có thông tin mới chủ động gửi cho peer. Push có độ trễ thấp nhưng tạo message trùng và tải cho receiver. Pull là node hỏi summary rồi lấy phần còn thiếu; cách này hợp với trạng thái lớn nhưng có độ trễ polling. Push-Pull kết hợp hai cách, trao đổi summary và bù phần thiếu của cả hai phía.

Chế độ	Ưu điểm	Nhược điểm	Sử dụng
Push	Phát hiện nhanh	Trùng lặp và tải receiver	Event nhỏ, khẩn cấp
Pull	Chỉ lấy phần thiếu	Chi phí polling	Trạng thái lớn
Push-Pull	Cân bằng tốc độ và sửa thiếu	Phức tạp hơn	Membership và metadata

3. Phát hiện lỗi dựa trên Gossip

A. Probe trực tiếp và gián tiếp

Probe trực tiếp gửi ping và coi peer lỗi khi không nhận response. Network delay, GC pause hoặc process quá tải cũng gây cùng triệu chứng. Do đó một timeout nên chuyển sang suspect trước, không xóa node ngay.

Với probe gián tiếp, A nhờ C kiểm tra B khi A không thể tới B. Nếu C tới được B, lỗi có thể nằm trên đường A-B. Nếu nhiều đường độc lập đều thất bại, độ tin cậy của nghi ngờ tăng lên.

B. Chuyển trạng thái kiểu SWIM

Thiết kế kiểu SWIM kết hợp probe định kỳ, probe gián tiếp và lan truyền suspect. Monitor chọn target, kiểm tra trực tiếp, rồi nhờ node khác kiểm tra khi thất bại. Nếu không xác nhận được, monitor gossip bản ghi suspect; thông báo alive có thể hủy nghi ngờ trước deadline.

sequenceDiagram
    participant A as Monitor A
    participant B as Target B
    participant C as Checker C
    participant G as Cluster
    A->>B: Probe trực tiếp
    B--xA: Response chậm hoặc mất
    A->>C: Nhờ kiểm tra B
    C->>B: Probe gián tiếp
    C-->>A: Kết quả
    A->>G: Gossip suspect(B)
    G-->>B: Thông báo trạng thái
    B-->>G: Alive hoặc dead

Timeout ngắn không phải luôn tốt hơn. Timeout ngắn phát hiện nhanh nhưng tăng false positive; timeout dài giảm false positive nhưng để node lỗi nhận traffic lâu hơn. RTT, retry, GC pause và các đoạn mạng phải được đo để chọn giá trị.

C. Generation và membership

Membership thường có các trạng thái alive, suspect và dead. Khi process dead khởi động lại, message cũ đến trễ không được làm hỏng trạng thái mới. Incarnation hoặc generation number giúp receiver bỏ qua bản ghi thế hệ cũ. Chính sách cũng phải nêu rõ xóa dead ngay hay giữ grace period để phục hồi.

4. Nhất quán và xử lý xung đột

Nếu communication phục hồi và update dừng lại, các node khỏe phải hội tụ về cùng trạng thái. Hàm merge phải deterministic với cùng một tập input. Revision phù hợp cho cấu hình đơn giản nhưng không luôn diễn tả được ý nghĩa của hai thay đổi đồng thời. Có thể cần merge theo field, giữ nhiều version, xác nhận của ứng dụng hoặc đường consensus.

Event ID và deduplication cache giúp loại xử lý lặp. set active là idempotent, còn increase balance không idempotent. Với thao tác không idempotent, kết hợp event ledger, sequence check, CRDT counter hoặc nguồn dữ liệu giao dịch.

Trong network partition, hai nhóm có thể cập nhật độc lập. Khi nối lại, chỉ chọn event đến cuối cùng có thể làm mất một update đồng thời. Membership có thể chịu bất nhất tạm thời, trong khi số dư và tồn kho thường cần quorum hoặc storage tuyến tính hóa.

5. So sánh với phương thức khác

Central broadcast dễ quản lý thứ tự nhưng phụ thuộc capacity và phục hồi của một thành phần. Consensus log cung cấp thứ tự mạnh nhưng phải trả chi phí quorum và xử lý lỗi leader. Message queue cung cấp lưu trữ, replay và chính sách giao nhận giữa producer và consumer. Có thể dùng queue cho business event và Gossip cho health, discovery hoặc metadata.

Tiêu chí	Gossip	Broadcast trung tâm	Consensus log	Message queue
Mở rộng	Phân tán theo peer	Giới hạn trung tâm	Leader và quorum	Cluster broker
Nhất quán	Hội tụ cuối	Tùy chính sách	Thứ tự mạnh	Chính sách giao nhận
Dùng cho	Membership, state	Thông báo cấu hình	Ledger, state machine	Business event

6. Trường hợp áp dụng

Trong service discovery, instance gossip địa chỉ, port, zone, version và health. Client phân biệt alive và suspect, giảm route mới tới instance bị nghi ngờ. Trong cache invalidation, có thể truyền event product 123, revision 42 thay vì gửi toàn bộ record. Giá và tồn kho quan trọng vẫn nên đọc lại source of truth vì độ trễ Gossip không bảo đảm vô hiệu hóa tức thời.

Event vận hành nên có thời gian nguồn, generation, hop count và thời gian forward cuối. Theo dõi p50, p95 của độ trễ, tỷ lệ member không tới được, tỷ lệ trùng và false-positive suspect. Hop tăng liên tục hoặc traffic dồn vào peer cho thấy cần điều chỉnh fanout, chọn peer hoặc chu kỳ.

7. Chuyên sâu và tuning

Fanout lớn tăng khả năng đến nơi trong một round nhưng cũng tăng CPU, network và message trùng. Fanout nhỏ làm đuôi hội tụ dài. Phải kiểm thử theo số node, tỷ lệ mất packet và ngân sách traffic thay vì sao chép một giá trị cho mọi môi trường.

Chọn peer từ nhiều rack hoặc availability zone để tránh lỗi chung làm mất đường truyền. Có thể ưu tiên peer cục bộ và dành một phần lựa chọn cho zone hoặc region từ xa. Với state lớn, dùng digest, delta compression, anti-entropy và tombstone retention. Xóa tombstone sớm có thể làm node cũ phục hồi dữ liệu đã bị xóa.

8. Cân nhắc và hàm ý

A. Phân loại yêu cầu nhất quán

Phân loại từng dữ liệu theo độ trễ cho phép, khả năng mất và khả năng phục hồi conflict. Service discovery có thể dùng eventual convergence, nhưng thanh toán và giữ chỗ tồn kho thường cần đường mạnh hơn.

B. Coi phát hiện lỗi là ước lượng

Network delay có thể làm node khỏe thành suspect. Dùng probe gián tiếp, kiểm tra lại, quorum và grace period trước automation phá hủy. Đo cả false positive và missed failure.

C. Bảo vệ trust boundary

Gossip có thể chứa địa chỉ, version và health. Dùng xác thực peer, mutual TLS, chữ ký khi cần, chống replay và nguyên tắc tối thiểu thông tin. Không chỉ dựa vào reputation score để chống node độc hại.

D. Đảm bảo observability

Propagation ngẫu nhiên khó tái hiện sau sự cố. Lưu event ID, generation, hop, timestamp và peer đã chọn theo chính sách riêng tư. Nếu không lưu payload, giữ hash, summary và sample.

E. Xác định source of truth

Tách gossip trạng thái khỏi đường xử lý giao dịch. Tài liệu phải nêu cách rebuild trạng thái sau restart, loại message cũ và giữ tombstone bao lâu.

F. Kiểm thử điều kiện xấu nhất

Kết hợp network partition, restart storm, mất packet, version skew và lỗi region trong kiểm thử. Định nghĩa mục tiêu bằng percentile và xác suất, chẳng hạn 99% member nhận trong năm giây.

9. Tóm tắt một câu

Gossip lan truyền thông tin bằng trao đổi lặp lại và dư thừa giữa một số peer, nhưng hội tụ, trùng lặp, nghi ngờ sai và conflict phải được thiết kế rõ ràng.

---

Tóm tắt một câu: Gossip giúp cluster học trạng thái qua trao đổi peer mà không cần bottleneck trung tâm; dữ liệu yêu cầu nhất quán mạnh phải đi qua nguồn có thẩm quyền riêng.