redis 哨兵模式集群搭建
redis 哨兵模式集群搭建
Sentinel(哨兵)，顾名思义就是站岗放哨的，是redis提供的高可用解决方案，它是对主从模式的优化升级，在主从模式下，如果主库发生宕机，需要人工介入将某个从节点提升为主库，同时需要修改应用配置的主节点地址，而在Sentinel模式下，每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未得到回应，会对节点做下线标识，如果被标识的是主节点，它还会与其他Sentinel节点进行协商，当多数派都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会通知应用方主节点已经发生转移。下面我们就来搭建一个Sentinel集群。
安装部署
环境准备
在这里我们使用的是Redis 4.0.10，在一台服务器上启动三个server来模拟一主两从的架构，redis的安装过程这里就不在演示了，可以参考文章【redis】部署及参数详解（吐血整理,建议收藏）。
部署过程
1. 启动主节点
修改配置文件
/usr/local/redis/etc/redis_6377.conf，主要注意以下几个参数
port 6377
daemonize yes
logfile "/redis_data/log/redis_6377.log"
dir "/redis_data/data/6377"
dbfilename "dump_6377.rdb"执行启动命令
redis-server /usr/local/redis/etc/redis_6377.conf通过redis客户端连接测试
redis-cli -h 127.0.0.1 -p 6377
127.0.0.1:6377> ping
PONG2. 启动从节点
从节点配置文件和主节点配置文件的主要区别是将6377改成从节点对应的端口号，本次实验两个从节点的端口号分别为6378和6379。同时配置需要同步的主节点的IP和端口。
slaveof 127.0.0.1 6377 启动从节点
redis-server /usr/local/redis/etc/redis_6378.conf
redis-server /usr/local/redis/etc/redis_6379.conf确认主从是否生效
[redis@localhost etc]$ redis-cli -h 127.0.0.1 -p 6377 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6378,state=online,offset=308,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=308,lag=13. 启动Sentinel节点
Sentinel节点至少3个且奇数，这样才能在协议中形成多数派。配置Sentinel节点配置文件/usr/local/redis/sentinel-26377.conf，主要注意以下参数
port 26377
dir "/redis_data/data/26377"
logfile "/redis_data/log/redis-26377.log"
#配置主节点的IP和端口，2代表主节点判断失败至少需要2个Sentinel节点同意，一般设置为Sentinel节点数的一半加1.
sentinel monitor mymaster 127.0.0.1 6377 2
#30秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移时从节点同时向新主发起复制请求的数量，1代表从节点会轮询发起复制。
sentinel parallel-syncs mymaster 1
#故障转移开始，180秒内没有完成，则认为转移失败
sentinel failover-timeout mymaster 180000启动Sentinel节点
redis-sentinel sentinel-26377.conf
redis-sentinel sentinel-26378.conf
redis-sentinel sentinel-26379.conf4. 通过Sentinel节点查看哨兵是否生效
[redis@localhost redis]$ redis-cli -h 127.0.0.1 -p 26377 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6377,slaves=2,sentinels=3至此，Sentinel模式的redis集群搭建就完成了。
故障转移
模拟主库宕机，通过kill命令杀死主库，查看故障转移情况：
127.0.0.1:26377> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6378,slaves=2,sentinels=3可以看到master改为127.0.0.1:6378了。
故障转移的大体步骤如下：
- 每个Sentinel节点每隔1秒对主、从、其他Sentinel阶段发送ping探测，超过down-after-milliseconds未返回响应，则判断该节点主观下线。
- Sentinel节点向其他Sentinel节点询问对于异常节点的判断，当达到 quorum个sentinel节点都认为被主观下线的节点异常时，则对该节点做客观下线。
- 在sentinel节点中通过Raft算法选举出一个leader来完成故障转移。
- 当出现故障的节点是主节点时，sentinel leader会根据优先级、复制偏移量、runid等在从节点中选出一个作为主节点，执行slaveof no one命令。
- leader向其他从节点发送指令，让他们成为新主的从节点，并将原来的主节点更新为从节点，当旧主恢复后去复制新主的数据。
- 复制完成后，发布主节点的切换消息。