哨兵 Sentinel | 彩潭有鲤的札记

type

status

date

slug

summary

启动并初始化Sentinel

启动一个Sentinel可以使用命令：

或者命令：

当一个Sentinel启动时，它需要执行以下步骤：

初始化服务器

Sentinel本质上只是一个运行在特殊模式下的Redis服务器，启动Sentinel的第一步，就是初始化一个普通的Redis服务器。不过，因为Sentinel执行的工作和普通Redis服务器执行的工作不同，所以Sentinel的初始化过程和普通Redis服务器的初始化过程并不完全相同。

比如说，普通服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态，但是因为Sentinel并不使用数据库，所以初始化Sentinel时就不会载入RDB文件或者AOF文件。

将普通Redis服务器使用的代码替换成Sentinel专用代码

将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。比如说，普通Redis服务器使用redis.h/REDIS_SERVERPORT常量的值作为服务器端口：

而Sentinel则使用sentinel.c/REDIS_SENTINEL_PORT 常量的值作为服务器端口：

除此之外，普通 Redis 服务器使用 redis.c/redisCommandTable 作为服务器的命令表：

而Sentinel则使用sentinel.c/sentinelcmds作为服务器的命令表，并且其中的INFO命令会使用Sentinel模式下的专用实现sentinel.c/sentinelInfoCommand函数，而不是普通Redis服务器使用的实现redis.c/infoCommand函数：

sentinelcmds命令表也解释了为什么在Sentinel模式下， Redis服务器不能执行诸如SET 、 DBSIZE 、 EVAL等等这些命令 —— 因为服务器根本没有在命令表中载入这些命令：PING 、SENTINEL、INFO、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE和PUNSUBSCRIBE这七个命令就是客户端可以对Sentinel执行的全部命令了。

初始化Sentinel状态

在应用了Sentinel的专用代码之后，接下来，服务器会初始化一个sentinel.c/sentinelState结构（简称“Sentinel 状态”），这个结构保存了服务器中所有和Sentinel功能有关的状态（服务器的一般状态仍然由redis.h/redisServer 结构保存）：

根据给定的配置文件，初始化Sentinel的监视主服务器列表

Sentinel状态中的masters字典记录了所有被Sentinel监视的主服务器的相关信息，字典的键是被监视主服务器的名字，而字典的值则是被监视主服务器对应的sentinel.c/sentinelRedisInstance结构。

每个sentinelRedisInstance结构（简称“实例结构”）代表一个被Sentinel监视的Redis服务器实例，这个实例可以是主服务器、从服务器、或者另外一个Sentinel 。实例结构包含的属性非常多，以下代码展示了实例结构在表示主服务器时使用的其中一部分属性：

sentinelRedisInstance.addr 属性是一个指向sentinel.c/sentinelAddr结构的指针，这个结构保存着实例的 IP 地址和端口号：

对Sentinel状态的初始化将引发对masters字典的初始化，而masters字典的初始化是根据被载入的Sentinel配置文件来进行的。

如果用户在启动Sentinel时，指定了包含以下内容的配置文件：

那么Sentinel将为主服务器master1创建实例结构：

并为主服务器master2创建实例结构：

而这两个实例结构又会被保存到Sentinel状态的masters字典中：

创建连向主服务器的网络连接

初始化Sentinel的最后一步是创建连向被监视主服务器的网络连接：Sentinel将成为主服务器的客户端，它可以向主服务器发送命令，并从命令回复中获取相关的信息。

对于每个被Sentinel监视的主服务器来说， Sentinel会创建两个连向主服务器的异步网络连接：

一个是命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复

另一个是订阅连接，这个连接专门用于订阅主服务器的__sentinel__:hello频道

为什么有两个连接？

在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丢失这条信息。

因此，为了不丢失__sentinel__:hello频道的任何信息， Sentinel必须专门用一个订阅连接来接收该频道的信息。

而另一方面，除了订阅频道之外，Sentinel还又必须向主服务器发送命令，以此来与主服务器进行通讯，所以Sentinel还必须向主服务器创建命令连接。

并且因为Sentinel需要与多个实例创建多个网络连接，所以Sentinel使用的是异步连接。

获取主服务器信息

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。

假设主服务器master有三个从服务器slave0、slave1和 slave2，并且一个Sentinel正在连接主服务器，那么Sentinel将持续地向主服务器发送INFO命令，并获得回复：

通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面的信息：

关于主服务器本身的信息，包括run_id域记录的服务器运行ID，以及role域记录的服务器角色。

根据run_id域和role域记录的信息，Sentinel将对主服务器的实例结构进行更新，例如，主服务器重启之后，它的运行ID就会和实例结构之前保存的运行ID不同，Sentinel检测到这一情况之后，就会对实例结构的运行ID进行更新

关于主服务器属下所有从服务器的信息，每个从服务器都由一个"slave"字符串开头的行记录，每行的ip=域记录了从服务器的IP地址，而port=域则记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器

主服务器返回的从服务器信息，则会被用于更新主服务器实例结构的slaves字典，这个字典记录了主服务器属下从服务器的名单：

字典的键是由Sentinel自动设置的从服务器名字，格式为ip:port：如对于IP地址为 127.0.0.1，端口号为11111的从服务器来说，Sentinel为它设置的名字就是127.0.0.1:11111

字典的值则是从服务器对应的实例结构：比如说，如果键是127.0.0.1:11111，那么这个键的值就是IP地址为127.0.0.1，端口号为11111的从服务器的实例结构

Sentinel在分析INFO命令中包含的从服务器信息时，会检查从服务器对应的实例结构是否已经存在于slaves字典：

如果从服务器对应的实例结构已经存在，那么Sentinel对从服务器的实例结构进行更新

如果从服务器对应的实例结构不存在，那么说明这个从服务器是新发现的从服务器， Sentinel会在slaves字典中为这个从服务器新创建一个实例结构

图中主服务器实例结构和从服务器实例结构之间的区别：

主服务器实例结构的flags属性的值为SRI_MASTER，而从服务器实例结构的flags属性的值为SRI_SLAVE

主服务器实例结构的name属性的值是用户使用Sentinel配置文件设置的，而从服务器实例结构的name属性的值则是Sentinel根据从服务器的IP地址和端口号自动设置的

获取从服务器信息

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，还会创建连接到从服务器的命令连接和订阅连接。

Sentinel对slave0、slave1和slave2三个从服务器分别创建命令连接和订阅连接：

在创建命令连接之后，Sentinel在默认情况下，会以每十秒一次的频率通过命令连接向从服务器发送INFO命令，并获得类似于以下内容的回复：

根据INFO命令的回复，Sentinel会提取出以下信息：

从服务器的运行ID run_id

从服务器的角色role

主服务器的IP地址master_host，以及主服务器的端口号master_port

主从服务器的连接状态master_link_status

从服务器的优先级slave_priority

从服务器的复制偏移量slave_repl_offset

根据这些信息，Sentinel会对从服务器的实例结构进行更新：

向主服务器和从服务器发送消息（PUBLISHS命令）

在默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令：

这条命令向服务器的__sentinel__:hello频道发送了一条信息，信息的内容由多个参数组成：

以s_开头的参数记录的是Sentinel本身的信息

m_开头的参数记录的则是主服务器的信息

如果Sentinel正在监视的是主服务器，那么这些参数记录的就是主服务器的信息
如果Sentinel正在监视的是从服务器，那么这些参数记录的就是从服务器正在复制的主服务器的信息

一条Sentinel通过PUBLISH命令向主服务器发送的信息示例：

这个示例包含了以下信息：

Sentinel的IP地址为127.0.0.1，端口号为26379，运行ID为e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa，当前的配置纪元为0

主服务器的名字为mymaster，IP地址为127.0.0.1，端口号为6379，当前的配置纪元为0

接收主服务器和从服务器的消息（SUBSCRIBE命令）

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：

Sentinel对__sentinel__:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止

对于每个与Sentinel连接的服务器，Sentinel既通过命令连接向服务器的 __sentinel__:hello频道发送信息，又通过订阅连接从服务器的__sentinel__:hello频道接收信息：

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知，也会被用于更新其他Sentinel对被监视服务器的认知。

假设现在有sentinel1、sentinel2、sentinel3三个Sentinel在监视同一个服务器，那么当sentinel1向服务器的__sentinel__:hello频道发送一条信息时，所有订阅了sentinel:hello频道的Sentinel（包括sentinel1自己在内）都会收到这条信息：

当一个Sentinel从__sentinel__:hello频道收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、Sentinel端口号、Sentinel运行ID等八个参数，并进行以下检查：

如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID相同，那么说明这条信息是Sentinel自己发送的， Sentinel将丢弃这条信息，不做进一步处理

如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID不相同，那么说明这条信息是监视同一个服务器的其他Sentinel发来的，接收信息的Sentinel将根据信息中的各个参数，对相应主服务器的实例结构进行更新

更新sentinels字典

Sentinel为主服务器创建的实例结构中的sentinels字典保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料：

sentinels字典的键是其中一个Sentinel的名字，格式为ip:port，比如对于IP地址为127.0.0.1，端口号为26379的Sentinel来说，这个Sentinel在sentinels字典中的键就是"127.0.0.1:26379"

sentinels字典的值则是键所对应Sentinel的实例结构，比如对于键"127.0.0.1:26379"来说，这个键在sentinels字典中的值就是IP为127.0.0.1，端口号为26379的Sentinel的实例结构

当一个Sentinel接收到其他Sentinel发来的信息时（称发送信息的Sentinel为源 Sentinel，接收信息的Sentinel为目标Sentinel），目标Sentinel会从信息中分析并提取出以下两方面参数：

与Sentinel有关的参数：源Sentinel的IP地址、端口号、运行ID和配置纪元

与主服务器有关的参数：源Sentinel正在监视的主服务器的名字、IP地址、端口号和配置纪元

根据信息中提取出的主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中查找相应的主服务器实例结构，然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels字典中，源Sentinel的实例结构是否存在：

如果源Sentinel的实例结构已经存在，那么对源Sentinel的实例结构进行更新

如果源Sentinel的实例结构不存在，那么说明源Sentinel是刚刚开始监视主服务器的新Sentinel，目标Sentinel会为源Sentinel创建一个新的实例结构，并将这个结构添加到sentinels字典里面

因为一个Sentinel可以通过分析接收到的频道信息来获知其他Sentinel的存在，并通过发送频道信息来让其他Sentinel知道自己的存在，所以用户在使用Sentinel的时候并不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方

创建连向其他`Sentinel`的命令连接

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接，而新Sentinel也同样会创建连向这个Sentinel的命令连接，最终监视同一主服务器的多个Sentinel将形成相互连接的网络：Sentinel A有连向Sentinel B的命令连接，而Sentinel B也有连向Sentinel A的命令连接

Sentinel之间不会创建订阅连接：Sentinel在连接主服务器或者从服务器时，会同时创建命令连接和订阅连接，但是在连接其他Sentinel时，却只会创建命令连接，而不创建订阅连接。这是因为Sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新Sentinel，所以才需要建立订阅连接，而相互已知的Sentinel只要使用命令连接来进行通信就足够了

三个监视同一主服务器的Sentinel之间互相连接：

使用命令连接相连的各个Sentinel可以通过向其他Sentinel发送命令请求来进行信息交换

判断主节点真的故障

检测主观下线状态

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他Sentinel在内）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线：

Sentinel1将向Sentinel2、主服务器master、从服务器slave1和slave2发送PING命令

Sentinel2将向Sentinel1、主服务器master、从服务器slave1和slave2发送PING命令

实例对PING命令的回复可以分为以下两种情况：

有效回复：实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种

无效回复：实例返回除三种回复之外的其他回复，或者在指定时限内没有返回任何回复

配置中的：down-after-milliseconds指定了主观下线的判断时长

注意：不光是master的下线时长是 5s，从服务器和sentinel也都会被设置成5s

检测客观下线状态

客观下线只适用于主节点。之所以针对「主节点」设计「主观下线」和「客观下线」两个状态，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。

所以，为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成哨兵集群（最少需要三台机器来部署哨兵集群），通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线）。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作。

Sentinel使用下面的命令询问其他Sentinel是否同意主服务器已下线：

如果被Sentinel判断为主观下线的主服务器的IP为127.0.0.1，端口号为6379，并且Sentinel当前的配置纪元为0，那么Sentinel将向其他Sentinel发送以下命令：

当一个Sentinel（目标Sentinel）接收到另一个Sentinel（源Sentinel）发来的SENTINEL ismaster-down-by命令时，目标Sentinel会分析并取出命令请求中包含的各个参数，并根据其中的主服务器IP和端口号，检查主服务器是否已下线，然后向源Sentinel返回一条包含三个参数的MultiBulk回复作为SENTINEL is-master-down-by命令的回复：

如果一个Sentinel返回以下回复作为SENTINEL is-master-down-by-addr命令的回复，那么说明Sentinel也同意主服务器已下线：

根据其他Sentinel发回的SENTINEL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，表示主服务器已经进入客观下线状态：

选取领头Sentinel进行主从故障转移

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。

假设有三个哨兵。当哨兵 B 先判断到主节点「主观下线后」，就会给其他实例发送is-master-down-by-addr命令。接着，其他哨兵会根据自己和主节点的网络连接情况，做出赞成投票或者拒绝投票的响应。当哨兵 B 收到赞成票数达到哨兵配置文件中的quorum配置项设定的值后，就会将主节点标记为「客观下线」，此时的哨兵B就是一个Leader候选者。

候选者会向其他哨兵发送命令，表明希望成为Leader来执行主从切换，并让所有其他哨兵对它进行投票。

每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己。

那么在投票过程中，任何一个「候选者」，要满足两个条件：

拿到半数以上的赞成票

拿到的票数同时还需要大于等于哨兵配置文件中的quorum 值

❓

为什么哨兵节点至少要有 3 个？

如果哨兵集群中只有2个哨兵节点，此时如果一个哨兵想要成功成为Leader，必须获得2票，而不是1票。

如果哨兵集群中有个哨兵挂掉了，那么就只剩一个哨兵了，如果这个哨兵想要成为Leader，这时票数就没办法达到2票，就无法成功成为Leader，这时是无法进行主从节点切换的。

因此，通常至少会配置3个哨兵节点。这时，如果哨兵集群中有个哨兵挂掉了，那么还剩下两个个哨兵，如果这个哨兵想要成为Leader，这时还是有机会达到2票的，所以还是可以选举成功的，不会导致无法进行主从节点切换。

❓

如果 3 个哨兵节点，挂了 2 个怎么办？

这个时候得人为介入了，或者增加多一点哨兵节点

❓

Redis 1 主4从，5个哨兵，quorum设置为 3，如果2个哨兵故障，当主节点宕机时，哨兵能否判断主节点“客观下线”？主从能否自动切换？

哨兵集群可以判定主节点“客观下线”

哨兵集群还剩下 3 个哨兵，当一个哨兵判断主节点“主观下线”后，询问另外 2 个哨兵后，有可能能拿到 3 张赞同票，这时就达到了quorum的值，因此，哨兵集群可以判定主节点为“客观下线”。

哨兵集群可以完成主从切换

当有个哨兵标记主节点为「客观下线」后，就会进行选举Leader的过程，因为此时哨兵集群还剩下 3 个哨兵，那么还是可以拿到半数以上（5/2+1=3）的票，而且也达到了quorum值，满足了选举Leader的两个条件，所以就能选举成功，因此哨兵集群可以完成主从切换。

领头Sentinel选取规则：

所有在线的Sentinel都有被选为领头Sentinel的资格，监视同一个主服务器的多个在线Sentinel中的任意一个都有可能成为领头Sentinel

每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元（configuration epoch）的值都会自增一次，配置纪元实际上就是一个计数器

在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel

当一个Sentinel（源Sentinel）向另一个Sentinel（目标Sentinel）发送SENTINEL ismaster-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头Sentinel

Sentinel设置局部领头Sentinel的规则是先到先得：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentinel拒绝

目标Sentinel在接收到SENTINEL is-master-down-by-addr命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元

源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的 leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一致，那么表示目标 Sentinel将源Sentinel设置成了局部领头Sentinel

如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel，那么这个Sentinel成为领头Sentinel

因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel，所以在一个配置纪元里面，只会出现一个领头Sentinel

如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头Sentinel为止

主从故障转移

在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，包含3个步骤：

在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器

新的主服务器是怎样挑选出来的？领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤：

删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的。

删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的

删除所有与已下线主服务器连接断开超过down-after-milliseconds*10毫秒的从服务器，可以保证列表中剩余的从服务器都没有过早地与主服务器断开连接。换句话说，列表中剩余的从服务器保存的数据都是比较新的。

领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。如果优先级最高的服务器有个多个，将选择偏移量最大的服务器。如果偏移量最大的服务器有多个，则选择id最小的服务器。

一次故障转移操作中，领头Sentinel向被选中的从服务器server2发送SLAVEOF no one命令的情形：

在发送SLAVEOF no one命令之后，领头Sentinel会以每秒一次的频率（平时是每十秒一次），向被升级的从服务器发送INFO命令，并观察命令回复中的角色（role）信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了

例如，在上图中领头Sentinel会一直向server2发送INFO命令，当server2返回的命令回复从：

变为：

的时候，领头Sentinel就知道server2已经成功升级为主服务器了

让已下线主服务器属下的所有从服务器改为复制新的主服务器，这一动作可以通过向从服务器发送SLAVEOF命令来实现

领头Sentinel向已下线主服务器server1的两个从服务器server3和server4发送SLAVEOF命令，让它们复制新的主服务器server2：

将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器

因为旧的主服务器已经下线，所以这种设置是保存在server1对应的实例结构里面的，当 server1重新上线时，Sentinel就会向它发送SLAVEOF命令，让它成为server2的从服务器

哨兵集群如何组成

配置哨兵的信息时，只需要填下面这几个参数，设置主节点名字、主节点的 IP 地址和端口号以及 quorum 值。

不需要填其他哨兵节点的信息，它们是如何感知对方的，又是如何组成哨兵集群的？哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。

在主从集群中，主节点上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

在下图中，哨兵A把自己的IP地址和端口的信息发布到__sentinel__:hello 频道上，哨兵B和C订阅了该频道。那么此时，哨兵B和C就可以从这个频道直接获取哨兵A的IP地址和端口号。然后，哨兵B、C可以和哨兵A建立网络连接。

通过这个方式，哨兵 B 和 C 也可以建立网络连接，这样一来，哨兵集群就形成了。

哨兵集群会对「从节点」的运行状态进行监控，那哨兵集群如何知道「从节点」的信息？

主节点知道所有「从节点」的信息，所以哨兵会每10秒一次的频率向主节点发送INFO命令来获取所有「从节点」的信息。

如下图所示，哨兵B给主节点发送INFO命令，主节点接受到这个命令后，就会把从节点列表返回给哨兵。接着，哨兵就可以根据从节点列表中的连接信息，和每个从节点建立连接，并在这个连接上持续地对从节点进行监控。哨兵A和C可以通过相同的方法和从节点建立连接。

正式通过Redis的发布者/订阅者机制，哨兵之间可以相互感知，然后组成集群，同时，哨兵又通过INFO命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控了。