5.进阶篇：Redis 主从架构

WaterBear • 2021年12月11日 am11:24 • Redis, 订阅专题

Redis主从复制原理与实战

Redis主从复制以及拓扑

redis支持简单并且易操作的主从复制功能，可以把从库看做是主库的镜像，数据同步基于秒级的同步。

redis 从2.8 版本之后从服务器会每秒一次频率向主库报告复制流的处理进度，相当于秒级的汇报，每秒都要告诉领导，我在做什么，到什么进度了。

一个主服务器可以有多个从服务器，同时不仅master可以有从库，从服务器也可以有自己的从库。可以参考一般单位的金字塔式的组织架构图。

我们可以根据我们实际的应用场景，或者备份需求等，来制定更符合我的架构拓扑。以上仅讲解使用，实际环境中几乎没有人使用多级的这种复制模式。

在主从复制过程中，对于master和slave来讲都不会被阻塞。首先master同步到一个或者多个slave的时候，master也可以正常的处理请求。slave在同步的过程中，也可以先使用旧的同步数据，完成读请求。在同步新数据和旧数据进行替换的瞬间是会有连接被阻塞的。

主从复制的场景

1.读写分离

首先clien 可以是一个支持读写分离的代理，比如twemproxy 或者程序直接写的读写分离，这样的话可以提高我们可扩展性，使访问速度更快。

2.提高主库性能

参照读写分离的图片，我们也可以把读写都放在master上，但是master作为纯内存操作，这样master的速度会更快，那我们数据持久化怎么来呢，我们可以把AOF文件或者RDB文件放在我们的slave上。不会影响到主库的性能。

3.增加安全性

增加数据的安全性，原理同第二条差不多，我们可以在从库上开启aof或者RDB也可以同时开启，来保证我们的数据完整性，并且定期的异地备份。这也算一个优点。

4.其他场景大家可以多思考一下。看看自己的架构或者应用，适用哪种，或者有更好的拓展模式。

主从复制原理

在从库配置完成启动之后，不管是第一次同步还是重新同步，slave 都会发送一个sync的命令给master 。master接受到请求之后执行bgsave的操作，保存一个rdb文件。

在保存期间，所有的数据修改操作，master都会保存在一个缓冲区内。

首先不论一个或者多个slave来请求，master都可以使用这个rdb文件发送给slave，slave接收到rdb文件之后，将文件内的数据加载到内存中。

完成之后，master会把缓冲区的写入操作通过redis命令协议的方式，全部发送个slave。这样的话，slave就可以拥有一份和master一样的数据。

部分同步与全量同步

首次进行主从配置的时候，假如主库有数据的话，一定会进行全量的同步。

在同步期间出现主从短暂的网络断开，是可以实现部分同步的，就是原来有的数据可以不同步。原理如下：

master需要为将要被发送的复制流创建一个内存缓冲区，同时记录下复制偏移量和master的run id （和MySQL的指针偏移量同理），网络断开后，slave重连之后，向master发送请求，如果指针偏移量之后的数据，都在缓冲区内，则执行部分同步，从偏移量开始。

由于缓冲区有大小限制，如果缓冲区超出了这段时间的偏移量，这个时候必须要进行全量同步。

主从配置与实战

master  192.168.188.191 6379
slave   192.168.188.190 6379

1.配置文件

我们可以通过配置文件修改，配置上 slaveof 192.168.188.191 6379 master的地址和端口，重启后生效，进行同步。

2.命令配置

可以通过登录之后，使用 slaveof 192.168.188.191 6379 来完成配置。但是重启之后这个配置就失效了。强烈建议配置文件配置。

192.168.188.190:6379> slaveof 192.168.188.191 6379
OK
192.168.188.190:6379> info Replication  查看主从信息
# Replication
role:slave                             #当前角色
master_host:192.168.188.191            #master地址
master_port:6379                       #master端口
master_link_status:down                #同步状态
master_last_io_seconds_ago:-1          #同步时间差
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1552116210
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

可以通过下图的master的日志看到同步的状态，什么时候开始同步的，什么时候同步完成的。大家可以多验证一下。