Redis面试——集群

一、主从同步

1. 当从节点初次与主节点建立复制关系时，从节点会向主节点发送 replicaof 命令（Redis 5.0 之前为 slaveof 命令）。主节点收到该命令后，会 fork 出一个后台子进程来生成 RDB 快照。生成 RDB 快照后，主节点将其发送给从节点，从节点接收并加载该快照以恢复数据，这一过程被称为全量同步
2. 在主节点生成 RDB 快照期间，其主线程仍会继续处理新的写命令，并将这些写命令记录到复制积压缓冲区（环形缓冲区）中。从节点完成 RDB 快照数据的加载后，会向主节点发送 psync 命令，并携带自身当前的复制偏移量。若该偏移量对应的写命令仍存在于复制积压缓冲区中，主节点会将从该偏移量开始的所有写命令发送给从节点，从节点执行这些写命令以更新数据，此过程为增量同步。若该偏移量对应的写命令已不在复制积压缓冲区中，意味着无法通过增量同步来更新数据，此时会触发新一轮的全量同步，即主节点再次生成 RDB 快照并发送给从节点
3. 若主节点与从节点之间的网络连接中断，从节点在重新连接上主节点后，会向主节点发送 psync 命令，并携带自身的复制偏移量。后续的同步过程与上述情况一致，根据偏移量是否在复制积压缓冲区中，决定进行增量同步还是全量同步

二、哨兵机制

（1）主节点故障判断

当部署了哨兵节点后，它们会定时向主节点发送心跳包（PING 命令），并等待主节点响应。若某个哨兵在指定时间（down - after - milliseconds 配置项设定的时间）内未收到主节点的响应，它会率先认为主节点出现故障，此为 “主观下线”（SDOWN，Subjectively Down）。当超过半数（quorum 配置项设定的数量）的哨兵都认为主节点主观下线时，就会判定主节点进入 “客观下线”（ODOWN，Objectively Down）状态 。此时，哨兵们会启动故障转移流程，从该主节点的从节点中选举出新的主节点

（2）选举规则

1. 从节点优先级：Redis 为每个从节点设置了一个优先级（priority 配置项），数值越小优先级越高。在选举时，优先级最高的从节点会优先被选为新的主节点。若没有配置优先级，或者多个从节点优先级相同，则会采用其他规则
2. 复制偏移量：复制偏移量反映了从节点与主节点的数据同步程度。复制偏移量越大，说明该从节点的数据与原主节点越接近，数据丢失的可能性越小。当优先级无法区分时，会选择复制偏移量最大的从节点成为主节点
3. 从节点 ID：若多个从节点的优先级相同且复制偏移量也相同，那么从节点的唯一 ID 会作为最后一个选举依据。ID 越小的从节点，越优先被选举为新的主节点

（3）故障转移后续

在选举出新的主节点后，哨兵节点会通过发布 - 订阅机制，通知所有连接过原主节点的客户端新主节点的信息，让客户端后续将请求发送到新的主节点上。当原来故障的主节点恢复正常后，它会自动转变为新主节点的从节点，重新加入到集群中进行数据同步

三、集群

（1）哈希槽分布

Redis 集群采用哈希槽（Hash Slot）来管理数据分布，总共有 16384 个哈希槽。当只有一台 Redis 服务器时，这 16384 个槽位都归这台服务器管理 。当部署了多台 Redis 服务器构成集群时，这些哈希槽会分配到各个节点上，但不一定是绝对均匀分布，管理员可以根据实际需求手动调整槽位的分配

（2）数据路由

当客户端发送的命令涉及某个键时，Redis 会使用 CRC16 算法对键进行计算，然后将计算结果对 16384 取模，所得结果就是该键对应的哈希槽编号。每个节点都维护着槽位与节点的映射关系，通过这个映射表就能知道该槽位对应在哪台 Redis 服务器上

（3）请求转发

客户端在启动时可以连接集群中的任意一台服务器。当客户端向连接的服务器发送请求，而该服务器发现请求的键并不在自己管理的槽位范围内时：

1. MOVED 重定向（槽位已永久迁移 ）：如果目标键所在的哈希槽已经永久迁移到另一个节点，当前节点会向客户端返回一个 MOVED 错误。该错误会携带新节点的地址信息，告知客户端应连接新的节点来获取数据
   1. 对于支持自动重定向的客户端（大多数 Redis 客户端库都具备此内置功能），在收到 MOVED 错误后，会自动提取新节点的 IP 和端口号，关闭当前连接，重新连接到新节点，并将后续所有涉及该哈希槽的请求发送到新节点
   2. 若客户端不支持自动重定向，就需要手动修改代码，更新客户端连接的节点信息，将后续请求发送到正确的节点
2. ASK 转向（槽位正在迁移 ）：当集群正在进行重新分片操作，源节点在迁移某个哈希槽到目标节点的过程中，可能部分键值对还留在源节点，部分已迁移到目标节点。此时如果客户端向源节点发送与该哈希槽中键有关的命令，且该键恰好已在目标节点，源节点会返回一个 ASK 错误
   1. 对于支持自动处理 ASK 错误的客户端，在收到 ASK 错误后，会先向目标节点发送一个 ASKING 命令（用于告知目标节点这是一次临时请求 ），然后重新发送原来的命令
   2. 若客户端不支持自动处理，就需要手动编写代码来处理：先向目标节点发送 ASKING 命令，再重新发送原始命令，才能完成操作

四、总结

Redis 的集群、主从复制和哨兵机制是可以同时存在并相互配合使用的，以满足不同的业务需求

1. 集群：当数据量很大时，为了分摊服务器压力，可采用 Redis 集群。Redis 集群会将 16384 个哈希槽分配到多个节点上，每个节点负责一部分槽位，从而将数据分散存储在多台服务器上。在集群中，每个节点既可以是主节点，也可以为这些主节点配备从节点（在创建集群时可指定），以实现高可用和读写分离
2. 主从复制：为了减轻读写压力，可在集群的基础上，对每个主节点进行主从复制。主节点负责处理写操作，从节点负责处理读操作，从而实现读写分离，提高系统的并发处理能力。主节点会将写操作同步到从节点，保证数据的一致性
3. 哨兵机制：为了保证 Redis 的高可用性，可引入哨兵机制。哨兵节点会监控主从节点的运行状态，当某个主节点出现故障时，哨兵会自动进行故障转移。它会从该主节点的从节点中选举出一个新的主节点，并通知客户端新主节点的信息，同时让其他从节点与新主节点建立复制关系

需要注意的是，在 Redis 集群中已经自带了一定的高可用特性，比如节点间的自动故障转移和数据分片。而哨兵机制通常更多用于非集群模式下的主从架构，来实现主节点的自动故障转移。不过，在一些复杂场景下，也可以将三者结合使用，以提供更强大的功能和更高的可靠性。例如，在集群的每个主从组中都配置哨兵，进一步增强每个主从组的高可用性