关于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个节点交换信息吗，估算时不要考虑小概率时间。