参考网址：
https://tech.souyunku.com6844903663362637832
https://tech.souyunku.com6844903726142996494
1. Redis高可用概述
Redis高可用特性实现技术主要包括：持久化、复制、哨兵和集群。下面简单介绍下这几项技术概念：
- 持久化：主要作用是数据备份，将数据及时备份到硬盘上，防止由于由于服务宕机等原因丢失数据。
- 复制：复制是高可用Redis的基础，哨兵和集群模式都是复制模式基础上实现高可用的。复制主要实现了多机备份、读操作的负载均衡和简单的故障恢复。
- 哨兵：哨兵模式主要是在复制基础上实现了自动化的故障恢复。缺点是：写操作无法负载均衡和存储能力受单机限制。
- 集群：集群模式通过部署多台主服务器，解决了写操作无法负载均衡、和存储能力受单机限制的缺点，实现了较为完善的高可用方案。
2. 复制模式（Replication）
- 复制模式中，官网都使用了replica instance来描述，为了方便，还是称为从服务器。
2.1 概念
Redis支持多个从服务器复制主服务器的数据，实现多机备份、读操作负载均衡和简单故障恢复。
- 备注：主从复制模式，读操作请求会打到从服务器上？未验证。
2.2 同步过程
参考网址：
https://redis.io/topics/replication
https://tech.souyunku.com6844903726142996494#heading-8
https://tech.souyunku.com/manmanrenshenglu/p/9013151.html
主从服务之间同步数据包括两种方式：完全重同步、部分重同步和命令传播。
2.2.1 命令传播
当主从服务器间正常链接时，主服务器会向从服务器发送写命令，从服务器接收写命令后执行相应写操作。
- 备注：写命令还包括键值过期等。
2.2.2 部分重同步
当主从服务器之间连接断开、或因网络原因发生超时，使用部分重同步来实现高效同步。在从服务器重新连接上主服务器时，从服务器会向发送PSYNC命令，并报告偏移量，主服务器会根据偏移量发送连接断开期间的写命令序列（命令会存储在复制积压缓冲区），执行部分重同步。
2.2.3 完全重同步
在部分重同步不可用、或初次建立连接的情况下（启动时就会），会使用完全重同步。从服务器会向主服务器发送SYNC命令，主服务器需要进行如下操作：
- （1）使用
BGSAVE进行全量持久化（RDB），并使用缓冲区存储现在开始的写命令； - （2）将生成的RDB文件发送给从服务器；
- （3）接着发送写命令序列给从服务器。
从服务器接收和载入来自主服务器的RDB文件，并执行写命令。
从服务器完全重同步日志
下图展示了从服务器启动时完全重同步的日志，可以看出发送SYNC命令后，接收RDB文件并载入，然后接收写命令序列，并写入AOF文件。
主服务器完全重同步日志
下图展示了主服务器完全重同步日志，可以看出收到SYNC命令后，进行全量持久化，并发送给从服务器。
2.3 特点
优点
- 多机备份：从服务器数据由主服务器复制过去，主从服务器数据一致；
- 读请求负载均衡：主服务器负责接收写请求，多台从服务器接收读请求，可以进行负载均衡。（未验证）
- 简单故障恢复：在主服务器不可用时，可以通过人工干预，将从服务器变成主服务器，需要修改客户端以及其它从服务器连接主服务器的地址。
缺点
- 主节点存储能力受限；
- 主节点写能力受限；
- 不能自动恢复；
3. 哨兵模式（Sentinel）
参考网址：
https://redis.io/topics/sentinel
https://tech.souyunku.com6844903663362637832
https://tech.souyunku.com6844903730786074638
3.1 概念
在主从复制模式基础上，增加哨兵节点（至少3个），用于进行节点存活检测和主从切换，用于实现自动化故障恢复。
整体上看，哨兵模式提供以下能力：
- 监控：每个哨兵节点会以每秒一次的频率向Redis主从节点节点、及Sentinel发送
PING命令，根据回复判断其它节点是否在线。 - 通知：当某个被监控节点出现问题时，哨兵节点可以通过API向其它应用程序通知该事件。
- 故障转移：在主节点下线后，能够将从节点升级为主节点，保证服务的可用性。
- 配置提供：理解是主从切换后可以自动修改Redis节点配置文件。
3.2 节点存活检测
3.2.1 主观下线
如果在down-after-milliseconds时间（默认30s）内主节点对哨兵节点的PING命令都是无效回复，那么认为该主节点主观下线（即当前哨兵节点主观认为该主节点下线）。
sentinel down-after-milliseconds <master-name> <milliseconds>
3.2.2 客观下线
在哨兵模式中，至少存在3个哨兵节点。
在某个哨兵节点判断主节点主管下线后，需要发送命令给其它哨兵节点，多个哨兵节点间进行投票，当超过quorum个哨兵节点认为主节点下线，那么这时候认为主节点客观下线。接下来会执行故障转移操作。
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 7102 2
3.3 选举领头哨兵
在检测出客观下线后，各个哨兵节点需要选举领头哨兵，由领头哨兵执行故障转移操作。
选举策略暂未深入研究
3.4 故障转移
故障转移的操作主要可以分为以下步骤，这些步骤会修改哨兵节点和Redis节点配置文件。
- 从主节点的从节点中选取一台作为新的主节点；
- 其它从节点复制新的主节点，哨兵节点监听新的主节点；
- 已经下线的主节点重新连接时，使其变成从节点，并且复制新的主节点。
选取从节点的策略暂未研究。
故障转移过程参考图
（1）检测出客观下线
（2）选举领头哨兵，并选举新的主服务器 
（3）旧主节点重连，成为从节点 
3.5 故障转移实战
哨兵节点启动时
（1）哨兵节点日志
从三个哨兵节点日志中均可以观察到，监听主节点的信息，如下：
（2）连接redis节点查看主从信息
使用redis-cli连接redis节点，使用info replication命令可以查看当前节点角色、主节点信息，如下图：
（3）连接哨兵节点查看哨兵、主从节点信息
使用redis-cli连接redis节点，使用info sentinel命令可以查看主节点信息、哨兵数目、从节点数目，如下图：
关闭主节点后
通过关闭主节点，来观察哨兵模式自动故障恢复（主从切换）效果。
（1）哨兵节点日志
关闭主节点后，观察哨兵节点日志，可以发现经过了主节点客观下线 -> 选择新的主节点 —> 其它节点复制新的主节点 的三个过程。
（2）哨兵节点配置文件
此时，观察发现哨兵节点的配置文件也已经被修改。
主节点信息：
从节点信息： 
（3）连接哨兵/redis节点查看主从信息
连接哨兵节点，观察到主节点已改变
连接redis节点，观察到主节点已改变 
（4）查看redis节点配置文件
观察到配置文件已经被修改
（5）查看redis节点日志文件
观察到 同步主节点失败 -> 复制新的主节点 -> 进行部分重同步
3.6 特点
优点
- 高可用，能够自动故障恢复。
缺点
- 主节点写能力受单机限制。
- 主节点存储能力受单机限制。