Redis Sentinel为Redis提供高可用性。实际上,这意味着使用Sentinel可以创建一个Redis部署,无需人工干预即可抵御某些类型的故障。这个也应该是Redis实际生产比较复杂的点
1.sentinel的功能
- 监控。Sentinel会不断检查主实例和从属实例是否按预期工作。
- 通知。Sentinel可以通过API通知系统管理员,另一台计算机程序,其中一个受监控的Redis实例出现问题。
- 自动故障转移。如果主服务器未按预期工作,Sentinel可以启动故障转移过程,其中从服务器升级为主服务器,其他其他服务器重新配置为使用新主服务器,并且使用Redis服务器的应用程序通知有关新服务器的地址。连接。
- 配置提供商。Sentinel充当客户端服务发现的权限来源:客户端连接到Sentinels以询问负责给定服务的当前Redis主服务器的地址。如果发生故障转移,Sentinels将报告新地址。
2.sentinel的快速使用
redis-server /path/to/sentinel.conf --sentinel
sentinel本质上只是一个运行在特殊模式之下的redis,sentinel通过info命令得到监听redis机器的master,slave等信息
在运行Sentinel时必须使用配置文件,因为系统将使用此文件以保存重新启动时将重新加载的当前状态。如果没有给出配置文件或者配置文件路径不可写,Sentinel将拒绝启动。
3.部署方式
您需要至少三个Sentinel实例才能实现强大的部署。
应将三个Sentinel实例放入被认为以独立方式失败的计算机或虚拟机中。例如,在不同的可用区域上执行的不同物理服务器或虚拟机。
Docker或其他形式的网络地址转换或端口映射应谨慎使用,针对此方式有特别说明
补充:sentinel集群是如何通信的,sentinel和监听服务器会建立2个连接一个是命令连接,一个是订阅连接,频道为"__sentinel__:hello" (2个_),自己可以在客户端监听验证
sentinel每2s会主动向这个频道写入自身和监听主机的信息,这样,其他的sentinel自然就知道了
4.最小配置文件
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
- sentinel monitor <master-group-name> <ip> <port> <quorum>
仲裁参数quarum就是需要有N个sentinel对于master的不可达,仅用于检测故障。在实际执行故障转移中,其中一个Sentinels需要被选为故障转移的领导者并被授权继续进行。 - down-after-milliseconds
是sentinel判断监控对象的主观下线的时间,如果在这个时间内ping,返回不了正确应答,就认为是主观下线 ,当sentinel之间命令连接,确认主观下线达到quorum数量,就判断为客观下线 - 实际生产,当主配置有密码时,由于使用了sentinel,则每个实例都有可能会变成主和从,所以每个实例都要配置requirepass和authmaster。且在sentinel中,也需要进行配置
sentinel auth-pass <master-group-name> <pass>
- failover-timeout
failover过期时间,当故障转移开始后,在此时间内仍然没有触发任何failover操作,当前sentinel将会认为此次failoer失败 - parallel-syncs
当新master产生时,同时进行slaveof到新master并进行同步复制的slave个数,也就是同时几个slave进行同步。因为在salve执行salveof与新master同步时,将会终止客户端请求,因此这个值需要权衡。此值较大,意味着“集群”终止客户端请求的时间总和和较大,此值较小,意味着“集群”在故障转移期间,多个salve向客户端提供服务时仍然使用旧数据
5.哨兵的故障恢复过程
哨兵本身不断在获取redis master和slave的信息,并通过订阅频道发现其他sentinel后,通过命令连接不断和其他sentinel进行通信
在实际发生故障时:
- 1 检查主观下线状态
- 2 检查客观下线状态
- 3选举sentinel的leader
请注意:sentinel通过 epoch进行选举,必须要获得至少一半的sentinel才能当选为最终的leader
即当不超过一半的sentinel连接时,你是无法获得sentinel的leader的,也就是无法进行故障转移
- 4故障转移
在这里,sentinel具体做了哪些
4.1从已下线的master的slaves中,选出一个作为新的master
4.2让其他的的slave改为复制新的的master
4.3将已下线的master改为新的master的slave,当这个旧的master重新上线时,改为新的master的slave
这里的具体过程,可以参考《redis设计与实现读书笔记 第二版》