概念
主从复制问题
1、高可用
主节点不可用，需要人工干预进行故障转移，即使自动化了还存在许多问题。
2、redis sentinel
自动完成故障发现和转移，并通知应用方，实现高可用。
存在多个哨兵和数据节点，每个哨兵节点对数据节点和其他哨兵节点进行监控，当节点不可达时，多个哨兵对其进行分析，如果是主节点，则哨兵节点间进行协商推举出一个哨兵来完成故障转移工作并通知应用方。（客户端连接的是哨兵节点集合，从而获取主节点信息）
配置和部署
主从节点部署，哨兵节点部署（类似于数据节点），哨兵节点之间能感知其他哨兵的存在
可监控多个主节点
哨兵部署技巧
1）生产中将哨兵节点部署在不同的物理机上
2）部署至少3个且奇数个
3）监控同一个业务的多个主节点集合，则监控多个主节点，否则只监控一个主节点
API
- 展示主节点状态和统计信息
- 展示某个主节点的从节点状态和统计信息
- 展示某个主节点的哨兵节点集合
- 展示主节点的ip和port
- 对匹配的主节点配置重置
- 强制故障转移
...
客户端连接哨兵
实现原理：1、遍历哨兵集合获取可用节点 2、获取主节点相关信息 3、验证主节点真实性，防止故障转移期间的变化
Java操作redis 哨兵 使用JedisSentinelPool全局只有一个，参数部分包括mastername，和sentinels集合
哨兵实现原理
- 三个定时监控任务
- 每隔10s哨兵向主从节点发送info命令获取拓扑结构（获取从节点，感知新的从节点，更新节点拓扑）
- 每隔2s哨兵向数据节点的__sentinel__:hello频道上发送该哨兵对主节点的判断和自身信息，每个哨兵会订阅该频道（发现新的哨兵，交换主节点的状态）
- 每隔1s哨兵向主从节点，其他哨兵节点发送ping命令进行心跳检测，确认可达性。
- 主观下线和客观下线
通过间隔1s的心跳检测来主观下线。
当主观下线的是主节点时候，向其他节点询问对主节点的判断，超过quorum时做出客观下线决定。 - 领导者哨兵节点选举
raft算法：大致是每个哨兵有一票，完成作出客观下线判断的节点请求推举自己为领导者，一旦获得（一半)以上的票，则结束选举 - 故障转移
- 选一个从节点为新的主节点（流程：过滤，优先级，复制偏移量大的，runid最小的）
- 领导哨兵使其执行slave of no one
- 向剩余从节点发送命令，让他们称为新主节点的从节点
- 哨兵节点集合将原来的主节点更新为从节点，并保持关注，恢复后区复制新的主节点。
运维和开发
- 故障转移日志分析（模拟方法：kill进程）
主节点：没有日志
从节点1：发现失联，收到哨兵节点命令变为主节点，其他从主节点发来了复制请求
其他从节点：发现和主节点失联，受到哨兵命令复制新主节点，之后发起复制操作
哨兵1：主观下线，投票领导人，从领导人获知新主节点和从节点，在30s后对原来的主节点进行主观下线
哨兵3：达到客观下线，被选为领导人，故障转移，发布切换信息
之后原来的主节点重启，受哨兵命令复制新主节点，复制后哨兵们分别撤销主观下线 - 节点运维
- 主节点下线：选取一个从节点晋升，通过哨兵即可，
- 从节点和哨兵下线：确保应用端感知到，此外哨兵会监视下线的节点
- 从节点上线：场景：读写分离时原来的从节点无法支持流量，主节点没有从节点来故障转移，用性能更高的机器换主节点；方法：slave of
- 加哨兵：场景：无法达到redis sentinel健壮性要求或者票数不够，原来的哨兵要下线；方法：配置哨兵参数启动，自动发现
- 加主节点：无法添加，需要切换，通过从节点来sentinel failover
- 节点配置
哨兵节点配置一致shang
一开始便规划好dir、loglevel等
以上内容提前做好预案
高可用读写分离设计方案
从节点用于主节点的故障转移和读能力扩展
- redis sentinel 对各个节点的监控，有事件发生都会发出事件消息，从节点变动事件包括：switch-master（从节点变为主节点）/convert-to-slave（原主节点降级为从节点）/sdown（主观下线）/reboot（重启添加了从节点）
- 将所有从节点看成一个资源池（所有客户访问slave资源池），无论上线还是下线客户端都能及时感知到（从资源池中添加和删除）。