19、Redis的Gossip协议

对于Redis集群包含的多个节点之间，每个节点会参与到请求响应、槽管理、故障恢复等众多的功能中，那么整个集群的信息再每个节点之间是如何进行通信的呢？今天我们就来聊下Redis的节点通信方式，Gossip协议。 Gossip本质是降低集群节点通讯次数，让相邻的节点通讯，获取结果后，带着结果传播给下一个相邻节点。

一、Gossip协议

 首先给出Gossip协议的定义：节点每秒随机选择超时的节点进行通信，包含其他节点的信息，最终全部节点都会获得集群的完整信息。

我们知道节点之间存在心跳检测的行为，也就是节点之间是定时都会进行通信的，来维持在线状态的节点信息，这些信息包括主从节点、节点和槽的关系等，会在每个节点的本地进行存储。而这些信息不仅仅只是存储在自己的本地，同时在和其他节点进行心跳检测时，每个节点会从自己本地已知的节点信息中，带上一部分放到通信的包体中，一起发送出去。接受到请求的节点，会根据收到的信息和自己本地的信息进行比对，做一些更新的处理。等到这个节点也和其他节点进行通信时，同样地也会把最新的集群信息带在通信的包体中，传递给其他节点。在这个过程中，通过每个节点之间的一次次传递信息，虽然不会在第一时间让整个集群的节点一下子全部更新到最新版本的信息，但是最终全部的节点，都还是能够获得集群的完整信息的。

那每个节点该怎么选择要通信的节点呢？节点本身会维护和周边节点的上次通信时间，假设配置的心跳检测的间隔时间是4s，节点会检查通信过的节点中，距离上次通信时间有没有超过最大通信时间限制的一半的，也就是4s的一半2s，如果有一些节点已经超过2s都没有联系过了，那就随机选择其中的一些进行一次通信。这里的设计其实是考虑的整个网络通信环境的稳定，避免一次性触发大量的连接。

如图所示，比如集群中新加入了一个节点，它首先根据管理员提供的信息和邻近的节点进行一次通信，编号1的节点收到新的信息后，等到下一个通信间隔，它随机地找到了编号2和另外一个节点进行通信，同时发送了最新的信息；然后编号2的节点也随机找到了编号3的节点来同步最新的信息。通过这样的过程，所有的节点最终都会知道有一个新节点加入了集群。

二、消息的类型

 

那Redis节点间通信的消息都包含哪些类型呢？

• Ping消息：用于检测节点是否在线，或者交换信息，也就是我们刚才提到的心跳检测时会使用的
• Pong消息：接受到Ping消息的节点，会响应一个Pong格式的消息，将自身的状态返回给请求的节点
• Meet消息：通知新节点的加入，比如刚才的图中提到的情况，每个节点之间发送的就是Meet消息
• Fail消息：广播节点下线，比如出现了节点故障，摘除机器后需要让节点知道不再和已下线的节点进行通信了
• Publish消息：其他数据监听机制下的广播消息
• Failover消息：出现故障时，进行选举的请求和投票
• Update消息：Redis的一致性哈希数据分区，会有槽和节点的对应关系，如果发生扩容或缩容，需要告诉节点进行槽的更新

当然除以上消息类型之外，还有其他的消息体，但在此之中，Ping、Pong、Meet、Fail是面试时最为常见的考点，各位同学重点要把这4个消息给记住。

三、解析消息

收到消息之后，每个节点还需要根据不同的情况对消息进行处理，也就是如何去解析消息。一般上我们分为两种情况：

• 新节点：如果消息的来源是该节点的本地没有记录过的新节点，那么会将这个新节点的信息加入的每个节点自己维护在本地的节点列表中，并更新上次通信时间为现在，之后会向这个新节点发起握手，来创建连接。
• 已知节点：而如果之前这两个节点已经通信过了，在进行惯例地检测时，则会比较一下本地和发送过来的信息是否一致，比如节点和槽之间的映射关系、主从节点的角色等等。

这里有一个新的知识点是配置纪元，就是说我这个节点收到了一个不一致的槽关系的消息时，我怎么知道是不是最新的呢？万一是因为网络延迟等原因，可能其他节点已经告诉过我最新的关系情况了，但是延后来的消息又把槽关系给改回去了，这肯定是不行的。所以集群信息是有版本的，也就是配置纪元通过递增的版本号来标记集群信息的版本，防止过时消息的污染。这样再进行本地和收到的消息的比较时，节点就可以检查下是不是比我本地的版本要大的，如果是则更新成最新的，否则忽略掉就可以了。

 那么以上就是今天讲的Redis的Gossip协议的相关面试考点，我们最后再来简单回顾一下：

• 随机通信，最终一致：节点并不要求即时生效，通过随机选择节点，传递本地已知信息的方式，达到集群信息在各节点中的最终一致的效果。
• Ping、Pong、Meet、Fail：四种消息的类型
• 配置纪元：集群信息的最新版本