Redis集群之主从架构

Redis集群之主从架构

引用

CSDN

1.

https://blog.csdn.net/weixin_45476104/article/details/135049062

Redis主从架构是一种常见的高可用性解决方案，通过主从复制实现数据冗余和读写分离。本文将详细介绍Redis主从架构的优势、应用场景、搭建方法、数据同步原理以及常见拓扑结构，帮助读者全面了解这一重要的技术方案。

前言

什么是Redis集群? Redis集群是一种通过将多个Redis节点连接在一起以实现高可用性、数据分片和负载均衡的技术。它允许Redis在不同的服务器节点上同时提供服务，提高整体性能和可靠性。根据搭建的方式和集群的特性，Redis集群主要有三种模式：主从复制模式（Master-Slave）、哨兵模式（Sentinel）和Cluster模式。本文将首先介绍主从复制架构模式。

一、主从架构的优势及应用场景

Redis主从架构具有多个关键优势：

• 高可用性：通过故障转移机制，Redis主从架构提供了高可用性。如果主节点出现故障，可以快速切换到一个从节点，几乎没有停机时间。
• 读写分离：Redis主从架构允许从节点处理读操作，从而减轻了主节点的读负载，提高了整体性能。
• 数据冗余：从节点是主节点的复制，实现了数据的热备份，提供了数据冗余。即使主节点出现问题，数据仍然可用。也是持久化之外的一种数据冗余方式。
• 灵活性：可以根据需要扩展从节点，以处理更多的读请求，从而提高系统的扩展性。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

二、搭建主从架构

1.主从架构结构图

2.ip端口划分

本文将在云服务器开启三个不同的端口来模拟三台机器来模拟主从集群。如读者有充足的云服务器可以使用三台机器与redis默认6379端口来搭建主从集群。

云服务器ip端口分配如下:

3.配置文件修改

1. 创建目录 master_slave

[root@iZbp1a6rq18exzu6f75ghgZ redis_install]# ls
bin  etc  master_slave

• 在目录master_slave中创建文件 7001， 7002 7003

[root@iZbp1a6rq18exzu6f75ghgZ master_slave]# mkdir 7001 7002 7003

• 将redis.conf 分别拷贝到7001,7002,7003,中

[root@iZbp1a6rq18exzu6f75ghgZ 7001]# pwd
/soft/redis_install/master_slave/7001
[root@iZbp1a6rq18exzu6f75ghgZ 7001]# ls
dump.rdb  redis.conf

4.三个配置文件 分别修改默认启动端口7001,7002,7003

4.启动redis服务

• 为了方便观察主从同步日志开启三个shell终端，在三个终端分别执行

[root@iZbp1a6rq18exzu6f75ghgZ 7001]# redis-server ./redis.conf 
[root@iZbp1a6rq18exzu6f75ghgZ 7002]# redis-server ./redis.conf 
[root@iZbp1a6rq18exzu6f75ghgZ 7003]# redis-server ./redis.conf 

2. 开启主从关系

开启主从关系有两种方式

• 修改配置文件（永久生效）

在从节点的redis.conf中添加一行配置：slaveof

• 使用redis-cli客户端连接到redis服务，执行slaveof命令

注意：在5.0以后新增命令replicaof，与salveof效果一致,本文为了方便观察使用命令

#在从节点分别执行命令
[root@iZbp1a6rq18exzu6f75ghgZ ~]# redis-cli -p 7003
127.0.0.1:7003> SLAVEOF 127.0.0.1 7001 
[root@iZbp1a6rq18exzu6f75ghgZ ~]# redis-cli -p 7002
127.0.0.1:7002> SLAVEOF 127.0.0.1 7001 

3. 在客户端中测试命令

分别在主节点7001，7002客户端执行命令测试，可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作

4. 查看主节点从节点信息

三、主从数据同步原理

3.1 全量同步

⼀般⽤于初次复制场景,Redis 早期⽀持的复制功能只有全量复制,它会把主节点全部数据⼀次性发送给从节点,当数据量较⼤时,会对主从节点和⽹络造成很⼤的开销。

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

可以看到全量同步使用的是RDB的持久化模式，所以我们在搭建主从架构的时候要使用默认的RDB持久化模式。

这里有一个问题，master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据(replication id决定是否需要同步，offset决定怎样同步)。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

完整流程：

1.slave节点请求增量同步
2.master节点判断replid，发现不一致，拒绝增量同步
3.master将完整内存数据生成RDB，发送RDB到slave
4.lave清空本地数据，加载master的RDB
5.master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

3.2 部分复制

⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景,当从节点再次连上主节点后,如果条件允许,主节点会补发数据给从节点,因为补发的数据远⼩于全量数据,可以有效避免全量复制的过⾼开销

部分复制完整流程：

1.当主从节点之间网络出现中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并中断复制连接。
2.由于主节点没有宕机，所以他依然会响应客户端命令，但因复制连接中断命令无法发送给从节点，但主节点内部会将这段时间的命令保存在客户端缓冲区中，默认大小为 1MB。
3.当主从节点网络恢复后，从节点会再次连接上主节点。当主从节点连接恢复后，由于从节点之前保存了自身的偏移量和主节点的运行 id。因此会把它们当作 psync 参数发送给主节点，要求进行部分复制操作。
4.主节点接受从节点的 psync 命令，会先核对请求的 runid 是否和自身的的 runid 一致，如果一致，说明该从节点复制的当前主节点。然后查看请求的 offset 是否在复制积压缓冲区，如果在则进行部分复制，否则进行全量复制，部分复制回复 +continue 响应，从节点接受回复
5.在进行部分复制时，主节点只需要根据 offset 将复制积压缓冲区的数据发送给从节点，保证主从复制进入正常状态

3.3 复制积压缓冲区

复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列,默认⼤⼩为 1MB,当主节点有连接的从节 点（slave）时被创建,这时主节点（master）响应写命令时,不但会把命令发送给从节点,还会写⼊ 复制积压缓冲区

由于缓冲区本质上是先进先出的定⻓队列,所以能实现保存最近已复制数据的功能,⽤于部分复制和 复制命令丢失的数据补救,如果当前从节点需要的数据, 已经超出了主节点的积压缓冲区的范围, 则⽆法进⾏部分复制, 只能全量复制了.

3.4 实时复制

主从节点在建⽴复制连接后,主节点会把⾃⼰收到的 修改操作 ,通过 tcp ⻓连接的⽅式,源源不断的传输给从节点,从节点就会根据这些请求来同时修改⾃⾝的数据,从⽽保持和主节点数据的⼀致性.另外,这样的⻓连接,需要通过⼼跳包的⽅式来维护连接状态. (这⾥的⼼跳是指应⽤层⾃⼰实现的⼼跳, ⽽不是 TCP ⾃带的⼼跳).

实时复制流程：

1.主从节点彼此都有⼼跳检测机制,各⾃模拟成对⽅的客⼾端进⾏通信
2.主节点默认每隔 10 秒对从节点发送 ping 命令,判断从节点的存活性和连接状态
3.从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令,给主节点上报⾃⾝当前的复制偏移量

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值（默认 60 秒),则判定从节点下线,断开复制客⼾端连接,从节点恢复连接后,⼼跳机制继续进⾏.

四、常见主从架构拓扑图

4.1 一主一从结构

一主一从结构是最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移支持。

优点： 很大程度上解决了读命令并发量较高的情况,当写命令并发量较高且需要持久化时,可以只在从节点上开启AOF(这样写IO的操作都交给了从节点,减少了主节点写命令的并发量),这样既可以保证数据安全性的同时也避免了持久化对主节点的性能干扰

缺点： 主节点一旦挂了,不能让它自动重启,如果自动重启,需要恢复数据,此时没有AOF文件,主节点就会默认丢失了数据,从节点进行复制操作也会把从节点的数据给删除了.

4.2 一主多从结构

一主多从结构(星形结构)使得应用端可以利用多个从节点实现读写分离(实际开发中,往往读请求远远超过写请求),增加从节点可以降低读请求的并发量,如图所示:

优点: 一主多从结构对于读比较大的场景,可以把读命令负载均衡到不同的从节点上来分担压力,同时一些耗时的读命令可以指定一台专门的从节点执行,避免破坏整体的稳定性

缺点： 对于写并发量较高的场景,多个从节点会导致主节点写命令的多次发送从而加重主节点的负载,随着从节点个数的增加,同步一条数据就需要传输很多次.

4.3 树形主从结构

树形主从结构(分层结构)使得从节点不但可以复制主节点数据,同时可以作为其他从节点的主节点继续向下层复制,通过引入复制中间层,可以有效降低系统按负载和需要传送给从节点的数据量

优点： 数据写⼊主节点 master之后会同步给 从节点和 slave_1 ,slave_2,slave_3。从节点slave_1进⼀步把数据同步给 slave_12 和 slave_13 节点,从节点slave_3进⼀步把数据同步给 slave_31 和 slave_32 节点,当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰,可以采⽤这种拓扑结构,主节点就不需要那么高的网络带宽了。

缺点:一旦数据进行修改,同步延时会更久.

总结

本文主要讲解了主从复制之间的复制原理，分为：全量复制和部分复制。Master 区分是全量复制还是部分复制，依靠的是 runid 与 offset 参数。第一次复制，则进行全量复制，Master 生成 RDB 文件。Slave 断线重连后，Master 依据 offset 在复制积压缓冲区中选择传输的起始字节进行部分复制。如果找不到则进行全量复制。