26 | 从Ping-Pong消息学习Gossip协议的实现

1、多个节点组成一个分布式系统，它们之间需要交换数据，可以采用中心化的方式（依赖第三方系统，例如ZK），也可以采用非中心化（分布式协议，例如 Gossip）的方式 2、Redis Cluster 采用非中心化的方式 Gossip 协议，实现多个节点之间信息交换 3、集群中的每个实例，会按照固定频率，从集群中「随机」挑选部分实例，发送 PING 消息（自身实例状态、已知部分实例信息、slots 分布），用来交换彼此状态信息 4、收到 PING 的实例，会响应 PONG 消息，PONG 消息和 PING 消息格式一样，包含了自身实例状态、已知部分实例信息、slots 分布 5、这样经过几次交换后，集群中每个实例都能拿到其它实例的状态信息 6、即使有节点状态发生变化（新实例加入、节点故障、数据迁移），也可以通过 Gossip 协议的 PING-PONG 消息完成整个集群状态在每个实例上的同步 课后题：为什么 clusterSendPing 函数计算 wanted 值时，是用的集群节点个数的十分之一？ 这个和 Redis Cluster 判定实例「故障」逻辑有关了。 Redis Cluster 实例在周期性向其它实例交换信息时，会先随机选出 5 个实例，然后从中找出最久没通信过的实例，发送 PING 消息。 但这里有个问题，随机选出的这 5 个实例，有可能并不是整个「集群」中最久没通信过的，为了避免拿不到这些实例的状态，导致集群误以为这些实例已过期，所以制定了一个策略：如果和实例最近通信时间超过了 cluster-node-timeout / 2，那会立即向这个实例发送 PING 消息。 每次 PING 都会收到 PONG 响应，一来一回 2 次心跳包，来回都带有部分实例的状态信息，那在 cluster-node-timeout 时间内会收到 4 次心跳包。 又因为 Redis Cluster 计算故障转移超时时间是 cluster-node-timeout * 2，那这段时间内就能收到 8 个 PING + PONG 心跳包，每个心跳包中实例个数设置为集群的 1/10，那在故障转移期间就能收到集群 80%（8 * 1/10）节点发来的故障状态信息了，满足集群大部分节点发来的节点故障情况。

关于PING消息 用的集群节点个数的十分之一作为wanted值如课代表所说，但是在我阅读源码的时候发现，PING消息是先把wanted数量的实例放到消息体，然后再把所有当前nodes认为是PFAIL的实例放到消息体末尾，也就是说，新版的redis实例加速了 PFAIL->FAIL的判断，跟十分之一的关系已经不大了。 PS: 当时看这段代码的时候非常疑惑，看源码的注释也很疑惑...直到翻阅github上面的提交记录 https://github.com/redis/redis/commit/1e659a04cf19e4349c8dbba931d1606336970b8c#diff-55c2de0fa49d05f6ed8f0c13cacedc85fba5d5739c8360567743f9f740df3179 /* If there are PFAIL nodes, add them at the end. */ if (pfail_wanted) { dictIterator *di; dictEntry *de; di = dictGetSafeIterator(server.cluster->nodes); while((de = dictNext(di)) != NULL && pfail_wanted > 0) { clusterNode *node = dictGetVal(de); if (node->flags & CLUSTER_NODE_HANDSHAKE) continue; if (node->flags & CLUSTER_NODE_NOADDR) continue; if (!(node->flags & CLUSTER_NODE_PFAIL)) continue; clusterSetGossipEntry(hdr,gossipcount,node); freshnodes--; gossipcount++; /* We take the count of the slots we allocated, since the * PFAIL stats may not match perfectly with the current number * of PFAIL nodes. */ pfail_wanted--; } dictReleaseIterator(di); }

主从如何做故障切换的 不讲一下吗？

为何选择了1/10的节点，在源码注释里其实就有，分两部分解释一下： 一、在clusterCron函数中，有一个强制PING策略： 如果节点A和节点B最后通信时间超过了 cluster-node-timeout/2，节点A会立即向节点B发送 PING 消息。所以，在在cluster-node-timeout时间内，节点A和节点B最少也会收发2来2回共4次心跳包。 Redis Cluster计算故障转移确认时间是cluster-node-timeout*2，那这段时间内节点A和节点B最少会收发4来4回共8个心跳包。 二、在一个100个全master节点的集群中，有一个正常节点A，一个被A判断为PFAIL节点C，在没有pfail_wanted的时候： 对于节点A，在cluster-node-timeout*2的故障转移确认时间内，最少也可以与他节点交换关于C节点到这么多个包： PROB * GOSSIP_ENTRIES_PER_PACKET * TOTAL_PACKETS (节点C被包含在一个entry中的几率，100选1，也就是1%)*(一个GOSSIP包中的entry数量，10分之1，100个节点网络中是10)*（其他节点与A交换的最小总包数，节点数*8） 1%*10*(100*8)=80 由于这些包都是随机选择entry的，节点A收发的这80个包含C节点信息的包，也就是与A交换过C节点信息的节点也差不多为80个，大概率覆盖了100个节点的多数节点，也就可以确实证明了C点有问题了。 为何不再高一些：现在这个比例已经够高了，如果再高一些，只会增加网络负担而已。而且，收发8个包已经是最差情况了，平时比8个包还会多一些。 同时，在4.x的源码中，已经补充了pfail_wanted的代码，会让PFAIL节点更快的传播。 为何不再低一些：在正常的redis cluster集群中，有一些slave节点，不会参与投票，所以保持了这样一个比例。 此外，这里就是个估算，别纠结为何用100不用99或98什么的，不影响结论。也不用纠结这80个包，如果收发全部重叠，不就只有40个节点交换信息吗，估算时不要考虑小概率时间。

这个达到最终一致性是Gossip中的谣言传播吗

老师我想问一下，我遇到一个问题，就是一个正常集群由于节点故障产生了一条fail信息，没有及时清理，这个ip又被别的集群使用了，请问这个是ping pong信息交换的，还是meet呢