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

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

文章目录

- 一、简单介绍什么是 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主从复制

如上图所示：我们跟着步骤来了解主从复制的原理：这张图展示了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 状态。

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

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、更新从节点配置