面试官：知道zookeeper如何选举吗？
我：知道。然后!#￥￥%……&&%%##%%##!@。
面试官：挺好，那你知道redis集群吗？
我：知道。
面试官：那Gossip协议了解过吗？
我：猝~
说来尴尬，redis集群、主从同步原理我都了解过，但是Gossip协议，确实第一次听说。话不多说，上详解！
Gossip 定义
Gossip protocol 也叫 Epidemic Protocol （流行病协议），是基于流行病传播方式的节点或者进程之间信息交换的协议。
因此 Gossip 有众多的别名，如“闲话算法”、“疫情传播算法”、“病毒感染算法”、“谣言传播算法”。
Gossip 特点
在一个有界网络中，每个节点都随机地与其它节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其它节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终它们的状态都是一致的。即使有的节点因宕机而重启，有新节点加入，但经过一段时间后，这些节点的状态也会与其他节点达成一致，也就是说，Gossip 天然具有分布式容错的优点。
Gossip 本质
Gossip 是一个带冗余的容错算法，更进一步，Gossip 是一个最终一致性算法。虽然无法保证在某个时刻所有节点状态一致，但可以保证在“最终”所有节点一致，“最终”是一个现实中存在，但理论上无法证明的时间点。
因为 Gossip 不要求节点知道所有其它节点，因此又具有去中心化的特点，节点之间完全对等，不需要任何的中心节点。实际上 Gossip 可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。
但 Gossip 的缺点也很明显，冗余通信会对网路带宽、CUP 资源造成很大的负载，而这些负载又受限于通信频率，该频率又影响着算法收敛的速度，下文中，我将结合 Redis 源码详细解释。
Gossip在Redis Cluster的作用
Redis Cluster原理
Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。 一组Redis Cluster是由多个Redis实例组成，官方推荐使用6实例，其中3个为主节点，3个为从节点。一旦有主节点发生故障的时候，Redis Cluster可以选举出对应的从节点成为新的主节点，继续对外服务，从而保证服务的高可用性。
Redis 集群实现的基础是分片，即将数据集有机的分割为多个片，并将这些分片指派给多个 Redis 实例，每个实例只保存总数据集的一个子集。利用多台计算机内存和来支持更大的数据库，而避免受限于单机的内存容量；通过多核计算机集群，可有效扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。
进行读写操作时，Key 对应的 Slot 可能并不在当前直连的节点上，经过“重定向”才能转发到正确的节点。如上图所示，我们直接登录 127.0.0.1:6379 客户端，进行 Set 操作，当 Key 对应的 Slot 不在当前节点时（如 key-test)，客户端会报错并返回正确节点的 IP 和端口。Set 成功则返回 OK。
所以，redis的每个节点，都需要保存自己的集群状态、所有节点、槽位信息等。这些信息如何做到全局一致呢？这时Gossip协议就有了发挥的地方。redis的集群信息，变化并不频繁。因此这些信息只需要最终一致即可。Goosip在redis cluster中可以充分发挥其优势。使得redis cluster达到信息最终一致。
Gossip协议优点：
-
协议简单，实现起来很方便
-
扩展性强，可以允许集群内节点任意增加或者减少，新增节点最终会与其他节点一致
-
去中心化，节点之间是完全对等的
-
最终一致性
缺点：
-
数据同步延迟，因为只保证最终一致性，所以会出现某个时间点，部分节点数据不同步的情况
-
传输数据冗余，相同数据在节点间会反复被传输