Redis 集群原理、主从复制和哨兵模式的详细讲解

---

引言：本文记录了博主在学习Redis的过程中的原理，了解为什么使用与怎么样使用 Redis 集群，在使用 Redis 集群时出现的主从复制和哨兵模式的相关知识。本文并不涉及Redis安装。

---

一、简单介绍什么是 Redis

首先，Redis是一个很重要的工具，它的英文全称是 Remote Dictionary Server 意思是远程字典服务，是一个开源的、基于内存的高性能键值存储数据库，读取和写入速度远超于常见的数据库。

另外，它支持多种数据结构，支持类型十分广泛，如字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）以及范围查询、位图（bitmaps）、超日志（hyperloglogs）和地理空间索引等。

• 被用于高性能缓存（最常用）
  • 作为缓存层，存储频繁访问的数据，减少对后端数据库的访问压力，从而提高系统的响应速度和吞吐量。
  • 在Web应用中，将用户会话信息、热点数据（如商品详情、用户信息等）存储在Redis中，避免每次都查询数据库。
  • 在后端的数据存储中，热点数据都可以存储在Redis中，提高访问速度，同时降低IO。
  • 只要有关热点数据，那就和缓存有关，基本就和Redis有关。
• 消息队列
  • 支持发布/订阅模式，可以作为消息队列使用，实现应用之间的异步通信。
  • 并不常用，虽然说增加消息中间件会增加额外的开销，但是在大型项目中，常常有访问峰值的出现，Redis的抗并发能力到达阈值时，就会影响队列问题。所以常常做到分工明确对后面的开发和维护效果更好。
• 分布式锁
  • 用于实现分布式环境下的锁机制，确保多个进程或线程在访问共享资源时的互斥性。
  • 在分布式系统中，多个实例需要对某个资源进行写操作时，通过Redis锁确保同一时间只有一个实例可以操作。
• 排行榜和计数器
  • 利用有序集合（Sorted Set）实现排行榜功能，对数据进行实时排序和计数。
  • 在游戏或社交应用中，实时更新用户的积分排名或统计页面访问次数。
• 会话管理
  • 存储用户会话信息，支持无状态的分布式应用。
  • 在Web应用中，将用户登录状态、会话数据存储在Redis中，实现会话的快速读取和共享。
• 数据持久化
  • 虽然Redis是基于内存的存储，但它支持多种持久化机制（如RDB和AOF），可以将数据持久化到磁盘，防止数据丢失。
  • 在需要数据持久化的场景中，定期将内存中的数据保存到磁盘，确保系统故障时数据不丢失。

二、为什么要使用 Redis 集群

首先，项目随着业务的扩展，单个Redis实例可能无法满足高并发和大数据量的需求，需要更强大的缓存组件。其次，项目常会出现网络问题和宕机问题等，会导致服务重启，存储在Redis中的热点数据就会丢失，这就是常见的单点故障问题。

使用Redis集群会有以下优势：

• 水平扩展：通过将数据分散到多个Redis节点上，增加系统的存储容量和处理能力。因为Redis集群使用哈希槽（hash slot）机制，将数据分布到多个节点上。每个节点负责一部分哈希槽，从而实现数据的水平扩展。
• 高可用性：通过主从复制和故障转移机制，确保系统的高可用性。Redis集群支持主从复制，当主节点故障时，从节点可以自动晋升为主节点，继续提供服务。此外，集群还支持故障检测和自动故障转移。
• 负载均衡：通过将请求分散到多个节点上，减轻单个节点的负载压力，提高系统的整体性能。客户端根据哈希槽将请求发送到不同的节点，从而实现负载均衡。
• 容错能力：通过冗余机制，确保部分节点故障时系统仍然可以正常运行。每个节点都有多个副本（主从复制），当某个节点故障时，其他副本可以接管其职责，确保数据的可用性。

上面提到了一个关键词：节点，下面解释下什么是节点，在集群中节点如何分配。

三、常说的Redis节点是什么，在集群中扮演什么角色

在Redis集群中，节点（Node）是指运行Redis服务的实例，它是一个独立的Redis服务器进程。每个节点负责存储一部分数据实现数据的分布，并且可以与其他节点通信以实现数据的分布和高可用性。

知道了什么是节点，关于节点的作用有以下描述：

• 数据存储：每个节点负责存储一部分键值对数据。通过哈希槽机制，整个键空间被划分为16384个哈希槽，每个节点会被分配一定数量的哈希槽。例如，如果有3个节点的集群，每个节点可能会被分配大约5461个哈希槽（16384 / 3 ≈ 5461）。这个是关于Redis集群的设计，后面会继续介绍。
• 数据分片：节点通过哈希槽机制实现数据的分片。当一个键被写入或读取时，Redis会根据键的哈希值计算出对应的哈希槽，然后将请求路由到负责该哈希槽的节点上。例如，键 user:1 可能被哈希到哈希槽 1234，而哈希槽 1234 被分配给了 节点A ，那么对 user:1 的操作就会被发送到 节点A 。
• 主从复制：每个节点可以有多个从节点（Replica）。主节点（Master）负责处理写操作，从节点通过复制主节点的数据来保持数据一致性。从节点不仅可以提供读操作，还可以在主节点故障时接管主节点的角色，实现高可用性。
• 故障转移：当主节点故障时，从节点会自动晋升为主节点，继续提供服务。集群中的其他节点会通过 内部通信机制检测到故障并触发故障转移。例如，如果主节点A故障，其从节点B会根据哨兵模式的选举等发哪个时晋升为主节点，客户端的请求会被自动路由到新的主节点B。
• 通信与协调：节点之间通过内部通信机制（如Gossip协议）交换状态信息，包括节点的健康状态、哈希槽的分配情况等。这种通信机制确保了集群的高可用性和数据一致性。

在Redis集群中，节点可以分为两种类型：也就是主节点和从节点。主节点负责写操作和数据分片，从节点负责数据复制和故障转移。

• 主节点（Master Node）：主节点负责处理写操作，并将数据同步到从节点。每个主节点负责一部分哈希槽，存储与这些哈希槽对应的键值对。
• 从节点（Replica Node）：从节点是主节点的副本，通过复制主节点的数据来保持数据一致性。从节点可以提供读操作，减轻主节点的负载。从节点在主节点故障时可以晋升为主节点，实现故障转移。

假设你有一个Redis集群，包含3个主节点和3个从节点，每个主节点有1个从节点。以下是节点的分配和作用：

• 主节点A：
  • 负责哈希槽范围：0-5460
  • 从节点：从节点A1
• 主节点B：
  • 负责哈希槽范围：5461-10922
  • 从节点：从节点B1
• 主节点C：
  • 负责哈希槽范围：10923-16383
  • 从节点：从节点C1

当客户端请求键 user:1 时：Redis计算键 user:1 的哈希值，确定其对应的哈希槽为 1234 。根据哈希槽分配，哈希槽 1234 属于 主节点B 。客户端将请求发送到主节点B。如果主节点B故障，从节点B1 会自动晋升为主节点，继续提供服务。现在知道了节点在Redis集群中的作用，再进一步了解Redis集群的工作原理。

四、Redis 集群实现主从复制

上面讲到了Redis集群的主从复制的概念和原理，主从复制就是将主节点和从节点中的数据同步，实现主节点负责处理写操作，从节点负责处理读操作，从节点通过复制主节点的数据来保持数据一致性。

我们要知道为什么要做主从复制，也就是要知道主从复制的优势是什么。

• 数据容灾。从机作为主机的一个数据备份，当主机宕机后，从机能够快速的切换成主机，达到一个高可用的目的。
• 读写分离。主机负责写数据，从机负责读数据，提高 Redis 的吞吐量，但是会发生数据一致性的问题，毕竟主从同步数据需要时间。

需要注意的是：

• 当 Redis 搭建主从后，从机就只能读数据，不能去写数据了，写的话会报错。
• 单纯的搭建 Redis 主从，不能实现主从的切换，也就是主机宕机后，从机还是从机，要想实现主从切换，必须引用 Redis 的哨兵机制。

下面通过图片解释，图片是百度搜索，找了两张，懒得自己画，看着不错就用了，如有侵权请联系。

如上图所示：我们跟着步骤来了解主从复制的原理：这张图展示了Redis主从实例之间的数据同步过程，具体如下：

首先两个实例：主实例和从实例IP地址信息，这个不多说。

第一阶段：建立连接，协商同步，为了全量复制做准备

• 从实例在配置完启动后，会根据配置的主机的 ip：port 去 ping 主机，看能不能 ping 通，建立一个 socket 通道。期间也会不断的进行心跳检测，保证二者实时感应到的。
• 从实例执行 replicaof 192.168.1.100 6379 或 slaveof 172.16.19.3 6379 命令（），向主实例发起连接请求。
• Redis 在 5.0.0 版本之前使用 slaveof 命令进行主从复制相关操作，从 5.0.0 版本开始使用 replicaof 命令替代 slaveof 命令，二者功能基本相同，主要用于设置一个 Redis 实例成为另一个实例的从节点，实现主从复制。避免存在歧视的问题。
• 连接请求就是从实例发送 psync ? -1 命令，请求进行数据同步。
• psync ：包含两个参数，分别是主服务器的 runID 和复制进度 offset 。
• runID ：每个 Redis 服务器在启动时会自动生成随机 ID 来唯一标识，第一次同步时，主从信息未知，所以设置为 ? 。
• offset ：表示复制的进度，第一次同步时，其值为 -1。
• 主实例收到连接诶请求后会回复 +FULLRESYNC {runID} {offset} ，告知从实例将进行全量同步，并提供主实例的 runID 和复制进度 offset，从服务器收到响应后，会记录这两个值。
• FULLRESYNC ：响应命令是采用全量复制的方式，主服务器会把所有的数据都同步给从服务器。

第二阶段：主库同步数据给从库

• 主实例执行 bgsave 命令，在后台生成 RDB 文件，这是对当前数据库状态的快照，然后把文件发送给从服务器。
• 主服务器生成 RDB 这个过程是不会阻塞主线程，Redis 依然可以正常处理命令，不会出现性能影响。
• 从实例接收到 RDB 文件后，先清空现有数据，然后加载 RDB 文件，将主实例的数据库状态同步过来。
• 在从实例加载文件的期间，主实例写操作命令记录的数据就不会同步，主从服务器间的数据就不一致了。
• 为了保证主从服务器的数据一致性，主服务器会将在 RDB 文件生成后收到的写操作命令，写入到 replication buffer 缓冲区。

第三阶段：主库发送新写命令给从库

• 主实例在生成 RDB 文件期间，新的写命令会被存储在 replication buffer 复制缓冲区中。
• 主实例将 replication buffer 中的写命令发送给从实例，从实例加载 replication buffer 中的写命令，以确保与主实例的数据最终一致。

至此，主从服务器的第一次同步的工作就完成了。

五、Redis 集群实现故障转移（哨兵模式）

Redis集群实现故障转移一般通过哨兵（Sentinel）机制，哨兵机制是来监控我们的 Redis 主从服务，当发现主从服务出现问题，比如主机下线了或宕机，它就会将其他的从机扶持成主机，达到系统正常运行的效果。一般而言，常用多个实例来组成 sentinel 哨兵集群来监视一组的一主多从或者是多组的一主多从。

哨兵模式遵循自己的选举机制和过半原则，只有当一半以上的 sentinel 认为某台机器出问题了，这个决议才会被通过，然后进行之后的操作。如果集群任意主节点挂掉，且当前主节点没有从节点，集群进入 fail 状态，如果集群超过半数以上主节点挂掉，无论是否有从节点，集群直接进入 fail 状态。

步骤如下图所示：图片是百度所查，如有侵权，请联系。

1、前期准备工作

• 配置主从复制：在每个Redis节点的配置文件 redis.conf 中设置节点角色和复制关系。例如有节点1（IP为 192.168.1.10 ），节点2、3、4（从节点）。
• 配置主节点配置文件中 replicaof no one 并设置密码等，从节点配置 replicaof 192.168.1.10 6379 指定主节点IP和端口。
• 配置 Sentinel 监控：在任意 Redis 节点创建 Sentinel 配置文件 sentinel.conf 。
• Sentinel 是一个特殊的 Redis 服务器，不会去进行持久化，Sentinel 实例启动后，每个 Sentinel 会创建2个连向主服务器的网络连接。
  • 命令连接：用于向主服务器发送命令，并接收响应。
  • 订阅连接：用于订阅主服务器的一个 sentinel:hello 频道。
• 获取主节点信息：Sentinel 默认每10秒一次，向被监控的主节点发送 info 命令，获取主节点和其下属从节点的信息。
• 获取从节点信息：当 Sentinel 发现主节点有新的从节点出现时，Sentinel 还会向从节点建立命令连接，当命令连接建立之后，Sentinel 还是会默认 10s 一次，向从节点发送 info 命令，并记录从节点的信息。
• sentinel monitor mymaster 192.168.1.10 6379 2 表示监控名为 mymaster 的主节点。
• sentinel auth - pass mymaster your_master_password 配置主节点密码。

2、故障检测

• 当 Sentinel 与主节点或从节点建立起订阅连接之后，Sentinel 就会通过订阅连接，向节点发送以下命令：subscribe —sentinel—:hello
• Sentinel 彼此之间只创建命令连接，而不创建订阅连接。通过订阅节点，就能感知到新的 Sentinel 的加入。
• 检测主观下线状态 SDOWN：
  • Sentinel 每2秒一次，向所有被监视的主节点和从节点所订阅的 sentinel：hello 频道上发送 PING 命令消息，消息会携带 Sentinel 自身的信息和主节点的信息，也会向其他 Sentinel 发送 PING 命令消息。
  • 当在 sentinel down - after - milliseconds mymaster 设置的毫秒时间内返回除了+PONG、-LOADING、-MASTERDOWN 的无效回复或者超时无回复，未收到主节点的 PONG 响应，单个 Sentinel 会先认为该主节点主观下线 SDOWN。
• 检查客观下线状态 ODOWN：
  • 当一个 Sentinel 将一个主节点判断为主观下线后，Sentinel 会向同时监控这个主节点的所有其他 Sentinel 发送查询命令。
  • 当同意主节点下线的 Sentinel 数量达到配置的最小选举数量，如上述配置中的2，则认为主节点客观下线 ODOWN 。

3、故障转移选举

• 在认定主节点客观下线后，Sentinel 会进行故障转移选举。它会将失效主节点中的一个从节点升级为新的主节点，并让失效主节点的其他从节点改为复制新的主节点。
• 当客户端试图连接失效的主节点时，集群也会向客户端返回新主节点的地址，集群使用新主节点替换失效主节点。
• 主节点和从节点切换后，主节点的 redis.conf 和从节点的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变。即从节点的配置文件中会有 replicaof 的配置，Sentinel 的监控目标也会调换。

4、选举规则

• 首先过滤掉主观下线的节点，先选举 Leader Sentinel ，当一个主节点被判定为客观下线后，监视这个主节点的所有 Sentinel 会通过选举算法 raft ，选出一个 Leader Sentinel 去执行 failover 故障转移操作。
• 先看优先级，选 优先级最高 的从节点，可在从节点配置slave - priority设置优先级，值越小优先级越高。
• 若优先级相同，会选择 复制偏移量最大（数据最完整）的从节点，复制偏移量越大则表示数据复制的越完整。
• 若仍相同，会根据节点的 runID 选择，因为 ID 越小说明重启次数越少。

5、更新从节点配置

• 新主节点选出后，Sentinel 会将新主节点信息更新到所有从节点的配置文件中，从节点配置文件中的 replicaof 配置会修改为新主节点的IP和端口。

6、重启从节点

• 从节点配置更新后，需重启每个从节点（执行redis - server redis.conf），使其连接到新的主节点，至此完成故障转移，集群恢复正常服务能力。

至此，完成了故障转移。

本文参考：
1、Redis三主三从集群搭建（三台机器）
2、浅谈：redis的主从复制 + 哨兵模式
3、Redis缓存哨兵机制的基本流程
4、Redis 主从复制