Redis 部署架构

Redis 部署架构主要有单机模式、主从模式、哨兵模式和集群模式。

单机模式

单机部署，读写都在一台机器，有性能瓶颈，如果宕机了就会导致缓存不可用。

主从模式

由于单机模式在⾼并发下会出现性能瓶颈，升级到⼀主多从的⽅式，master节点处理写操作，slave节点处理从操作，slave从master同步数据。

主从同步策略

主从同步在salve和master刚连接的时候进⾏全量同步，全量同步结束后开始增量同步。如果有需要，slave在任何时候都可以发起全量同步，其主要策略就是⽆论如何⾸先会尝试进⾏增量同步，如果不成功，则会要求slave进⾏全量同步，之后再进⾏增量同步。

全量同步

在master和slave节点建⽴连接之后，slave会向master发送增量同步（slave会携带⾃⼰的repid和offset），master接收了slave的增量同步请求之后，就会拿⾃身的replId和slave的replId进⾏判断，如果相同则进⾏增量同步，不相同则进⾏全量同步。之后master会将⾃⼰的replId和offset发送给slave。全量同步，master会执⾏bgsave⽣成⾃⼰的RDB⽂件，将⾃⼰的RDB⽂件发送给slave，slave清除原来已经有的RDB，将新的RDB加载到内存之中。

增量同步

增量同步是指在全量同步之后，从节点与主节点之间仅传输增量数据的同步⽅式。通过增量同步，从节点可以实时地获取主节点的写命令并应⽤到⾃⼰的数据集中，保持与主节点的数据⼀致性。 增量同步的具体步骤为：

• 主节点将发送给从节点的每个写命令都记录到内存中的复制积压缓冲区（Replication backlog）。
• 从节点定期向主节点发送PSYNC命令进⾏增量同步请求。
• 主节点⽐对从节点的复制偏移量（Replication offset），如果从节点的复制积压缓冲区中的数据还在，就执⾏部分复制（Partial Resynchronization），只发送从上次同步以后的写命令给从节点。
• 从节点接收到写命令后，将其重放到⾃⼰的数据集中，使从节点的数据保持与主节点⼀致。

优缺点

优点

• 主从复制对于master来说是⾮阻塞的，slave在进⾏主从复制的过程中，master依然可以处理请求；
• 主从复制对于slave来说也是⾮阻塞的，slave在进⾏主从复制的过程中也可以接受外界的查询请求，只不过这时候返回的数据不⼀定是正确的。（可以在slave的配置⽂件中配置，在同步过程中阻⽌查询）
• 每个slave可以接受来⾃其他slave的连接；
• 主从复制提⾼了Redis服务的扩展性，避免单节点问题，另外也为数据备份冗余提供了⼀种解决⽅案；
• 为了降低主redis服务器写磁盘压⼒带来的开销，可以配置让主redis不在将数据持久化到磁盘，⽽是通过连接让⼀个配置的从redis服务器及时的将相关数据持久化到磁盘，不过这样会存在⼀个问题，就是主redis服务器⼀旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空。

缺点

• 如果主节点(master)出现故障，需要⼿动将从节点(slave)转换为主节点，这种模式在故障恢复⽅⾯效率不⾼，需要⼈⼯介⼊。

哨兵模式

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

实现方式

通过引⼊哨兵进程，周期性地向Redis节点发送命令，并等待节点的响应，来判断被监控的Redis实例是否正常运⾏。若发现主节点出现故障，哨兵将基于预设的投票机制，⾃动将某个从节点晋升为新的主节点，保持服务的连续性和数据的可⽤性。

由于哨兵本身也是个独⽴的进⾏，因此也存在稳定性问题。哨兵⾄少需要 3 个实例才能保证⾃⼰的健壮性。

故障迁移

• 定期检测：哨兵每1s向master、slave和其他哨兵发送⼀次ping做⼼跳检测。如果master在⼀段时间内不回复或错误回复，该哨兵会认为这个节点主观下线。
• master下线：当超半数哨兵认为主观下线，则msater节点变为客观下线。 当master故障后，哨兵通过Raft算法（选举算法）共同选举出⼀个哨兵为 leader，来处理主节点的故障转移和通知。所以哨兵集群中节点≥3。

主观下线判定方法：
哨兵进程会使⽤ PING 命令检测它⾃⼰和主、从库的⽹络连接情况，⽤来判断实例的状态。
如果Sentinel发现主库或从库对 PING 命令的响应超时了，那么，Sentinel就会先把它标记为主观下线。
客观下线判定方法：
当⼀个哨兵节点发现主节点处于主观下线状态时，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。
如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将⾃⼰维护的结构体中将该主节点标记为SRIO DOWN（客观下线）。
客观下线询问命令是：SENTINEL is-master-down-by-addr <master ip> <master 端⼝号> <⽤于选举哨兵leader的配置> <*>。

• master的选举：
  • 过滤掉不健康的（已下线的）、没有回复哨兵 ping 响应的从节点；
  • 选择配置⽂件中从节点优先级配置最⾼的。（replica-priority，默认值为 100）；
  • 如果没有配置从节点优先级，那么选择复制偏移量最⼤，也就是复制最完整的从节点。
• 由leader执⾏故障转移：
  • 将某个slave升级为master，让其他slave指向新master；
  • 若原master恢复，也变为slave，并指向新master；
  • 通知客户端更换了master。

哨兵leader选举

在哨兵集群主节点客观下线的情况下，哨兵节点节点间会发起⼀次选举，命令为:SENTINEL is-master-down-by-addr <master ip> <master 端⼝号> <⽤于选举哨兵leader的配置> <该哨兵节点id>，只是runid这次会将哨兵⾃⼰的runid带 进去， 希望其他哨兵将⾃⼰设置为主节点。如果超过半数以上的哨兵节点返回将该节点标记为leader的情况下，会由该leader对故障进⾏迁移。leader选举一般采用Raft选举算法。

Raft选举算法

Raft算法是⼀种基于领导者的⼀致性算法，它要求集群中的每个节点都有三种⻆⾊：领导者（leader）、候选者（candidate）和跟随者（follower）。 领导者负责发起选举请求，候选者负责投票，跟随者负责响应领导者的指 令。Raft算法的核⼼是选举过程，分为以下⼏个步骤：

• 初始化：集群启动时，所有的节点都是跟随者，没有领导者。每个节点都有⼀个选举超时时间，随机在150ms到300ms之间，如果在超时时间 内没有收到领导者的⼼跳包，就会转变为候选者，开始发起选举。
• 发起选举：候选者会增加⾃⼰的选举轮次（term），并向其他节点发送选举请求，包含⾃⼰的选举轮次和标识。同时，候选者会给⾃⼰投⼀票，并重置⾃⼰的选举超时时间。
• 投票：跟随者收到选举请求后，会⽐较⾃⼰的选举轮次和候选者的选举轮次，如果⾃⼰的选举轮次更⼤，或者已经给其他候选者投过票，就会拒绝投票；否则，就会同意投票，并重置⾃⼰的选举超时时间。
• 统计票数：候选者收到投票回复后，会统计⾃⼰的票数，如果超过半数，就会成为领导者，并向其他节点发送⼼跳包，通知⾃⼰的领导地位；如果没有超过半数，就会继续等待投票回复，直到超时或者收到⼼跳包。
• 维持领导者：领导者会周期性地向所有跟随者发送⼼跳包，维持⾃⼰的领导地位，并检查跟随者的状态。如果领导者发现⾃⼰的选举轮次⼩于某个跟随者的选举轮次，就会认为⾃⼰的领导地位已经过期，转变为跟随者，重新开始选举超时计时。
• 处理冲突：如果集群中出现⽹络分区或者节点故障，可能会导致多个候选者同时发起选举，造成选举冲突。Raft算法通过随机化选举超时时间，使得冲突的概率降低。同时，如果⼀个候选者收到了另⼀个候选者的选举请求，它会拒绝投票，并重置⾃⼰的选举超时时间，避免⽆效的选举。

最终，只有⼀个候选者能够获得多数的票数，成为领导者，结束选举。

master节点选举

哨兵在选择新主库时,先按照⼀定的筛选条件，把不符合条件的从库去掉，再按照⼀定的规则，给剩下的从库逐个打分，将得分最⾼的从库选为新主库。选举过程如下：

• 从库筛选：在选主时，除了要检查从库的当前在线状态，还要判断它之前的⽹络连接状态，如果从库总是和主库断连，⽽且断连次数超出了⼀定的阈值，表明这个从库的⽹络状况并不是太好，排除该从库；
• 从库分数判断：Sentinle集群选主中，按照三个规则依次进⾏三轮打分，分别是从库优先级、从库复制进度以及从库 ID 号，只要在某⼀轮中，有从库得分最⾼，那么它就是主库了，选主过程到此结束，如果没有出现得分最⾼的从库，那么就继续进⾏下⼀轮；
  • 第⼀轮：优先级最⾼的从库得分⾼⽤户可以通过slave-priority配置项，给不同的从库设置不同优先级，⽐如，有两个从库，它们的内存⼤⼩不⼀样，可以⼿动给内存⼤的实例设置⼀个⾼优先级，在选主时， 哨兵会给优先级⾼的从库打⾼分，如果有⼀个从库优先级最⾼，那么它就是新主库了。
  • 第⼆轮：和旧主库同步程度最接近的从库得分⾼这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。主从库同步时有个命令传播的过程。在这个过程中，主库会⽤master_repl_offset记录当前的最新写操作在 repl_backlog_buffer中的位置，⽽从库会⽤slave_repl_offset这个值记录当前的复制进度。因为主库已挂，哨兵⽐较各个从库的slave_repl_offset⼤⼩，值越⼤的得分越⾼。
  • 第三轮：ID 号⼩的从库得分⾼，每个实例都会有⼀个 ID，这个 ID 就类似于这⾥的从库的编号，⽬前Redis在选主库时，有⼀个默认的规定： 在优先级和复制进度都相同的情况下，ID 号最⼩的从库得分最⾼，会被选为新主库。
• 重新配置从节点：当新主节点选举出来后，哨兵领导者会向所有的从节点发送命令，让它们与新主节点建⽴复制关系，更新⾃⼰的主节点信息。同时，哨兵领导者也会向所有的哨兵节点发送命令，让它们更新⾃⼰的主节点信息，并通知客户端使⽤新的主节点地址。

⾄此故障迁移完成。

cluster模式

Redis cluster是 Redis 3.0开始引⼊的分布式存储⽅案。集群由多个节点(Node)组成，Redis 的数据分布在这些节点中。集群中的节点分为主节点和从节点，只有主节点负责读写请求和集群信息的维护，从节点只进⾏主节点数据和状态信息的复制。

cluster部署架构图

实现原理

数据分片

数据分区(或称数据分⽚)是集群最核⼼的功能，集群将数据经过CRC16哈希到指定的节点上，⼀⽅⾯突破了Redis单机内存⼤⼩的限制，存储容量⼤⼤增加，另 ⼀⽅⾯每个主节点都可以对外提供读服务和写服务，⼤⼤提⾼了集群的响应能⼒，Redis单机内存⼤⼩受限问题。

客户端连接集群中任⼀实例即可发送命令，当 Redis Instance 收到⾃⼰不负责的 slot 的请求时，会将负责请求 Key 所在 slot 的 Redis Instance 地址返回给客户端，客户端收到后⾃动将原请求重新发往这个地址。⼀个Key 到底属于哪个 Slot 由(HASH SLOT =CRC16(key)mod 16384)决定。只有master 节点会被分配槽位，slave 节点不会分配槽位。

高可用保障

在Redis Cluster中，主节点之间会进⾏定期的健康检查和状态同步，确保数据的⼀致性。当其它主节点 ping ⼀个主节点 A 时，如果半数以上的主节点与 A 通信超时，那么认为主节点 A 宕机了，这时候主节点 A 的从节点可以通过选举机制快速选出新的主节点，实现故障的⾃动转移，从⽽确保服务的连续性。选举过程如下：

• 所有⼦节点向其他节点发送请求，请求⾃身成为主节点，其他节点收到请求后，返回投票信息，只有主节点 master 有权投票，且只能投⼀次；
• 当获取到的票数⼤于⼀半⼈数时（master 个数），就当选 master。

期间，所有⼦节点发送请求的时机有所有不同，所以基本都有先后顺序，很少会出现票数相同情况，如果相同，则重新选举，直到选出 master 为⽌。所以⾄少需要3主3从个节点，否则当节点出现问题，就会出现选举失败。