Redis复制、哨兵、集群
Redis实现高可用相关的技术，它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：
- 持久化：主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
- 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
- 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
- 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
1 主从复制
1.1 拓扑结构
主从拓扑1
主从拓扑2
1.2 复制模式
- 全量复制
- 部分复制：复制积压缓冲区
1.3 问题点
- 同步故障
- 复制数据延迟(不一致)：不可避免，可优化网络环境；延迟过大时，通知应用不再通过该从节点读取数据。
- 读取过期数据(Slave 不能主动删除数据)：Redis 3.2中，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端。
- 从节点故障：需要及时修改应用程序读写Redis数据的连接，手动或自动。
- 主节点故障：选择一个从节点升为主节点。
- 避免全量复制
- 选择小主节点(分片)、低峰期间操作。
- 如果节点运行 id 不匹配(如主节点重启、运行 id 发送变化)，此时要执行全量复制，应该配合哨兵和集群解决。
- 主从复制积压缓冲区不足产生的问题(网络中断，部分复制无法满足)，可增大复制缓冲区( rel_backlog_size )。
- 复制风暴：当一个主机下面挂了很多个从机时，master 挂了，这时 master 重启后，因为 runid 发生了变化，所有的 slave 都要做一次全量复制，这将引起单节点和单机器的复制风暴，开销会非常大。应该把主节点尽量分散在多台机器上，避免在单台机器上部署过多的主节点。当主节点所在的机器故障后提供故障转移机制，避免机器恢复后进行密集的全量复制。
2. 哨兵
2.1 拓扑图
哨兵拓扑图
2.2 节点下线
- 主观下线
- 即 Sentinel（哨兵） 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。
- Sentinel 集群的每一个 Sentinel 节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在
down-after-milliseconds时间内没有回复 Sentinel 节点的心跳包，则该 Redis 节点被该 Sentinel 节点主观下线。
- 客观下线
- 所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum 个统一。
- 当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要 Sentinel 集群的其他 Sentinel 节点共同判断为主观下线才行。
- 该 Sentinel 节点会询问其它 Sentinel 节点，如果 Sentinel 集群中超过 quorum 数量的 Sentinel 节点认为该 Redis 节点主观下线，则该 Redis 客观下线。
2.3 Leader选举
选举出一个 Sentinel（哨兵） 作为 Leader：集群中至少有三个 Sentinel 节点，但只有其中一个节点可完成故障转移。
选举流程：
- 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求设置它为领导者。
- 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，则同意该请求，否则拒绝。
- 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum，则它成为领导者。
- 如果此过程有多个 Sentinel 节点成为领导者，则等待一段时间再重新进行选举。
2.4 故障转移
- 转移流程
- Sentinel 选出一个合适的 Slave 作为新的 Master(slaveof no one 命令)。
- 向其余 Slave 发出通知，让它们成为新 Master 的 Slave( parallel-syncs 参数)。
- 等待旧 Master 复活，并使之称为新 Master 的 Slave。
- 向客户端通知 Master 变化。
- 从 Slave 中选择新 Master 节点的规则
- 选择 slave-priority 最高的节点。
- 选择复制偏移量最大的节点(同步数据最多)。
- 选择 runId 最小的节点。
Sentinel 集群故障转移完成，所有 Sentinel 又会恢复平等。Leader 仅仅是故障转移操作出现的角色。
3. 分布式集群
3.1 拓扑图
分布式集群拓扑图
3.2 Gossip通讯
Gossip通讯
3.3 寻址分片
3.3.1 hash取模
- hash(key)%机器数量
- 问题：当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模数据迁移。
3.3.2 一致性哈希分区
一致性哈希分区
3.3.3 带虚拟节点的一致性哈希分区
CRC16(key)%16384
带虚拟节点的一致性哈希分区
