Redis主从架构搭建以及主从复制原理

每天多学一点点~
话不多说，这就开始吧…

文章目录

Redis主从架构搭建以及主从复制原理
- 1.前言
- 2.Redis集群方案比较
- 3.Redis伪主从搭建(1主2从)
- 4.Redis主从复制原理
- 5.结语

1.前言

博主最早接触的是redis高可用集群(linux+windows)，因为当时在国网，有充足的硬件支持，也写过搭建博文，但并不是所有公司都有那么多服务器，最近有时间重新整理一下redis的三种集群模式~今天先搭建redis主从架构

Redis系列文章

Redis的持久化方式和缓存淘汰策略
Redis哨兵高可用架构搭建+springboot整合
Redis高可用集群(搭建+水平扩容缩容+原理+java代码整合)
浅谈Redis分布式锁(Redisson)

2.Redis集群方案比较

主从模式

最初的redis架构模式，主写从读，为了防止服务器挂了(硬盘坏了)的情况下数据丢失，且不存在选举，若主服务器挂了，必须重写启动从服务器，改其配置让其成为主(当然可以写脚本，虽然现在基本上不怎么用了)，但是其主从之间的复制原理还是很重要的，后文会介绍。
哨兵模式
在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率
高可用集群

Redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

3.Redis伪主从搭建(1主2从)

搭建方式和真正主从一模一样，只是放在了一台虚拟机上而已，且只有一个redis-server而已。
192.168.73.130:6380(主) 192.168.73.130:6381(从) 192.168.73.130:6382(从)
建立三个文件夹 6380 6381 6382，将redis.conf文件复制到其中

修改一下配置(对应到各个端口)

port 6380 # redis端口
daemonize yes #后台启动
bind 0.0.0.0 #让其他ip的客户端可以连接(不然本机连不上虚拟机)
pidfile /var/run/redis_6380.pid #redis进程文件id
logfile “6380.log” #redis日志文件
dir /usr/local/redis5.0.2/zhucong/data/6380 # redis日志文件目录
在两个从节点redis.conf文件上配置主从复制

replicaof 192.168.73.130 6380 # 从本机6380的redis实例复制数据
replica-read-only yes # 让从节点只读
启动节点(以配置文件形式启动)
先启动主节点

src/redis-server /usr/local/redis5.0.2/zhucong/6380/redis.conf

在这里插入图片描述
再启动从节点

src/redis-server /usr/local/redis5.0.2/zhucong/6381/redis.conf   #6381
src/redis-server /usr/local/redis5.0.2/zhucong/6382/redis.conf   #6382

在这里插入图片描述
查看主从架构信息

info replication #

在这里插入图片描述
测试主从是否搭建成功

在6380(主)上写数据，看是否同步到从节点

redis-cli -p 6380 #连接redis
set name zjq #设置
redis-cli -p 6381
scan 0 match * count 10 #用游标查找

在这里插入图片描述

在从上写数据，看是否拒绝

主从架构搭建成功(主写，从读)

4.Redis主从复制原理

如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个SYNC命令(redis2.8版本之前的命令)给master请求复制数据。
master收到SYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间， master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，master和slave断开重连后支持部分复制。

数据部分复制

从2.8版本开始，slave与master能够在网络连接断开重连后只进行部分数据复制。 master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的 slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master 继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。从2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据
主从复制(全量复制)流程图：

主从复制(部分复制)流程图：