redis 集群模式

        Redis ⽀持三种集群模式，分别为主从模式、哨兵模式和 Cluster 模式。

        最初，Redis 采⽤主从模式构建集群。在这种模式下，如果主节点 (master) 出现故障，需要⼿动将从节点 (slave) 转换为主节点。然⽽，这种模式在故障恢复⽅⾯效率不⾼。

        为了提⾼系统的可⽤性，Redis 引⼊了哨兵模式。在哨兵模式中，⼀个哨兵集群负责监控主节点和从节点。如果检测到主节点故障，系统可以⾃动将从节点晋升为新的主节点。这提⾼了故障恢复的⾃动化程度。

        尽管如此，哨兵模式仍然⾯临内存容量和写⼊性能的限制，因为这种模式的写⼊能⼒仍然局限于单个节点。为了解决这⼀问题，Redis 在 3.x 版本之后推出了 Cluster 集群模式。 Cluster 模式通过数据分⽚和节点的⽔平扩展，实现了更⾼效的内存利⽤和写⼊性能。4

1.主从模式

1.1概念

在 Redis 的主从复制架构中，系统通过定义主库（ master ）和从库（ slave ）的⻆⾊，实现数据的⾼效同步和备份。这⼀架构具体包含以下特点：

• master 的读写能⼒ ： master 是系统中的数据中⼼，它不仅承担全部的写操作，还能处理读请求。当在 master 上执⾏任何改变数据的操作时，这些更改会⾃动且实时地同步到所有 slave。

• 单向数据流 ：数据同步流是单向的，意味着数据只从 master 流向 slave ，确保了数据同步的⼀致性和可靠性。

• slave 的只读特性 ： slave 通常被配置为只读模式，它们接收并存储从 master 传来的数据。这样设计主要是为了分散读取压⼒，从⽽提⾼系统的整体读取性能。

• 主 slave 的对应关系 ：⼀个 master 可以对应多个 slave ，形成⼀对多的关系。这种结构利于数据的冗余备份和读取负载的分散。相反，⼀个 slave 只能对应⼀个 master ，以保持数据同步的

⼀致性。

• slave 的容错性 ：如果某个 slave 出现故障，它对系统其他部分的影响是最⼩的。即便在 slave 宕机的情况下，其它 slave 仍能继续提供读服务， master 也能保持正常的读写操作。当故障的slave 恢复后，它会⾃动从 master 同步缺失的数据。

• master 故障的影响 ： master 的故障会导致 Redis 暂时⽆法处理新的写请求，但已连接的 slave 可以继续提供读服务。⼀旦 master 恢复， Redis 会重新提供完整的读写服务。

• master 故障的应对机制 ：在当前的 master 发⽣故障时，系统不会⾃动在 slave 中选择⼀个新的 master 。这需要通过额外的⾼可⽤性解决⽅案来实现，例如使⽤ Redis Sentinel 或 Redis Cluster来管理 master 的选举和故障转移。

1.2 主从复制原理

1.2.1 全量复制

从节点通过配置⽂件中的replicaof {masterip} {port} 获得主节点 ip 和 port ，然后向主节点发送 psync {repID} {offset} 指令，其中 repID 表示主节点唯⼀标识，offset 为复制偏移量，因为当前从节点与主节点尚未连接，且尚未开始复制，所以repID 为 ? ， offset 为 -1 ；

• 主节点收到 psync {repID} {offset} 指令后，会响应从节点并发送fullresync {repID} {offset} 指令，从节点会将主节点的repID 和 offset 保存下来；

• 主节点收到 psync {repID} {offset} 指令后，会执⾏ bgsave 异步的⽣成 RDB ⽂件，然后主节点将 RDB ⽂件发送给从节点，从节点接收到RDB ⽂件后，会清空内存数据，然后加载RDB ⽂件的数据到内存中；

• 由于主节点⽣成 RDB ⽂件时是异步⽣成的，此时主节点是⾮阻塞的，可以继续处理业务，所以在⽣成 RDB ⽂件期 间 ， 发送 RDB ⽂件期间 和 从节点加载 RDB ⽂件期间 主节点执⾏的写指令均会存放到缓冲区replication_buffer中，所以当从节点加载完RDB ⽂件后，主节点会将 replication_buffer 中的内容发送给从节点，从节点会执⾏replication_buffer 中的指令，从⽽达到和主节点⼀致的状态。

1.2.2 增量复制

主节点和从节点如果因为某些原因，断开了连接，⽽断开连接这段时间⾥主节点⼜处理了⼀些写指令，那么从节点重新连接后，应该怎么将断开连接那段时间⾥的写指令同步给重

连的从节点？通常的想法就是 再执⾏⼀次全量同步 ，在 2.8 之前的版本，确实是这么实现的，但从 2.8 版本开始，引⼊了 增量同步

具体的实现如下。

• 主节点维护着⼀份 repl_backlog_buffer 缓冲区域，叫做 复制积压缓冲区 ，主节点在任何时候执⾏写指令时，都会将写指令记录在 repl_backlog_buffer 中， repl_backlog_buffer 是⼀个环形数组，所以当数组满时，后续再添加的写指令会覆盖旧的写指令，因此主节点还使⽤了⼀个叫做master_repl_offset 的偏移量，来记录主节点的存到 repl_backlog_buffer 中的最新写指令的位置， master_repl_offset 就是上⾯提到的offset ，只不过在主节点中叫做 master_repl_offset ；

• 从节点也有⼀个偏移量叫做 slave_repl_offset ，⽤来记录从节点已经从主节点的 repl_backlog_buffer 中同步到的最新写指令的位置；

• 主节点收到写指令后， master_repl_offset 增加，从节点从主节点的 repl_backlog_buffer 同步了写指令后， slave_repl_offset 增加；

• 从节点断开重连后，会向主节点发送 psync {repID} {slave_repl_offset} 指令，此时 slave_repl_offset 通常会⼩于 master_repl_offset ，所以主节点仅需要将slave_repl_offset到 master_repl_offset 之间的写指令同步给从节点，这就是 增量同步 。

特别注意 ：如果 repl_backlog_buffer 中记录的从节点断开连接期间的写指令已经被后续的写指令覆盖，那么此时不能执⾏增量同步，⽽是需要执⾏全量同步，所以需要将repl_backlog_buffer 的⼤⼩设置⼀个合理的值，来尽可能的保证不出现重连后需要全量同步的情况。

2.哨兵集群架构

        哨兵模式是主从复制模式的⼀种进阶形式，继承了主从复制的所有优势，如数据⼀致性和读写分离。它的核⼼优点在于能够⾃动实现主从切换和故障转移，从⽽提升了系统的可⽤性和鲁棒性。在哨兵模式下，系统能够从⼿动切换转变为⾃动切换，极⼤地增强了系统的⾃动化程度和稳定性。然⽽，哨兵模式也存在⼀定的局限性，特别是在在线扩容⽅⾯。当集群容量接近或达到上限时，进⾏扩容操作相对较为复杂和困难。

        哨兵通过发送命令(ping命令)，等待Redis服务器响应，如果在指定时间内，主机Redis⽆响应，从机则判断主机宕机，选举从机上位，从⽽监控运⾏的多个Redis实例。

第⼀步：⼼跳机制

每个 Sentinel 会每秒钟⼀次的频率向它所知的主服务器、从服务器 以及其他 Sentinel 实例 发送⼀个 PING 命令，获取其拓扑结构和状态信息。

第⼆步：判断master节点是否下线

每个 sentinel 哨兵节点每隔1s 向所有的节点发送⼀个PING命令，作⽤是通过⼼跳检测，检测主从服务器的⽹络连接状态。

如果 master 节点回复 PING 命令的时间超过 down-after-milliseconds 设定的阈值（默认30s）则这个 master 会被sentinel 标记为主观下线。

第三步：基于Raft算法选举领头sentinel

master客观下线，那就需要⼀个sentinel来负责故障转移，所以需要通过选举⼀个sentinel的领头⽺来解决。

第四步：故障转移

故障转移的⼀个主要问题和选择领头sentinel问题差不多，就是要选择⼀个slaver节点来作为master。

选择主Maseter过程⼤致如下：

① 选择优先级最⾼的节点，通过sentinel配置⽂件中的replica-priority配置项，这个参数越⼩，表示优先级越⾼；

② 如果第⼀步中的优先级相同，选择offset最⼤的，offset表示主节点向从节点同步数据的偏移量，越⼤表示同步的数据越多；

③ 如果第⼆步offset也相同，选择run id较⼩的；

这样通过以上四⼤步骤，实现由Redis Sentinel⾃动完成故障发现和转移，实现⾃动⾼可⽤。

第五步：通知

通知所有⼦节点新的master，后边从新的master上边同步数据；⼴播通知所有客户端新的master。

3.Cluster模式

        由于数据量过⼤，单个Master 复制集难以承担，因此需要对多个复制集进⾏集群，形成⽔平扩展每个复制集只负责存储整个数据集的⼀部分，这就是 Redis 的集群，其作⽤是提供在多个Redis 节点间共享数据的程序集。

        Redis的数据分片（sharding）是一种将一个Redis数据集分割成多个部分，分别存储在不同的Redis节点上的技术。它可以用于将一个单独的Redis数据库扩展到多个物理机器上，从而提高Redis集群的性能和可扩展性。
        Redis数据分片的实现方式通常是将数据按照某种规则（例如，key的hash值）分配到不同的节点上。当客户端想要访问某个key时，它会先计算出这个key应该存储在哪个节点上，然后直接连接到该节点进行操作。因此，对于客户端而言，Redis集群就像是一个大型的、统一的数据库，而不需要关心数据的实际分布情况。
在Redis的Cluster 集群模式中，使用哈希槽（hash slot）的方式来进行数据分片，将整个数据集划分为多个槽，每个槽分配给一个节点。客户端访问数据时，先计算出数据对应的槽，然后直接连接到该槽所在的节点进行操作。Redis Cluster还提供了自动故障转移、数据迁移和扩缩容等功能，能够比较方便地管理一个大规模的Redis集群。

Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责⼀部分 hash 槽。

集群的整个数据库被分为 16384 个槽（ slot ），数据库中的每个键都属于这16384 个槽的其中⼀个，集群中的每个节点可以处理 0 个或最多 16384 个槽。

Key 与哈希槽映射过程可以分为两⼤步骤：

1. 根据键值对的 key ，使⽤ CRC16 算法，计算出⼀个 16 bit 的值；

2. 将 16 bit 的值对 16384 执⾏取模，得到 0 ～ 16383 的数表示 key 对应的哈希槽。