05_Redis之集群

news/2025/4/1 19:29:57/文章来源:https://www.cnblogs.com/Invinc-Z/p/18800973

05_Redis之集群

现实中的项目通常需要若干台Redis服务器的支持：
（1）从结构上，单个 Redis 服务器会发生单点故障，同时一台服务器需要承受所有的请求负载。这就需要为数据生成多个副本并分配在不同的服务器上；
（2）从容量上，单个 Redis 服务器的内存非常容易成为存储瓶颈，所以需要进行数据分片。同时拥有多个 Redis 服务器后就会面临如何管理集群的问题，包括如何增加节点、故障恢复等操作。
为此，本文将依次介绍 Redis 中的复制、哨兵（sentinel）和集群（cluster）的使用和原理。

一、主从复制

redis 主从复制特点

master 可以拥有多个slave

多个slave 可以连接同一个master 外，还可以连接到其他slave

主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求

提高系统的伸缩性

redis 主从复制原理

当从数据库配置为复制主数据库时，它会主动向主数据库发送 PSYNC 命令，请求同步数据。无论是第一次连接还是重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，同时master 主进程会开始收集新的写命令并缓存。后台进程完成写文件后，master 就发送文件给slave，slave将文件保存到硬盘上，再加载到内存中，接着master 就会把缓存的命令转发给slave，后续master 将收到的写命令发送给slave。如果master 同时收到多个slave 发来的同步连接命令，master 只会启动一个进程来写数据库镜像，然后发送给所有的slave。

同步命令的触发

从数据库连接到主数据库后，自动发送：

PSYNC <replication-id> <offset>

参数说明：
- <replication-id>：主数据库的复制 ID（唯一标识数据集版本）。
- <offset>：从数据库当前的复制偏移量（用于判断是否需要全量同步）。

`PSYNC` 的作用

全量同步（Full Sync）：
如果从数据库首次连接或数据差异过大，主数据库会生成 RDB 快照发送给从数据库，完成全量同步。
部分同步（Partial Sync）：
如果主从数据库的复制 ID 一致且偏移量在缓冲区范围内，主数据库仅发送缺失的增量命令，减少数据传输量。

主数据库的响应

主数据库根据 PSYNC 请求返回以下结果之一：

+FULLRESYNC <replication-id> <offset>：
表示触发全量同步，从数据库需接收 RDB 文件并加载数据。
+CONTINUE：
表示触发部分同步，从数据库直接接收增量命令。

全量同步后，主数据库持续发送增量命令（通过 REPLCONF ACK 机制保持实时同步）。

关键注意事项

版本兼容性：
- Redis 2.8+ 支持 PSYNC，旧版本仅支持 SYNC（强制全量同步）。
- 确保主从数据库版本兼容（建议使用 Redis 5.0+）。
复制缓冲区（Replication Buffer）：
主数据库会缓存最近的写命令（默认 1MB），用于支持部分同步。可通过 client-output-buffer-limit 调整。
网络中断处理：
若主从连接中断后恢复，从数据库会重新发送 PSYNC，尝试增量同步。

配置步骤

在 /etc/redis下面，将 6379.conf 文件拷贝两份，分别叫做6380.conf与 6381.conf
将 6380.conf 与 6381.conf 文件下面的如下配置进行修改:

port 6380     port 6381
pidfile "/run/redis_6380.pid"  pidfile "/run/redis_6381.pid"
logfile "/var/log/redis_6380.log"  logfile "/var/log/redis_6381.log"
dbfilename "dump_6380.rdb" dbfilename "dump_6381.rdb"
appendfilename "appendonly_6380.aof"  appendfilename "appendonly_6381.aof"
replicaof 127.0.0.1 6379    replicaof 127.0.0.1 6379

从节点开启主从复制，有3种方式：

（1）配置文件

在从服务器的配置文件中加入：replicaof <masterip> <masterport>

（2）启动命令

redis-server启动命令后面加入 --replicaof <masterip> <masterport>

（3）客户端命令

Redis服务器启动后，直接通过客户端执行命令：replicaof <masterip> <masterport>，则该Redis实例成为从节点。

如果该数据库已经是其他主数据库的从数据库了，replicaof命令会停止和原来数据库的同步转而和新数据库同步。此外对于从数据库来说，还可以使用 replicaof no one命令来使当前数据库停止接收其他数据库的同步并转换成为主数据库

启动上述三个配置文件

sudo redis-server /etc/redis/6379.conf
sudo redis-server /etc/redis/6380.conf
sudo redis-server /etc/redis/6381.conf

进入到对应服务器的客户端

redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381

接下来查看主从复制的信息info replication，每个机器都是属于主机

二、哨兵模式

什么是哨兵？

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

监控主数据库和从数据库是否正常运行。
主数据库出现故障时自动将从数据库转换为主数据库。

哨兵是一个独立的进程，使用哨兵的一个典型架构如图所示。

在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健，如图所示。注意，此时不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监控。

如何配置

建立一个配置文件，如 sentinel.conf，内容为：sentinel monitor mymaster 127.0.0.1 6379 1
其中 mymaster 表示要监控的主数据库的名字，可以自己定义一个。这个名字必须仅由大小写字母、数字和“.-_”这 3 个字符组成。后两个参数表示主数据库的地址和端口号，这里我们要监控的是主数据库6379。最后的1表示最低通过票数。接下来执行来启动Sentinel进程，并将上述配置文件的路径传递给哨兵：
redis-sentinel /path/to/sentinel.conf
需要注意的是，配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。

实现原理

一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：

sentinel monitor master-name ip redis-port quorum

其中 master-name 是一个由大小写字母、数字和“.-_”组成的主数据库的名字，因为考虑到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号。

ip 表示当前系统中主数据库的地址，而 redis-port则表示端口号。quorum 用来表示执行故障恢复操作前至少需要几个哨兵节点同意。

一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个sentinel monitor配置即可，例如：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel monitor othermaster 192.168.1.3 6380 4

同时多个哨兵节点也可以同时监控同一个 Redis 主从系统，从而形成网状结构。

哨兵启动后，会与要监控的主数据库建立两条连接，这两个连接的建立方式与普通的Redis客户端无异。其中一条连接用来订阅该主数据的__sentinel__:hello频道以获取其他同样监控该数据库的哨兵节点的信息，另外哨兵也需要定期向主数据库发送 INFO 等命令来获取主数据库本身的信息，因为当客户端的连接进入订阅模式时就不能再执行其他命令了，所以这时哨兵会使用另外一条连接来发送这些命令。

和主数据库的连接建立完成后，哨兵会定时执行下面3个操作。

（1）每10秒哨兵会向主数据库和从数据库发送INFO命令。

（2）每 2 秒哨兵会向主数据库和从数据库的__sentinel__:hello 频道发送自己的信息。

（3）每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。

这3个操作贯穿哨兵进程的整个生命周期中，非常重要。

首先，发送INFO命令使得哨兵可以获得当前数据库的相关信息（包括运行ID、复制信息等）从而实现新节点的自动发现。前面说配置哨兵监控 Redis 主从系统时只需要指定主数据库的信息即可，因为哨兵正是借助 INFO 命令来获取所有复制该主数据库的从数据库信息的。启动后，哨兵向主数据库发送 INFO 命令，通过解析返回结果来得知从数据库列表，而后对每个从数据库同样建立两个连接，两个连接的作用和前文介绍的与主数据库建立的两个连接完全一致。在此之后，哨兵会每 10 秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据库的角色变化（由故障恢复操作引起）进行信息更新等。

接下来哨兵向主从数据库的 __sentinel__:hello 频道发送信息来与同样监控该数据库的哨兵分享自己的信息。发送的消息内容为：

<哨兵的地址>, <哨兵的端口>, <哨兵的运行 ID>, <哨兵的配置版本>, <主数据库的名字, <主数据库的地址>, <主数据库的端口>, <主数据库的配置版本>

前文介绍过，哨兵会订阅每个其监控的数据库的 __sentinel__:hello 频道，所以当其他哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。如果是则将其加入已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送 PING命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其他哨兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版本高，则更新主数据库的数据。

实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。这是通过每隔一定时间向这些节点发送PING命令实现的。时间间隔与down-after-milliseconds选项有关，当down-after-milliseconds的值小于1秒时，哨兵会每隔down-after-milliseconds指定的时间发送一次PING命令，当down-after-milliseconds的值大于1秒时，哨兵会每隔1秒发送一次PING命令。

当超过down-after-milliseconds选项指定时间后，如果被PING的数据库或节点仍然未进行回复，则哨兵认为其主观下线（subjectively down）。主观下线表示从当前的哨兵进程看来，该节点已经下线。如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送 SENTINEL is-master-down-by -addr 命令询问其他哨兵节点以了解他们是否也认为该主数据库主观下线，如果达到指定数量时，哨兵会认为其客观下线（objectively down），并选举领头的哨兵节点对主从系统发起故障恢复。这个指定数量即为 quorum 参数。例如，下面的配置：

sentinel monitor my master 127.0.0.1 6379 2

该配置表示只有当至少两个 Sentinel 节点（包括当前节点）认为该主数据库主观下线时，当前哨兵节点才会认为该主数据库客观下线。进行接下来的选举领头哨兵步骤。

虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要由领头的哨兵来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了 Raft 算法，具体过程如下。

（1）发现主数据库客观下线的哨兵节点（下面称作A）向每个哨兵节点发送命令，要求对方选自己成为领头哨兵。

（2）如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。

（3）如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A成功成为领头哨兵。

（4）当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

因为要成为领头哨兵必须有超过半数的哨兵节点支持，所以每次选举最多只会选出一个领头哨兵。选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。故障恢复的过程相对简单，具体如下。

首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。挑选的依据如下。

（1）所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过 replica-priority 选项来设置。

（2）如果有多个最高优先级的从数据库，则复制的命令偏移量越大（即复制越完整）越优先。

（3）如果以上条件都一样，则选择运行ID较小的从数据库。选出一个从数据库后，领头哨兵将向从数据库发送 replicaof no one命令使其升格为主数据库。而后领头哨兵向其他从数据库发送 replicaof <hostname> <port>命令来使其成为新主数据库的从数据库。最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。

部署

哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏与否取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能会发生单点故障。整体来讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致，即：

（1）为每个节点（无论是主数据库还是从数据库）部署一个哨兵；

（2）使每个哨兵与其对应的节点的网络环境相同或相近。

这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举例一个例子：当网络分区后，如果哨兵认为某个分区是主要分区，即意味着从每个节点观察，该分区均为主分区。同时设置 quorum 的值为 N/2 + 1（其中 N 为哨兵节点数量），这样使得只有当大部分哨兵节点同意后才会进行故障恢复。当系统中的节点较多时，考虑到每个哨兵都会和系统中的所有节点建立连接，为每个节点分配一个哨兵会产生较多连接，尤其是当进行客户端分片时使用多个哨兵节点监控多个主数据库会因为 Redis 不支持连接复用而产生大量冗余连接，同时如果Redis节点负载较高，会在一定程度上影响其对哨兵的回复以及与其同机的哨兵与其他节点的通信。所以配置哨兵时还需要根据实际的生产环境情况进行选择。