高并发高可用复杂系统中的缓存架构(十一) redis哨兵集群搭建

动手实操，练习如何操作部署哨兵集群，如何基于哨兵进行故障转移，还有一些企业级的配置方案

在这之前我一直以为 redis sentinel 是另外的一个项目，其实不是，还是 同一个 redis ，不过是通过 redis-sentinel + sentinel 配置文件 启动的另一个程序

采用一主（MASTER）二从（SLAVE）三哨兵(SENTINEL)的架构

前面已经在windows上搭建过一主两从高可用redis 6380主，6381，6382从

现在在每个redis文件夹下新建一个sentinel.conf文件

配置如下

#当前Sentinel服务运行的端口
port 26380

bind 127.0.0.1
#master
#Sentinel去监视一个名为mymaster的主redis实例，这个主实例的IP地址为本机地址127.0.0.1，端口号为6380，
#而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
sentinel monitor mymaster 127.0.0.1 6380 1
#指定了Sentinel认为Redis实例已经失效所需的毫秒数。当 实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。
#只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
sentinel down-after-milliseconds mymaster 5000
#指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel config-epoch mymaster 12
#如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel leader-epoch mymaster 13

6381配置文件为sentinel.conf

#当前Sentine2服务运行的端口
port 26381

bind 127.0.0.1
#slave1
sentinel monitor mymaster 127.0.0.1 6380 1
sentinel down-after-milliseconds mymaster 5000
sentinel config-epoch mymaster 12
sentinel leader-epoch mymaster 13

6382 sentinel.conf 

#当前Sentine2服务运行的端口
port 26382

bind 127.0.0.1
#slave1
sentinel monitor mymaster 127.0.0.1 6380 1
sentinel down-after-milliseconds mymaster 5000
sentinel config-epoch mymaster 12
sentinel leader-epoch mymaster 13

 

启动哨兵命令：redis-server.exe sentinel.conf --sentinel ，后面的“--sentinel”也要打上

# 这个是Redis6379配置内容，其他文件同理新增然后改一下端口即可，26380 26381
#当前Sentinel服务运行的端口
port 26381
bind 127.0.0.1
# 哨兵监听的主服务器 
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应，则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来，则启动failover  
sentinel failover-timeout mymaster 10000  
# 执行故障转移时， 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1