原文：https://blog.csdn.net/chenyang_wei/article/details/127846656
在 Redis 主从复制模式中，因为系统不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。
Redis 官方推荐一种高可用方案，也就是 Redis Sentinel 哨兵模式，它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。
哨兵模式是一种特殊的模式，Redis 为其提供了专属的哨兵命令，它是一个独立的进程，能够独立运行。
哨兵主要有两个重要作用：
1、哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态；
2、当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。
在实际生产情况中，Redis Sentinel 是集群的高可用的保障，为避免 Sentinel 发生意外，它一般是由 3～5 个节点组成，这样就算挂了个别节点，该集群仍然可以正常运转。
本例环境配置：
master : 127.0.0.1 6380
slave1：127.0.0.1 6381
slave2：127.0.0.1 6382
sentinel1：127.0.0.1 16380
sentinel2：127.0.0.1 16381
sentinel3：127.0.0.1 16382
一、Redis集群配置
可参考：中间件：Redis-x64-5.0.14.1集群主从复制（Win10）
二、哨兵Sentinel配置
1、给master 6380中增加哨兵配置文件 sentinel.conf
哨兵全部配置主服务器信息，因为master有slave信息
#当前Sentinel服务运行端口
port 16380
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
2、同样给从服务 6381、6382下增加 sentinel.conf
#当前Sentinel服务运行端口
port 16381
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
#当前Sentinel服务运行端口
port 16382
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
3、启动集群
先启动master，再启动slave 6381、6382；启动可参考：中间件：Redis-x64-5.0.14.1集群主从复制（Win10）
4、启动哨兵
三个哨兵启用后，可以看见生成三个不同的 Sentinel ID
5、集群状态
三、测试
1、测试主机master 6380宕机
通过选票，6382成为master，6381中的master变成 6382。
2、停机的原master 6380重启
6380仍是从服务器，6382是master；6380不会再变回master。
3、slave 6381宕机
6382中可以看到只剩6380一个从机
重启6381 slave，6381回归关闭前状态
四、其他
1、从机配置命令：slave [master ip] [master port]
2、哨兵监听的主服务器：sentinel monitor [master名称(可以自定义)] [ip] [port] [通过票数]
master宕机后，从机投票通过设定的 通过票数 后认定master宕机，设定slave为master。
3、sentinel <选项的名字> <主服务器的名字> <选项的值>
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数;
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
4、Windows cmd启动redis：redis-server.exe redis.windows.conf；
5、Windows cmd启动哨兵：redis-server.exe sentinel.conf --sentinel;
6、Windows cmd redis cli：redis-cli.exe -h IP -p 端口;
7、Windows cmd redis cli查看redis状态信息：info replication；
————————————————
版权声明：本文为CSDN博主「我也不清楚」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/chenyang_wei/article/details/127846656