版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Francis123580/article/details/82526820
Redis Sentinel 高可用
背景:主从复制问题
- 主节点出现问题后,需要手动将一个从节点晋升为主节点,修改应用方的主节点地址,命令其它从节点去复制新的主节点
- 主节点的写能力受到单机的限制
- 主节点的存储能力受到单机的限制
解决:Redis Sentinel 实现
- Redis Sentinel 是一个分布式架构,包含若干个 Sentinel 节点和 Redis 数据节点
- 每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控
- 当 Sentinel 发现节点不可用达时,会对节点做下线标识
- 如果被标识的是主节点,它还会和其他 Sentinel 节点进行协商
- 当大多数 Sentinel 节点都认为主节点不可达时,它们会选举出一个 Sentinel 进行故障转移,并把结果通知给 Redis 应用方
Redis Sentinel 功能
- 监控:Sentinel 节点定期检测 Redis 数据节点、其余 Sentinel 节点是否可达
- 通知:Sentinel 节点将故障转移的结果通知给应用方
- 主节点故障转移:实现从节点晋升为主节点并维护后续正确的正从关系
- 配置提供者:客户端在初始化时连接的是 Sentinel 节点集合,从中获取主节点信息
Redis Sentinel 部署
- 部署启动多个 Redis 节点
- 配置 Redis 节点主从关系
- 部署多个 Sentinel 节点,配置见下文 [ redis-sentinel.conf ]
- 启动 Sentinel 节点,
redis-sentinel redis-sentinel-26379.conf
- 查看启动情况,
redis-cli -h 127.0.0.1 -p 26379 info Sentinel
[ redis-sentinel.conf ]
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
# 监控 127.0.0.1 6379 节点,失败需要2个 Sentinel 同意
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
配置部署优化
配置优化
- < quorum > 配置的越小,达到下线的条件就越宽松
- down-after-milliseconds 配置的越大,代表 Sentinel 节点对于节点不可达的条件就越宽松,意味着应用方故障时间可能越长
- parallel-syncs 代表故障转移后,从节点向新主节点同时发起复制操作的个数,如果为1,则是轮询
- failover-timeout 作用域故障转移各个阶段,选主时间、检查节点信息、复制新主数据时间超过,则故障转移失败
- notification-script 作用在故障转移期间,若发生警告级别 Sentinel 事件,触发对应脚本
- client-reconfig-script 作用在故障转移之后,触发对应路径脚本
部署优化
- Sentinel 节点不部署在一台物理机器上
- 部署至少3个且奇数个 Sentinel 节点
- Sentinel 节点集合监控同一个业务的多个主节点集合则用一套 Sentinel 监控多个主节点,如果不是,则每个主节点用一套 Sentinel