版权声明：本文为博主原创文章，未经博主允许不得转载。 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