一、基本概念
1.主从复制的问题:
一旦主节点出现故障需要手动的将一个从节点晋升为主节点同时需要修改应用方的主节点地址还需要通过命令其他节点去复制新的主节点。
主节点的写能力和存储能力受到单机的限制
2.高可用:
上图为一主二从的redis主从复制模式下的主节点出现故障
故障转移过程:
Ⅰ、主节点故障,客户端连接主节点失败造成复制中断
Ⅱ、重新选出一个新的主节点,然后执行slaveof no one使其成为新的主节点
Ⅲ、从节点成为新的主节点后更新应用方的主节点信息并重启
Ⅳ、客户端命令另一个从节点复制新的主节点
Ⅴ、原来的主节点恢复后去复制新的主节点
上述这几个过程不符合高可用的思想,因为这个过程需要人介入
Redis Sentinel的高可用性:当主节点出现故障时,它可以自动完成故障发现和故障转移并可以通知应用方实现真正的高可用
Redis Sentinel是一个分布式架构,其包含若干个Sentinel节点和Redis数据节点,其中每个Sentinel节点会对数据节点和其余的Sentinel节点进行监控,当发现节点不可达时会对节点做下线标识,如果标识的时主节点,它会和其他Sentinel节点进行协商,当大多数Sentinel节点认为主节点不可达时,它们会选举一个Sentinel节点来自动完成故障转移工作同时也会将这个实时的变化通知给redis的应用方,整个过程不需要人工介入
Redis Sentinel故障转移逻辑:
Ⅰ、主节点出现故障,从节点和主节点失去连接主从复制失败
Ⅱ、每个Sentinel节点通过定期监控发现主节点出现故障
Ⅲ、多个Sentinel节点对主节点的故障达成一致并选举出其中一个Sentinel节点作为领导者负责故障转移
Ⅳ、故障转移后整个redis sentinel拓扑图
根据上述架构图可以得知Redis Sentinel具有以下功能:
监控:Sentinel节点会定期检测redis数据节点、其余Sentinel节点是否可达
通知:Sentinel节点会将故障转移的结果通知给应用方
主节点故障转移:实现从节点晋升主节点并维护后续正确的主从关系
配置提供者:在上述结构中,客户端在初始化的时候时Sentinel集合,从中获取主节点的信息
Sentinel节点集合是由若干个Sentinel节点组成,这样即使个别Sentinel节点不可用,整个Sentinel节点集合都是健壮的,它们是独立的redis节点但不存储数据只支持部分命令。
3.Redis Sentinel的安装和部署
Ⅰ、部署redis数据节点
Ⅱ、启动主节点 redis-server redis-6379.conf
通过 redis-cli -h 127.0.0.1 -p 6379 ping 来确认redis的数据节点已经启动
启动两个从节点
redis-server redis-6380.conf redis-6381.conf
Ⅲ、确认主从关系(从节点视角):
Ⅳ、 部署Sentinel节点
Sentinel的默认端口是26379,sentinel monitor mymaster127.0.0.163792,其中2表示至少需要两个Sentinel节点同意才可以决定主节点下线
启动Sentinel节点:redis-sentinel redis-sentinel-26379.conf 或者 redis-server redis-sentinel-26379.conf --sentinel
Ⅴ、最终的拓扑结构图:
4.相关配置参数解释:
每个Sentinel节点都要通过定期发送ping命令来判断redis数据节点和其他的Sentinel节点是否可达,如果超过down-after-milliseconds配置的时间没有有效的回复则判断节点不可达,该值越大表示条件越宽松反之越严格。
parallel-syncs是用来限制在一次故障转移后每次向新的主节点发起复制操作的从节点数,如果该参数配置比较大就会有多个从节点向新的主节点发起复制操作,虽然该操作不会引起阻塞,但是也会对主节点所在的机器造成一定的网络等资源的额外开销。
failover-timeout故障转移超时时间,作用于故障转移的各个阶段:
Ⅰ、选出合适的从节点
Ⅱ、晋升选出的从节点为主节点
Ⅲ、命令其余的从节点复制新的主节点
Ⅳ、等待原主节点回复后命令它去复制新的主节点
如果redis sentinel对一个主节点故障转移失败,下次对该主节点做故障转移的起始时间是failover-timeout的2倍
如果对选出的从节点执行slaveof no one失败时,则故障转移失败
如果将选出的从节点晋升成主节点后再执行info命令确认选出的节点确实晋升成为主节点,如果这个过程超过failover-timeout则表示故障转移失败