Redis哨兵模式及其运行原理解析

搭建一主二从三哨兵

作用：读写分离 容灾恢复
启动多台redis容器，修改配置文件中的端口号以及日志文件名称
其实对于容器，可以不修改端口，只需启动容器时映射不同的端口即可

1 修改master和slave的配置文件

master

# 注释这一行，表示Redis可以接受任意ip的连接
# bind 127.0.0.1 

# 关闭保护模式
protected-mode no 

# 让redis服务后台运行
daemonize no 

# 设定密码(可选，如果这里开启了密码要求，slave的配置里就要加这个密码. 只是练习配置，就不使用密码认证了)
# requirepass masterpassword 

# 配置日志路径，为了便于排查问题，指定redis的日志文件目录
logfile "/var/log/redis/redis.log"

slave

注意：slave对应的master地址是master容器所在宿主机的地址
# 注释这一行，表示Redis可以接受任意ip的连接
# bind 127.0.0.1 

# 关闭保护模式
protected-mode no 

# 让redis服务后台运行
daemonize no

# 设定密码(可选，如果这里开启了密码要求，slave的配置里就要加这个密码)
requirepass masterpassword 

# 设定主库的密码，用于认证，如果主库开启了requirepass选项这里就必须填相应的密码
# masterauth <master-password>
masterauth 123
# requirepass foobared
requirepass 123

# 设定master的IP和端口号，redis配置文件中的默认端口号是6379
# 低版本的redis这里会是slaveof，意思是一样的，因为slave是比较敏感的词汇，所以在redis后面的版本中不在使用slave的概念，取而代之的是replica
# 将35.236.172.131做为主，其余两台机器做从。ip和端口号按照机器和配置做相应修改。
replicaof 47.112.136.29 6379

# 配置日志路径，为了便于排查问题，指定redis的日志文件目录
logfile "/var/log/redis/redis.log"

2 启动master和多台slave

docker run -d --name redis_master -v ~/redis/master/data:/data  -v ~/redis/master/redis.conf:/usr/local/etc/redis.conf  \
 -p 6379:6379 redis redis-server /usr/local/etc/redis.conf
 
 
docker run -d --name redis_slave1 -v ~/redis/slave1/data:/data  -v ~/redis/slave1/redis.conf:/usr/local/etc/redis.conf  \
 -p 6380:6380 redis redis-server /usr/local/etc/redis.conf
 
 
docker run -d --name redis_slave2  -v ~/redis/slave2/data:/data  -v ~/redis/slave2/redis.conf:/usr/local/etc/redis.conf  \
 -p 6381:6381 redis redis-server /usr/local/etc/redis.conf

3 配置哨兵

#当前Sentinel服务运行的端口
port 26379
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 3000
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel failover-timeout mymaster 10000
#如果10秒后,mysater仍没启动过来，则启动failover
sentinel auth-pass mymaster 123
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel config-epoch mymaster 0

4 启动多个哨兵

docker run -it --name sentinel -p 26379:26379  -v ~/redis/sentinel1/data:/data  \
-v ~/redis/sentinel1/sentinel.conf:/usr/local/etc/sentinel.conf -d redis redis-sentinel /usr/local/etc/sentinel.conf

docker run -it --name sentinel -p 26380:26380-v ~/redis/sentinel2/data:/data  \
-v ~/redis/sentinel2/sentinel.conf:/usr/local/etc/sentinel.conf -d redis redis-sentinel /usr/local/etc/sentinel.conf

docker run -it --name sentinel -p 26381:26381-v ~/redis/sentinel3/data:/data  \
-v ~/redis/sentinel3/sentinel.conf:/usr/local/etc/sentinel.conf -d redis redis-sentinel /usr/local/etc/sentinel.conf

运行过程

1 启动哨兵后，哨兵每10s会给master发送info指令，来获取从机的信息，
然后并向master订阅一个频道_sentinel_:hello
2 当有其它哨兵加入时，它会每隔2s向这个频道发送一个消息，包含了该哨兵的ip和端口以及对master的判断结果
其它订阅了该频道的哨兵就会知道有一个新哨兵加入了，同时还可以知道它是否认为master主观下线
3 sentinel会每秒向master、slave、sentinel 发送ping命令，如果超过down-after-milliseconds(最大失联时间)内没有回复，
就认为对方下线了，即主观下线，为了避免误判，会询问其它哨兵对master的判断

命令为  sentinel is-master-down-by-addr 127.0.0.1 6379 0 * （*表示直接交换对master下线的判断）

返回结果为三个参数
·

down_state：目标Sentinel节点对于主节点的下线判断，1是下线，0是在线。
·leader_runid：当leader_runid等于“*”时，代表返回结果是用来做主节点是否不可达，当leader_runid等于具体的runid，代表目标节点同意runid成为领导者。
·leader_epoch：领导者纪元。

当超过quorum个数的哨兵认为master主观下线了，才会切换master，即客观下线
切换后，master slave sentinel的配置文件内容会发生变化
如果是slave或sentinel主观下线，就没有后续操作
4 在执行master切换时，需要向从多个sentinel中选举一个领导者，来执行故障转移操作
5 正常运行时，哨兵会每10秒向集群中的master、slave发送info命令，当master下线后，会每秒给slave发送info命令

哨兵的3个定时器

1 每秒向master、slave以及其它哨兵发送ping命令，判断这些节点是否可达
以及判断master是否主观下线
1 每2s向master的_sentinel_:hello频道发送哨兵的节点信息以及它对master的判断结果
用于发现新的哨兵信息，以及为客观下线以及领导者选举作依据
2 每10s向所有redis节点发送info指令，用于获取redis集群的最新结构信息

sentinel领导者选举：

使用了Rafg算法思想
1 每个对master作出主观下线的哨兵会像其它哨兵发出sentinel is-master-down-by-addr命令，让它们给自己投票
2 其它哨兵在第一次收到该命令时，会给这个对方投票，如果时之后的收到的就不会做出反馈
3 如果某个哨兵的票数超过一半且超过了quorum，它就会成为领导者
4 如果该过程中没有产生领导者，就继续下一轮，知道产生领导者为止

选择新master：

哨兵中选举出的领导者负责从slave中选一个作为新master
1 过滤不健康的slave，即5s内没有响应哨兵的ping命令，或者与之前的master累计失联时间超过10*down-after-milliseconds(最大失联时间)秒
2 选择slave-proprity(从节点优先级)最高的从节点列表
3 选择复制偏移量最大的从节点，即从master复制的数据越多
4 选择runid最小的从节点
5 如果以上条件还不能选出一个，就看哪个从节点给之前master发送的命令最多

故障转移：

1 哨兵领导者节点使用slaveof no none，让选出来的从节点成为新master
2 领导者节点给剩余的从节点发送命令slaveof ip port，让它们成为新master的从节点
3 所有的哨兵节点会把原来的master更新为从节点，然后监视新master
待原master恢复后，就去全量复制新master的数据

从节点的作用：

1 故障恢复，成为新的master
2 扩展master的读能力

身份认证：

requirepass： 连接到该redis的密码
masterauth: 对应master的密码
因为slave可能会变成master，所以上述两个密码slave都要配置

哨兵模式的缺点:

写都是在master上的，而最新的数据复制到从机上，存在延迟