Redis Sentinel 哨兵架构是高可用方案。
1. 基本概念
1.1 主从复制问题
主从复制模式的作用：
- 从节点作为后备，保证数据尽量不丢失
- 从节点扩展主节点的读能力
问题：
- 一旦主节点故障，需要手动将一个从节点晋升
- 主节点写能力受到单机限制
- 主节点存储能力受到单机限制
1.2 高可用
故障转移过程
- 主节点故障，复制中断
- 选出一个从节点，
slaveof no one使其成为新的主节点 - 更新应用方的主节点信息，重新启动应用方
- 命令另一个从节点复制新的主节点
- 待原来的主节点恢复后，去复制新的主节点
1.3 Redis Sentinel的高可用性
Redis Sentinel能自动完成故障发现和故障转移，包含若干个Sentinel节点和Redis数据节点。每个Sentinel节点会对数据节点和其余Sentinel节点进行监控。
故障转移步骤：
- 主节点故障，主从复制失败
- 每个Sentinel节点通过定期监控发现主节点出现了故障
- 多个Sentinel节点对主节点的故障达成一致，选出某个sentinel节点作为领导者负责故障转移
- Sentinel领导者节点执行了故障转移
2. 安装和部署
3. API
4. 客户端连接
5. 实现原理
5.1 三个定时监控任务
一套合理的监控机制是Sentinel节点判定节点不可达的重要保证
- 每个10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新拓扑
- 每个2秒，每个Sentinel节点会向Redis数据节点的sentinel:hello频道发送对主节点的判断以及当前Sentinel节点信息
- 每个1秒，每个Sentinel节点会向主节点，从节点，其余Sentinel节点发送一条ping命令做一次心跳检测
5.2 主观下线和客观下线
- ping命令后节点没有回复，sentinel节点对该节点做失败判定
- 客观下线，当Sentinel主观下线的节点是主节点时，向其他Sentinel节点询问，超过<quorum>个数即为客观下线
5.3 领导者Sentinel节点选举
实际的故障转移工作只由一个Sentinel节点完成，所以要选一个领导者。通过Raft算法实现选举
选出最好的从节点.jpg
6 开发与运维中的问题
6.1 故障转移日志分析
6.2 节点运维
6.3 高可用读写分离
要点：实时掌握所有从节点状态，把所有从节点看做一个资源池
Redis Sentinel下的读写分离架构图.jpg
