需要配合源码一起康~
官网手册yyds:https://redis.io/docs/manual/sentinel/
redis主从模式,如果主挂了,需要人工将从节点提升为主节点,通知应用修改主节点的地址。不是很友好,so Redis 2.8之后开始提供哨兵架构来解决该问题,有一些哨兵节点监控redis节点,如果发生一些异常,可以做一些干预。
Redis sentinel是Redis主从版本的高可用实现方式
redis主从版本会将主节点的数据同步给从节点。从节点的作用:
在这个过程中,需要运维人员来做操作,时效性和准确性都比较难保证。sentinel应运而生,能够自动完成故障发现和故障转移
redis sentinel是一个分布式架构,包含若干sentinel节点和redis数据节点。sentinel的大致步骤:
第一步:启动主节点
第二步:启动从节点
第三步:确定主从关系
第一步:确定sentinel节点配置(下方有参数详解)
# 监控主节点的地址和端口,判断主节点失败需要至少2个sentinel
# sentinel monitor
sentinel monitor mymaster 127.0.0.1 6379 2
# 监控主节点的配置项
# sentinel
# 60s master不可达就认为它坏掉了
sentinel down-after-milliseconds mymaster 60000
# 故障转移超时时间
sentinel failover-timeout mymaster 180000
# 同时配置使用新master的replicas数目
sentinel parallel-syncs mymaster 1
第二步:启动sentinel节点
redis-sentinel /path/to/sentinel.conf
# 或者
redis-server /path/to/sentinel.conf --sentinel
第三步:确认sentinel节点
$ redis-cli -p 5000
127.0.0.1:5000> sentinel master mymaster
1) "name"
2) "mymaster"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6379"
7) "runid"
8) "953ae6a589449c13ddefaee3538d356d287f509b"
# 或者
$ redis-cli -p 5000
127.0.0.1:5000> info Sentinel
第四步:测试sentinel
# 可以让主节点30s不可达
redis-cli -p 6379 DEBUG sleep 30
# 监控主节点的地址和端口,判断主节点失败需要至少2个sentinel
# sentinel 节点会从主节点获取从节点和其他sentinel的信息
# 完成故障转移,还需要有半数以上投票选出执行故障转移的领导,所以投票者为max(quorum, num(sentinel)/2+1)
sentinel monitor <master-group-name> <ip> <port> <quorum>
# 60s master不可达就认为它坏掉了
# 这个参数对判断sentinel节点、主节点、从节点同时有效
sentinel down-after-milliseconds mymaster 60000
# 同时配置使用新master同步的replicas数目
# 因为从节点同时向主节点发起复制,会对主节点的机器造成一定的网络和磁盘开销。如果这个值为1,有3个replicas,则会轮询展开复制
sentinel parallel-syncs mymaster 1
# sentinel对一个节点故障转移失败,下一次再对该节点的故障转移时间将是failver-timeout时间的2倍
# 对要提升为主的从节点执行slaveof no one一直失败,如果这个时间超过failver-timeout,则故障转移失败
# 如果slaveof no one执行成功,但在新主上执行info确认身份命令超过failver-timeout未响应,则故障转移失败
# 如果在其他从节点上执行slaveof host port让其更新主节点,命令超过failver-timeout未响应,则故障转移失败(sentinel最终还是会配置从节点去同步最新主节点)
sentinel failover-timeout mymaster 180000
# acl需要配置账户、密码;如果不支持acl直接配置密码
sentinel auth-user <master-group-name> <username>
sentinel auth-pass <master-group-name> <password>
127.0.0.1:6379> ACL SETUSER sentinel-user ON >somepassword allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill
# 当一些警告级别的事件发生(节点的主观下线、客观下限等),会触发对应路径的脚本,并向脚本发送一些信息
# 参数这样: +sdown/odown sdown客观下线 odown主观下线
# 当配置之后,脚本会收到每个sentinel节点传过来的事件参数(如主观下线:+sdown master mymaster host port)
sentinel notification-script <master-name> <script-path>
# sentinel完成故障转移之后,会把故障转移的结果发给对应的脚本
# 参数这样:
# role: sentinel的角色,leader/observer
# from:原主节点 to:新主节点
sentinel client-reconfig-script <master-name> <script-path>
# notification-script
#!/bin/sh
python notify_redis.py $*
# notify_redis.py
import sys
def main(args):
for arg in args:
if arg == "+odown":
print "HEY SOMETHING IS UP WITH REDIS"
email_text_or_whatever_thing_you_wanna_do()
main(sys.argv)
指定多个masterName来区分不同的主节点
# 只对当前的sentinel节点有效,如果执行成功会立即刷新配置文件
sentinel set xx
sentinel节点的高可用:至少三个且奇数个数的sentinel
一套sentinel监控一个主节点:隔离性好,但会造成资源浪费;
一套sentinel监控多个主节点:同一业务的多个主节点可接受