Redis集群介绍及测试思路

r囧r小猫 2023-09-25 22:16 126阅读 0赞

## Redis集群介绍 ##

Redis集群一般有四种方式，分别为：主从复制、哨兵模式、Cluster以及各大厂的集群方案。在3.0版本之前只支持单实例模式，3.0之后支持了集群方式。在3.0之前各大厂为了解决单实例Redis的存储瓶颈问题各自推出了自己的集群方案，其核心思想就是数据分片，主要有客户端分片、代理分片、服务端分片。这里咱们只介绍前三种方式：主从、哨兵、Cluster。

### 1、主从复制 ###

Redis单节点的数据是存储在一台服务器上的，如果服务器出现故障，会导致数据不可用，而且读写都是在同一台服务器上，请求量大时会出现I/O瓶颈。为了避免单点故障和读写不分离，Redis提供了复制功能来实现Master中的数据向Slave数据库的同步。Master可以有多个Slave节点，Slave节点也可以有Slave节点，从节点是级联结构，如下图所示：

![format_png][]

#### 主从复制工作原理 ####

一般情况下为了让数据读写分离，Master节点用来执行写操作，Slave节点提供读操作，Master执行写操作时将变化的数据同步到Slave，其工作原理如下图所示：

![format_png 1][]

Redis主从复制基本原理有三种：全量复制、基于长连接的命令传播、增量复制。

首先介绍一下全量复制，当主从服务器刚建立连接的时候，会按照三个阶段完成数据的第一次同步。假设现在有实例1（192.168.1.1）和实例2（192.168.1.2），当我们在实例2上执行“replicaof 192.168.1.1 6379”命令后，实例2就变成了实例1的从库，并开始从实例1上复制数据，有如下三个阶段：

![format_png 2][]

**第一个阶段**，是主从库之间建立连接、协商同步的过程，为全量复制做准备。具体来说，从库给主库发送psync命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync命令包含了主库的runID和复制进度offset两个参数。

•runID：是每个Redis实例启动时自动生成的一个随机ID，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的runID，所以将runID设置为“？”。

•offset：设置为-1，表示第一次复制。

主库收到psync命令后，会用FULLRESYNC响应命令带上两个参数：主库runID和主库目前的复制进度offset，返回给从库，从库收到响应后会记录下这两个参数。FULLRESYNC响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。

**第二个阶段**，主库将所有数据同步给从库，从库收到数据后，首先清空现有数据，然后在本地完成数据加载。这个过程依赖于内存快照生成的RDB文件。具体来说，主库执行bgsave命令，生成RDB文件，接着将文件发给从库。

**第三个阶段**，主库会把第二阶段执行过程中新接收到的写命令，再发送给从库。具体来说，当主库完成RDB文件发送后，就会把此时replication buffer中的修改和新增操作发给从库，从库再重新执行这些操作。这样一来，主从库就实现同步了。

以上是全量复制的基本流程，一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为**基于长连接的命令传播**，可以避免频繁建立连接的开销。

长连接是基于网络的，那么它就存在网络断开的风险，在Redis2.8之前，如果主从库在命令传播时出现了网络闪断，那么从库会和主库重新进行一次全量复制，开销非常大。在Redis2.8开始，网络闪断之后，主从库会采用**增量复制**的方式继续同步，就只会把主从网络断连期间主库收到的命令同步给从库。

增量复制核心在于repl\_backlog\_buffer这个缓冲区。当主从库断连后，主库会把断连期间收到的写操作命令写入replication buffer，同时也会写入repl\_backlog\_buffer这个缓冲区。repl\_backlog\_buffer是一个环形缓冲区，主库记录自己写到的位置，从库也记录自己读到的位置。主从连接恢复之后，从库首先给主库发送psync命令，并把自己当前的slave\_repl\_offset发给主库，主库会判断自己的master\_repl\_offset和slave\_repl\_offset之间的差距，一般来说master\_repl\_offset会大于slave\_repl\_offset。此时，主库只用把master\_repl\_offset和slave\_repl\_offset之间的命令操作同步给从库就行。

### 2、哨兵模式 ###

> sentinel，中文名哨兵。Redis的sentinel系统用于管理多个Redis实例，该系统主要执行以下四个任务：

1.监控（Monitoring）：Sentinel会不断的检查主服务器和从服务器是否正常运作。

2.自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

3.通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

4.配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

哨兵用于实现Redis集群的高可用性，本身也是分布式的，作为一个哨兵集群去运行。Sentinel的进程之间使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。下面分别介绍一下监控和自动故障转移的基本原理：

#### Sentinel集群监控原理 ####

[format_png]: https://img-blog.csdnimg.cn/img_convert/29194230c1f20adb2b33af778b79ef3b.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/48d5b239847a916e3f39569f3cfa4ad4.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/48df9b09efa52b1cf1d985d75c112ba6.webp?x-oss-process=image/format,png