分布式Redis深度历险

，比如说不会去加载RDB文件以及AOF文件，本身也不会存储业务数据。

与主服务器建立连接

Sentinel启动后，会与配置文件中提供的所有主服务器建立两个连接，一个是命令连接，一个是订阅连接。

命令连接用于向服务器发送命令。

订阅连接则是用于订阅服务器的_sentinel_:hello频道，用于获取其他Sentinel信息，下文会详细说。

获取主服务器信息

Sentinel会以一定频率向主服务器发送Info命令获取信息，包括主服务器自身的信息比如说服务器id等，以及对应的从服务器信息，包括ip和port。Sentinel会根据info命令返回的信息更新自己保存的服务器信息，并会与从服务器建立连接。

获取从服务器信息

与和主服务器的交互相似，Sentinel也会以一定频率通过Info命令获取从服务器信息，包括：从服务器ID，从服务器与主服务器的连接状态，从服务器的优先级，从服务器的复制偏移等等。

向服务器订阅和发布消息

在如何保障集群高可用小节留下了一个疑问：用如何保证监视服务器的高可用? 在这里我们可以先给出简单回答：用一个监视服务器集群(也就是Sentinel集群)。如何实现，如何保证监视服务器的一致性暂且先不说，我们只要记住需要用若干台Sentinel来保障高可用，那一个Sentinel是如何感知其他的Sentinel的呢?

前面说过，Sentinel在与服务器建立连接时，会建立两个连接，其中一个是订阅连接。Sentinel会定时的通过订阅连接向_sentinel_:hello频道频道发送消息(对Redis发布订阅功能不太了解的同学可以去去了解下)，其中包括：

• Sentinel本身的信息，如ip地址、端口号、配置纪元(见下文)等
• Sentinel监视的主服务器的信息，包括ip、端口、配置纪元(见下文)等

同时，Sentinel也会订阅_sentinel_:hello频道的消息，也就是说Sentinel即向该频道发布消息，又从该频道订阅消息。则忽略，否则将更新sentinels中的内容，并对新的Sentinel建立连接。

主观下线

Sentinel默认会以每秒一次的频率向所有建立连接的服务器(主服务器，从服务器，Sentinel服务器)发送PING命令，如果在down-after-milliseconds内都没有收到有效回复,Sentinel会将该服务器标记为主观下线，代表该Sentinel认为这台服务器已经下线了。需要注意的是不同Sentinel的down-after-milliseconds是可以不同的。

客观下线

为了确保服务器真的已经下线，当Sentinel将某个服务器标记为主观下线后，它会向其他的Sentinel实例发送Sentinel is-master-down-by-addr命令，接收到该命令的Sentinel实例会回复主服务器的状态，代表该Sentinel对该主服务器的连接情况。

Sentinel会统计发出的所有Sentinel is-master-down-by-addr命令的回复，并统计同意将主服务器下线的数量，如果该数量超出了某个阈值，就会将该主服务器标记为客观下线。

选举领头Sentinel

当Sentinel将一个主服务器标记为客观下线后，监视该服务器的各个Sentinel会通过Raft算法进行协商，选举出一个领头的Sentinel。

建议你先看Raft算法的基础知识，再来看下文。

规则：

所有的Sentinel都有可能成为领头Sentinel的资格

每次选举后，无论有没有选出领头Sentinel，配置纪元都会+1

在某个纪元里，每个Sentinel都有为投票的机会

我们称要求其他人选举自己的Sentinel称为源Sentinel，将被要求投票的Sentinel称为目标Sentinel

每个发现主服务器被标记为客观下线且还没有被其他

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!