共计 5185 个字符，预计需要花费 13 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Redis 中的哨兵模式有什么用，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
基本介绍
哨兵（sentinel）是 Redis 的高可用性 (High Availability) 的解决方案：
由一个或多个 sentinel 实例组成 sentinel 集群可以监视一个或多个主服务器和多个从服务器。【相关推荐：Redis 视频教程】
当主服务器进入下线状态时，sentinel 可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证 redis 的高可用性。
图解
哨兵模式搭建步骤
1、复制一份 sentinel.conf 文件
cp sentinel.conf sentinel‐26379.conf
cp sentinel.conf sentinel‐26380.conf
cp sentinel.conf sentinel‐26381.conf2、相关配置修改
# 哨兵 sentinel 实例运行的端口默认 26379
port 26379
#将 `daemonize` 由 `no` 改为 `yes`
daemonize yes
#哨兵 sentinel 监控的 redis 主节点的 ip port
#master-name 可以自己命名的主节点名字只能由字母 A -z、数字 0 -9、这三个字符 .-_ 组成。#quorum 当这些 quorum 个数 sentinel 哨兵认为 master 主节点失联那么这时客观上认为主节点失联了
#sentinel monitor master-name ip redis-port quorum
sentinel monitor master 127.0.0.1 6379 2
#当在 Redis 实例中开启了 requirepass foobared 授权密码这样所有连接 Redis 实例的客户端都要提供密码
#设置哨兵 sentinel 连接主从的密码注意必须为主从设置一样的验证密码
#sentinel auth-pass master-name password
sentinel auth-pass master MySUPER--secret-0123passw0rd
#指定多少毫秒之后主节点没有应答哨兵 sentinel 此时哨兵主观上认为主节点下线默认 30 秒，改成 3 秒
#sentinel down-after-milliseconds master-name milliseconds
sentinel down-after-milliseconds master 3000
#这个配置项指定了在发生 failover 主备切换时最多可以有多少个 slave 同时对新的 master 进行同步，这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication 而不可用。可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。#sentinel parallel-syncs master-name numslaves
sentinel parallel-syncs master 1
#故障转移的超时时间 failover-timeout 可以用在以下这些方面：#1. 同一个 sentinel 对同一个 master 两次 failover 之间的间隔时间。#2. 当一个 slave 从一个错误的 master 那里同步数据开始计算时间。直到 slave 被纠正为向正确的 master 那里同步数据时。#3. 当想要取消一个正在进行的 failover 所需要的时间。#4. 当进行 failover 时，配置所有 slaves 指向新的 master 所需的最大时间。不过，即使过了这个超时，slaves 依然会被正确配置为指向 master，但是就不按 parallel-syncs 所配置的规则来了 #默认三分钟
#sentinel failover-timeout master-name milliseconds
sentinelf ailover-timeout master1 80000docker run -it --name redis-sentinel2639 -v /Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf -v /Users/yujiale/docker/redis/data26379:/data --network localNetwork --ip 172.172.0.16 -d redis:6.2.6 redis-sentinel /etc/redis/sentinel.conf3、启动 sentinel 哨兵实例
# 启动 redis-master 和 redis-slaver
在 redis-master 目录下 ./redis-server redis.conf
在 redis-slaver1 目录下 ./redis-server redis.conf
在 redis-slaver2 目录下 ./redis-server redis.conf# 启动 redis-sentinel
在 redis-sentinel1 目录下 ./redis-sentinel sentinel.conf
在 redis-sentinel2 目录下 ./redis-sentinel sentinel.conf
在 redis-sentinel3 目录下 ./redis-sentinel sentinel.conf4、查看启动状态
执行流程
1、启动并初始化 Sentinel
Sentinel 是一个特殊的 Redis 服务器不会进行持久化
Sentinel 实例启动后每个 Sentinel 会创建 2 个连向主服务器的网络连接
命令连接：用于向主服务器发送命令，并接收响应
订阅连接：用于订阅主服务器的—sentinel—:hello 频道
2、获取主 Master 信息
Sentinel 默认每 10s 一次，向被监控的主服务器发送 info 命令，获取主服务器和其下属从服务器的信息。
3、获取从 salve 信息
当 Sentinel 发现主服务器有新的从服务器出现时，Sentinel 还会向从服务器建立命令连接和订阅连接。
在命令连接建立之后，Sentinel 还是默认 10s 一次，向从服务器发送 info 命令，并记录从服务器的信息。
4、以订阅的方式向主服务器和从服务器发送消息
默认情况下，Sentinel 每 2s 一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello 频道上发送消息，消息中会携带 Sentinel 自身的信息和主服务器的信息。
5、接收来自主服务器和从服务器的频道信息
当 Sentinel 与主服务器或者从服务器建立起订阅连接之后，Sentinel 就会通过订阅连接，向服务器发送以下命令
subscribe—sentinel—:helloSentinel 彼此之间只创建命令连接，而不创建订阅连接，因为 Sentinel 通过订阅主服务器或从服务器，就可以感知到新的 Sentinel 的加入，而一旦新 Sentinel 加入后，相互感知的 Sentinel 通过命令连接来通信就可以了。
6、检测主观下线状态
Sentinel 每秒一次向所有与它建立了命令连接的实例 (主服务器、从服务器和其他 Sentinel) 发送 PING 命令实例在 down-after-milliseconds 毫秒内返回无效回复 (除了 +PONG、-LOADING、-MASTERDOWN 外) 实例在 down-after-milliseconds 毫秒内无回复（超时）Sentinel 就会认为该实例主观下线(SDown)
7、检查客观下线状态
当一个 Sentinel 将一个主服务器判断为主观下线后
Sentinel 会向同时监控这个主服务器的所有其他 Sentinel 发送查询命令
主机的
SENTINEL is-master-down-by-addr ip port current_epoch runid其他 Sentinel 回复
down_state leader_runid leader_epoch判断它们是否也认为主服务器下线。如果达到 Sentinel 配置中的 quorum 数量的 Sentinel 实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。
8、选举 Leader Sentinel
当一个主服务器被判定为客观下线后，监视这个主服务器的所有 Sentinel 会通过选举算法（raft），选出一个 Leader Sentinel 去执行 failover（故障转移）操作。
哨兵选举
Raft
Raft 协议是用来解决分布式系统一致性问题的协议。
Raft 协议描述的节点共有三种状态：Leader, Follower, Candidate。
term：Raft 协议将时间切分为一个个的 Term（任期），可以认为是一种“逻辑时间”。
选举流程
Raft 采用心跳机制触发 Leader 选举
系统启动后，全部节点初始化为 Follower，term 为 0。
节点如果收到了 RequestVote 或者 AppendEntries，就会保持自己的 Follower 身份
节点如果一段时间内没收到 AppendEntries 消息，在该节点的超时时间内还没发现 Leader，Follower 就会转换成 Candidate，自己开始竞选 Leader。
增加自己的 term。
启动一个新的定时器。
给自己投一票。
向所有其他节点发送 RequestVote，并等待其他节点的回复。
一旦转化为 Candidate，该节点立即开始下面几件事情：
如果在计时器超时前，节点收到多数节点的同意投票，就转换成 Leader。同时向所有其他节点发送 AppendEntries，告知自己成为了 Leader。
每个节点在一个 term 内只能投一票，采取先到先得的策略，Candidate 前面说到已经投给了自己，Follower 会投给第一个收到 RequestVote 的节点。
Raft 协议的定时器采取随机超时时间，这是选举 Leader 的关键。
在同一个 term 内，先转为 Candidate 的节点会先发起投票，从而获得多数票。
Sentinel 的 leader 选举流程
1、某 Sentinel 认定 master 客观下线后，该 Sentinel 会先看看自己有没有投过票，如果自己已经投过票给其他 Sentinel 了，在一定时间内自己就不会成为 Leader。
2、如果该 Sentinel 还没投过票，那么它就成为 Candidate。
3、Sentinel 需要完成几件事情：
更新故障转移状态为 start
当前 epoch 加 1，相当于进入一个新 term，在 Sentinel 中 epoch 就是 Raft 协议中的 term。
向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的 epoch。
给自己投一票（leader、leader_epoch）
4、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断 epoch）
5、Candidate 会不断的统计自己的票数，直到他发现认同他成为 Leader 的票数超过一半而且超过它配置的 quorum，这时它就成为了 Leader。
6、其他 Sentinel 等待 Leader 从 slave 选出 master 后，检测到新的 master 正常工作后，就会去掉客观下线的标识。
故障转移
当选举出 Leader Sentinel 后，Leader Sentinel 会对下线的主服务器执行故障转移操作
1. 它会将失效 Master 的其中一个 Slave 升级为新的 Master, 并让失效 Master 的其他 Slave 改为复制新的 Master；
2. 当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master。
3.Master 和 Slave 服务器切换后，Master 的 redis.conf、Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即，Master 主服务器的 redis.conf 配置文件中会多一行 replicaof 的配置，sentinel.conf 的监控目标会随之调换。
主服务器的选择
1. 过滤掉主观下线的节点
2. 选择 slave-priority 最高的节点，如果由则返回没有就继续选择
3. 选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续
4. 选择 run_id 最小的节点，因为 run_id 越小说明重启次数越少
关于“Redis 中的哨兵模式有什么用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
