Bạn có 10.000 server cần biết cùng một thông tin, ví dụ node nào vừa chết, cấu hình nào vừa đổi. Gửi broadcast cho tất cả cùng lúc thì nghẽn mạng. Gửi qua một server trung tâm thì server đó thành điểm chết. Gossip protocol giải bài toán này bằng cách mô phỏng kiểu tin đồn lan truyền ngoài đời thực.

Nguyên lý hoạt động

Mỗi node định kỳ chọn ngẫu nhiên một vài node khác rồi gửi cho chúng thông tin mới nhất mình biết. Node nhận được sẽ hợp nhất thông tin đó với dữ liệu của mình, rồi ngẫu nhiên chọn vài node khác để gửi tiếp. Quá trình này lặp lại liên tục. Không cần leader, không cần cơ chế đồng thuận, cũng không cần biết topology mạng. Mỗi vòng gossip, số node biết thông tin tăng theo cấp số nhân: 1 → 3 → 9 → 27. Với 10.000 node, chỉ cần khoảng 8 đến 10 vòng để toàn bộ cluster đều nhận được tin.

Ba biến thể chính

Push gossip là dạng đơn giản nhất: node chủ động gửi thông tin mới cho node được chọn ngẫu nhiên. Pull gossip thì ngược lại: node định kỳ hỏi node khác "có gì mới không?". Push-pull kết hợp cả hai: hai node trao đổi qua lại để đồng bộ. Push hiệu quả khi thông tin mới xuất hiện và cần lan nhanh. Pull hiệu quả hơn khi phần lớn node đã có thông tin, chỉ còn vài node chưa cập nhật. Trong thực tế, hầu hết hệ thống dùng push-pull để cân bằng.

Ứng dụng thực tế

Amazon DynamoDB dùng gossip để các node chia sẻ thông tin thành viên, biết node nào đang hoạt động. Apache Cassandra dùng gossip để trao đổi trạng thái cluster: tải CPU, dung lượng đĩa, phiên bản schema. HashiCorp Consul dùng thư viện Serf (dựa trên giao thức SWIM, một biến thể của gossip) để phát hiện node chết trong vòng vài giây mà không cần health check tập trung.

Ưu và nhược điểm

Gossip protocol có khả năng chịu lỗi cao vì không phụ thuộc vào bất kỳ node riêng lẻ nào. Khi một node chết, các node khác vẫn tiếp tục gossip bình thường. Băng thông tiêu thụ ổn định vì mỗi node chỉ giao tiếp với một số lượng cố định node mỗi vòng, bất kể cluster có 100 hay 100.000 node. Nhược điểm lớn nhất là tính nhất quán cuối cùng: không có gì đảm bảo tất cả node có cùng thông tin tại một thời điểm. Gossip cũng tạo ra lưu lượng dư thừa vì cùng một thông tin được gửi nhiều lần qua nhiều đường. Để giảm lãng phí, các hệ thống thường đánh dấu thông tin đã nhận và chỉ gửi phần thay đổi thay vì toàn bộ trạng thái.

Nếu bạn đang xây dựng hệ thống phân tán và cần một cơ chế phát hiện lỗi hoặc đồng bộ metadata nhẹ, gossip protocol là lựa chọn đáng cân nhắc. Nó không thay thế được consensus protocol như Raft cho những quyết định cần tính nhất quán tuyệt đối, nhưng với những tác vụ "biết sớm hay muộn đều được", gossip vừa đơn giản vừa gần như không thể chết.