各位有梦想的阿猿大家好，我是初昕之旅，您技术成长之路上的好帮手。今天继续更新《来道题》系列，每天一道面试题，年薪百万来找你~

对于Redis集群包含的多个节点之间，每个节点会参与到请求响应、槽管理、故障恢复等众多的功能中，那么整个集群的信息再每个节点之间是如何进行通信的呢？今天我们就来聊下Redis的节点通信方式，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：四种消息的类型
配置纪元：集群信息的最新版本

那么等下次面试时，如果各位同学能够回答出来以上的知识点，我相信面试官一定会对咱们刮目相看的，一看就是一个热爱学习、有思考的好工程师。每天一道面试题，年薪百万来找你~

附视频讲解：

「来道题」Redis的Gossip协议

「来道题」Redis的Gossip协议相关推荐

Redis Cluster Gossip 协议详解
Redis Cluster Gossip 协议大家好,我是历小冰,今天来讲一下 Reids Cluster 的 Gossip 协议和集群操作,文章的思维导图如下所示. 集群模式和 Gossip 简介 ...
一万字详解 Redis Cluster Gossip 协议
大家好,我是历小冰,今天来讲一下 Reids Cluster 的 Gossip 协议和集群操作,文章的思维导图如下所示. 集群模式和 Gossip 简介对于数据存储领域,当数据量或者请求流量大到一定 ...
redis哨兵主从不切换_《「面试突击」—Redis篇》-- Redis的主从复制？哨兵机制？...
Redis如何保证高并发,高可用? 高并发:redis的单机吞吐量可以达到几万不是问题,如果想提高redis的读写能力,可以用redis的主从架构,redis天热支持一主多从的准备模式,单主负责写请求 ...
深入解析redis cluster gossip机制
社区版redis cluster是一个P2P无中心节点的集群架构,依靠gossip协议传播协同自动化修复集群的状态.本文将深入redis cluster gossip协议的细节,剖析redis clu ...
「分布式技术专题」基于Gossip协议的去中心服务
概述 Gossip 协议可以翻译为流言协议.它是在 1987 年发表在 ACM 上的论文 <Epidemic Algorithms for Replicated Database Mainten ...
ADAS自动驾驶辅助系统通讯协议「ADASIS Protocol」接口定义解析（二）详细
「ADASIS Protocol Introduction」 --信号接口解析本文来自微信公众号:[阿波兹得][续]ADASIS Protocol介绍 (2) 信号解析https://mp.weix ...
Redis作者Antirez经历的「性别歧视」风波
本篇文章是2012年Redis作者发表的关于性别歧视的博客,文章推出后,引来了轩然大波,骂声一片.这可能是antirez在互联网上经历的最黑暗的一段时间了.这里我将他的博文翻译出来分享给大家一起观察作 ...
SOME/IP协议详解「总目录」
SOME/IP协议详解「总目录」欢迎大家来到雪云飞星的<SOME/IP协议详解>,开始前博主先列出本专栏学习的大纲,同时这也可以作为大家学习SOME/IP协议知识点的参考.下面蓝字都是传 ...
2 -「季淳卿」 Redis 字符串+哈希
这里写目录标题 String(字符串) Hash(哈希) 1 -「季淳卿」 Redis基本介绍和String练习开始下回分解 String(字符串) 代码如下: #-- 1 strlen key 查 ...

「来道题」Redis的Gossip协议

Gossip协议

消息的类型

解析消息

「来道题」Redis的Gossip协议相关推荐

最新文章

热门文章