一、简介

声明：该文章内容参考自 51CTO技术栈公众号的部分内容，纯属学习记录使用。

二、redis高可用相关

2.1 持久化

持久化主要作用是数据备份，即将数据存储在硬盘，保证数据不会因为进程退出而丢失。

2.2 复制

redis高可用的基础，哨兵和集群都是在该基础上实现高可用的。复制主要实现了数据的多机备份，以及对读操作的负载均衡和简单的故障恢复。
缺陷：故障时无法自动恢复，需手动进行切换；写操作无法负载均衡；存储能力受到单机的限制；

2.3 哨兵

哨兵在复制的基础上实现了故障的自动化回复；
缺陷：写操作无法负载均衡；存储能力受到单机的限制；

2.4 集群

使用集群，解解决了redis的写操作无法负载均衡的问题，以及存储能力收到单机限制的问题。

三、哨兵

3.1 哨兵原理

3.1.1 哨兵架构图

由俩部分组成：哨兵节点集合和数据节点集合。
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据，负责对数据节点和七月的哨兵节点进行监控；一个哨兵节点可以监控多个主节点；
- 数据节点：主节点和从节点都是数据节点；

3.1.2 功能

监控
- 哨兵节点会不断的检查主节点和从节点的运行情况是否正常；
自动故障转移
- 当主节点不能正常工作时，哨兵节点会选举一个从节点作为主节点，并让其它从节点改为复制新的主节点；
配置提供者
- 客户端在初始化时，通过链接哨兵节点来获取当前redis服务的主节点地址；
通知
- 哨兵可以将故障转移的结果发送给客户端；

3.1.3 哨兵大致原理

首先，哨兵节点会针对其他的哨兵节点和数据节点进行监控，当发现节点不可达时，会对节点做下线标识；
如果被标记的节点是主节点，它会和其它的哨兵节点进行协商，当大多数的哨兵节点都认为该节点不可达时，则会选举出一个哨兵节点来完成故障自动转移工作，同时会将该变化通知到redis的应用方。

3.1.4 哨兵故障转移流程

主节点出现故障，此时俩个从节点与主节点失去连接，主从复制失败；
每个哨兵节点通过定期监控发现主节点出现了故障，然后将该节点标记为不可达；
多个哨兵结点对主节点的故障达成一致则会选取其中一个哨兵节点负责处理主节点的失效转移；
哨兵节点会选取另一个从节点作为主节点，然后建立新的主从关系，失效的旧的节点会在恢复后自动变为从节点；

3.1.5 底层原理

特殊命令
- 哨兵节点是运行在特殊模式下的redis节点，其支持的命令和普通的redis节点不同。如下：
- TODO
定时任务
- 每个哨兵节点都维护了三个定时任务，分别如下：
  - 通过向主从节点发送info命令获取最新的主从结构；
  - 通过发布订阅功能获取其它哨兵节点的信息；
  - 通过向其它节点发送ping命令进行心跳检测，判断是否下线；
主观下线
- 在心跳检测的定时任务中，如果其它节点超过一定时间没有回复，哨兵节点会将其主观下线，标记不可达；
客观下线
- 哨兵节点在对主节点进行主观下线后，会通过sentinelis-master-down-by-addr命令询问其它哨兵节点该主节点的状态，如果判断主节点下线的哨兵节点数量达到一定的阈值，则会对该主节点进行客观下线；
- 注意：客观下线时主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵节点主观下线后，不会再有后续的客观下线和故障转移操作；
选举领导者哨兵节点
- 当主节点被判断客观下线之后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并有该领导者节点对其进行故障转移操作；
- 监视该主节点的所有哨兵节点都有可能被选举为领导者，选举使用的是Raft算法，基本思路是先到先得：即在一轮选举中，哨兵A向哨兵B发送成为领导者的请求，如果B没有同意过其它哨兵节点，则会同意A成为哨兵节点；
- 一般来说，哨兵选择的速度很快，谁先完成客观下线，一般就能成为领导者；
故障转移
- 选举出的领导者哨兵节点开始进行故障转移，该操作大致有以下三步：
  - 在从节点中选择新的主节点：选择的原则是：首先过滤掉不健康的从节点，然后选择优先级最高的从节点(由slaver-priority指定)。如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点；
  - 更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点，并通过slaveof命令让其它从节点成为其从节点；
  - 将已经下线的主节点设置为新的主节点的从节点。当故障的主节点恢复后重新上线则其会成为新的主节点的从节点。