谈谈Redis的几种经典集群模式

​

目录

前言 

主从复制

哨兵模式

分片集群

前言 

Redis集群是一种通过将多个Redis节点连接在一起以实现高可用性、数据分片和负载均衡的技术。它允许Redis在不同节点上同时提供服务，提高整体性能和可靠性。在Redis中提供集群方案总共有三种：主从复制、哨兵模式、Redis分片集群。这些都是目前主流经典的集群模式，redis做集群的好处：

• 采用Redis集群方案解决单点故障问题
• 对于高并发读写请求,采用集群方案提升Redis作业能力
• 处理大量数据,多个Redis节点实现数据的分布式存储

下面我将会谈谈这三种集群方式的演化与一些细节。

主从复制

主从模式指的是使用一个Redis实例作为主机，其余的实例作为备份机，主机和从机的数据完全一致。主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取，也就是说客户端可以将数据写入到主机，由主机自动将数据的写入操作同步到从机。

​编辑

数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

 引入主从复制的目的有两个：一是读写分离，分担 master 的压力。二是容灾备份。

主从复制优点：做到读写分离，提高服务器性能；

主从复制缺点：一旦Master节点由于故障不能提供服务，需要人工将Slave节点晋升为Master节点；宕机前部分有部分数据未同步到从机，切换IP后会引入数据不一致降低系统可用性，数据量特别大一个主是存储不了。

其中，主从数据同步分为了两个阶段，一个是全量同步，一个是增量同步。

全量同步是指从节点第一次与主节点建立连接的时候使用全量同步：

• 从节点请求主节点同步数据，其中从节点会携带自己的replication id和offset偏移量。
• 主节点判断是否是第一次请求，主要判断的依据就是，主节点与从节点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点就会把自己的replication id和offset发送给从节点，让从节点与主节点的信息保持一致。
• 在同时主节点会执行bgsave，生成rdb文件后，发送给从节点去执行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这样就保持了一致

当然，如果在rdb生成执行期间，依然有请求到了主节点，而主节点会以命令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送给从节点，这样就能保证主节点与从节点完全一致了，后期再同步数据的时候，都是依赖于这个日志文件，这个就是全量同步

如果不是第一次与主节点建立连接，则进行增量同步：

• 当从节点服务重启之后，数据就不一致了，所以这个时候，从节点会请求主节点同步数据，
• 主节点还是判断不是第一次请求，不是第一次就获取从节点的offset值，然后主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

哨兵模式

 我们在上面提到了主从模式当主服务器宕机后，需要手动把一台从服务器切换为主服务器，需要人工干预进行切换，为了解决这个问题出现了哨兵模式。

redis2.8 中提供了哨兵工具，来实现自动化的系统监控和故障恢复。哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行多个 Redis 实例。

哨兵节点是特殊的redis节点，不存储数据。 

​编辑

 当主服节点不可用，Sentinel会自动选举一个从节点作为新的主节点，并让其它的从节点从新的主节点复制数据，用户的请求会被变更为新的主节点，然而一个哨兵进程对Redis节点进行监控有可能会出现误判。为此，一般使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

主观下线

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）；如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态。

客观下线

当有足够数量（半数以上）的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）；若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

故障转移

当前哨兵虽然发现了主数据客观下线，需要故障恢复，但故障恢复需要由领头哨兵来完成。这样来保证同一时间只有一个哨兵来执行故障恢复，选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。

① 首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选出之后通过slaveif no ont将该从服务器升为新主服务器。

② 所有在线的从数据库中，选择优先级最高的从数据库。优先级通过replica-priority参数设置，优先级相同，则复制的命令偏移量越大(复制越完整)越优先 ， 如果以上都一样，则选择运行ID较小的从数据库。

③ 选出一个从数据库后，领头哨兵将向从数据库发送SLAVEOF NO ONE命令使其升格为主数据库，而后领头哨兵向其他从数据库发送 SLAVEOF命令来使其成为新主数据库的从数据库，最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。

集群脑裂  

由于redis master节点和redis salve节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到master，所以通过选举的方式提升了一个salve为master，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在old master那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将old master降为salve，这时再从新master同步数据，这会导致old master中的大量数据丢失。

• 可以设置最少的salve节点个数，比如设置至少要有一个从节点才能同步数据
• 可以设置主从数据复制和同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失

哨兵模式优点：主从可以自动切换，系统更健壮，可用性更高；

哨兵模式缺点：最大的缺点就是还要多维护一套哨兵模式，实现起来也变的更加复杂增加维护成本。

分片集群

分片集群主要解决的是，海量数据存储的问题，集群中有多个master，每个master保存不同数据，并且还可以给每个master设置多个slave节点，就可以继续增大集群的高并发能力。同时每个master之间通过ping监测彼此健康状态，就类似于哨兵模式了。当客户端请求可以访问集群任意节点，最终都会被转发到正确节点。

采用无中心结构，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis 分片集群引入了哈希槽的概念，有 16384 个哈希槽，集群中每个主节点绑定了一定范围的哈希槽范围， key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，通过槽找到对应的节点进行存储。

主要是针对海量数据+高并发+高可用的海量数据场景，Redis集群模式的性能和高可用性均优于哨兵模式。

​