redis之高可用

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

主从复制

2.8以前的版本只有完整重同步（SYNC）的方式，效率十分低。从2.8开始，使用PSYNC代替SYNC来执行复制时的同步操作。

PSYNC部分重同步功能由一下三个部分构成：

1. 主从服务器的复制偏移量，可以看作是已复制的字节数
2. 主服务器的复制积压缓冲区
3. 服务器的运行ID

如果offset偏移量之后的数据仍然存在于复制积压缓冲区里，那么主服务器对从服务器执行部分重同步操作；否则主服务器将对从服务器执行完整重同步操作。

第一次复制时，从发送psync ? -1；否则发送psync <runid> <offset>

主发送

1. +fullresync <runid> <offset>
2. +continue
3. -ERR

同步后，主从服务器进入命令传播阶段。

心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送REPLCONF ACK <replication_offset>，其中replication_offset是当前从服务器的复制偏移量。

作用：

1. 检测主从服务器的网络连接状态
2. 辅助实现min-slave配置选项。min-slaves-to-write, min-slaves-max-lag, 可以防止主服务器在不安全的情况下执行写命令。
3. 检测命令丢失

Sentinel

检测主观下线状态

默认情况下，sentinel每秒会向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他sentinel）发送ping命令，并通过ping命令来判断实例是否在线。

当主服务器down-after-milliseconds毫秒内，连续向sentinel返回无效回复，那么sentinel会主观认为主服务器已经下线

检查客观下线状态

向同样监视主服务器的其他sentinel询问，看它们是否也认为主服务器已经下线。当认为主服务器下线的sentinel超过quorum时，那么该sentinel就会认为主服务器已经进入客观下线状态。

选举领头sentinel

先到先得（看谁发送的命令更快到达）
半数以上的支持。
sentinel会向其他sentinel发送带有自己runid的命令，sentinel在第一次接受到命令时会将runid的sentinel作用自己的局部领头sentinel。如果一个sentinel获得超过半数的sentinel的投票，那么它就成为领头sentinel。
领头sentinel的产生需要半数以上sentinel的支持 如果在给定时限内，没有选举出sentinel，那么将在一段时间后再次选举，直到选出领头sentinel。

故障转移

1. 从从服务器中挑选出一个将其转换为主服务器
2. 将其他从服务器变为新的主服务器的从服务器
3. 将已下线的主服务器设置为新的主服务器的从服务器

挑选原则：

1. 删除处于下线状态的从服务器
2. 删除所有最近5秒没有回复过领头的从服务器
3. 删除与主服务器过早断开的从服务器，从而保证新的主服务器的数据是比较新的
4. 从剩下的从服务器中挑选优先级最高的从服务器。