Redis学习笔记(八)：redis主从复制-建立连接、数据同步、命令传播、复制缓冲区、复制偏移量、心跳机制

川长思鸟来 2023-02-18 08:07 11阅读 0赞

> **Redis学习笔记系列**
> 
>  *  [Redis学习笔记(一)：下载与安装-Windows、Linux][Redis_-Windows_Linux]
>  *  [Redis学习笔记(二)：数据类型和通用操作命令][Redis]
>  *  [Redis学习笔记(三)：Java连接Redis(Jedis)以及示例代码][Redis_Java_Redis_Jedis]
>  *  [Redis学习笔记(四)：Redis持久化][Redis_Redis]
>  *  [Redis学习笔记(五)：Redis事务-multi、exec、discard、锁、分布式锁、死锁][Redis_Redis_-multi_exec_discard]
>  *  [Redis学习笔记(六)：删除策略、逐出算法][Redis 1]
>  *  [Redis学习笔记(七)：redis高级数据类型及应用场景-Bitmaps、HyperLogLog、GEO][Redis_redis_-Bitmaps_HyperLogLog_GEO]
>  *  [Redis学习笔记(八)：redis主从复制-建立连接、数据同步、命令传播、复制缓冲区、复制偏移量、心跳机制][Redis_redis_-]
>  *  [Redis学习笔记(九)：哨兵模式-监控、通知、故障转移][Redis_-]
>  *  [Redis学习笔记(十)：Redis集群-结构设计、集群搭建、集群操作、主从下线、主从切换][Redis_Redis_-]
>  *  [Redis学习笔记(十一)：企业级解决方案-缓存预热、缓存雪崩、缓存击穿、缓存穿透、性能指标监控][Redis_- 1]

# 简介 #

>   互联网的”三高“架构：**高并发、高性能、高可用**。而redis本身是单线程单机的(redis-6.0以后支持多线程)，单机具有不稳定，不可靠的特点，极具风险，如果出现机器故障、容量达到瓶颈等等时，都可能会导致数据丢失，甚至对业务造成灾难性打击。为了避免单机redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使其中有一台服务器宕机，其它服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据的冗余备份。

### 多台服务器连接方案 ###

主从复制：将master中的数据即时、有效地复制到slave中

*  提供数据方：master(负责写数据，执行写操作时，将出现变化的数据自动同步到slave)  
      \* 主服务器、主节点、主库  
      \* 主客户端
 *  接收数据方：slave(负责读数据)  
      \* 从服务器、从节点、从库  
      \* 从客户端
 *  需要解决的问题：数据同步
 *  核心工作：master的数据复制到slave中  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70]

### 主从复制的作用 ###

>  *  读写分离：master写，slave读，提高服务器的读写负载能力
>  *  负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过对多个从节点分担数据读取负载，大大提高redis服务器并发量与数据吞吐量
>  *  故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
>  *  数据冗余：实现数据热备份，是持久化之外的一种数据冗余备份方式

# 主从复制工作流程 #

主从复制过程大体分为3个阶段

> 1.  建立连接阶段
> 2.  数据同步阶段
> 3.  命令传播阶段

### 1.建立连接阶段 ###

1.  设置master的地址和端口，保存master信息
2.  建立socket连接
3.  发送ping命令(定时任务)
4.  身份验证
5.  发送slave端口信息  
    至此，主从连接成功，实现最终的目的：

*  slave保存了master的地址和端口
 *  master保存了slave的端口
 *  二者之间创建了连接的socket  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 1]

> **主从连接(slave连接master)**
> 
>  *  方式一：客户端发送命令
> 
> > `slaveof <masterip> <masterport>`
> 
>  *  方式二：启动服务器参数
> 
> > `redis-server --slaveof <masterip> <masterport>`
> 
>  *  方式三：服务器配置
> 
> > `slaveof <masterip> <masterport>`

*  **在master中查看slave连接信息**
 *  命令： `info`  
    ![在这里插入图片描述][20200616155333336.png]

> **主从连接断开**
> 
>  *  客户端发送命令 `slaveof no one`

> **授权访问**
> 
>  *  master配置文件设置密码
> 
> > `requirepass <password>`
> 
>  *  master客户端发送命令设置密码
> 
> > `config set requirepass <password>`  
> > `config get requirepass`
> 
>  *  slave客户端发送命令设置密码
> 
> > `auth <password>`
> 
>  *  slave配置文件设置密码
> 
> > `masterauth <password>`
> 
>  *  启动客户端设置密码
> 
> > `redis-cli -a <password>`

### 2.数据同步阶段 ###

>  *  在slave初次连接master后，复制master中的所有数据到slave
>  *  将slave的数据库状态更新成master当前的数据库状态

1.  请求同步数据
2.  创建RDB同步数据
3.  恢复RDB同步数据
4.  请求部分缓冲区同步数据
5.  恢复部分缓冲区同步数据  
    至此，数据同步工作完成，实现最终目的：

*  slave具有master端全部数据，包含RDB过程接收的数据
 *  master保存slave当前数据同步的位置
 *  完成数据的克隆  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 2]
 *  **注意事项**
 *  **master：**

> 1.  如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
> 2.  复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。需要在master修改缓冲区的大小 `repl-backlog-size 1mb`
> 3.  master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

*  **slave：**

> 1.  为避免slave进行全量复制/部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务 `slave-server-stale-data yes|no`
> 2.  数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令
> 3.  多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽不足，因此数据同步需要根据业务需求，适量错峰
> 4.  slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层的master间数据同步延迟较大，数据一致性变差，应谨慎选择。

### 3.命令传播阶段 ###

>  *  当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致状态，同步的动作称为命令传播
>  *  master将接收到的数据变更命令发送给slave，slave接收命令后执行命令

*  命令传播阶段出现了断网现象

>  *  网络闪断闪连 — 忽略
>  *  短时间网络中断 — 部分复制
>  *  长时间网络中断 — 全量复制

*  部分复制的三个核心要素

> 1.  服务器的运行id(run id)
> 2.  主服务器的复制积压缓冲区
> 3.  主从服务器的复制偏移量

##### 服务器运行id(run id) #####

*  概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
 *  组成：运行id由40位字符组成，是一个随机的十六进制字符
 *  作用：运行id被用于在服务器进行传输，识别身份，如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别
 *  实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行id发送给slave，slave保存此ID，通过info server命令，可以查看节点的run id。

##### 复制积压缓冲区 #####

*  概念：复制积压缓冲区，又名复制缓冲区，是一个先进先出(FIFO)的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区。复制缓冲区默认数据存储空间大小是1M，由于存储空间大小是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
 *  由来：每台服务器启动时，如果开启有AOF或被连接成master节点，即创建复制缓冲区
 *  作用：用于保存master收到的所有指令(仅影响数据变更的指令，例如:set，select)
 *  数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到复制缓冲区中
 *  组成：偏移量、字节值
 *  工作原理：1. 通过offset区分不同的slave当前数据传播的差异 2. master记录已发送的信息对应的offset 3.slave记录已接收的信息对应的offset  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 3]

##### 复制偏移量 #####

*  概念：一个数字，描述复制缓冲区中的指令字节位置
 *  分类：

>  *  master复制偏移量：记录发送给所有slave的指令字节对应的位置(多个)
>  *  slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置(一个)

*  数据来源：

>  *  master端：发送一次记录一次
>  *  salve端：接收一次记录一次

*  作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用

## 数据同步+命令传播阶段详解 ##

### 数据同步 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 4]

### 命令传播 ###

即上面图片中：期间会不停地接收客户端命令，offset发生变化

##### 心跳机制 #####

*  简介

>  *  进入命令传播阶段后，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
>  *  master心跳：
> 
> >  *  指令：PING
> >  *  周期：由repl-ping-slave-period决定，默认10秒
> >  *  作用：判断slave是否在线
> >  *  查询：`info replication` 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
> 
>  *  slave心跳：
> 
> >  *  指令：REPLCONF ACK \{offset\}
> >  *  周期：1秒
> >  *  作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
> >  *  作用2：判断master是否在线

*  注意事项

>  *  当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作
> 
>     min-slaves-to-write 2 
>     min-slaves-max-lag 10
> 
> slave数量少于2个，或者所有slave的延迟都大于等于10秒时，强制关闭master的写功能，停止数据同步
> 
>  *  slave数量由slave发生REPLCONF ACK 命令做确认
>  *  slave延迟由slave发生REPLCONF ACK 命令做确认

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 5]

# 主从复制常见问题 #

*  频繁的全量复制(1)

> 伴随着系统的运行，master的数据量会越来越大，一旦master重启，runid将会发生改变，会导致全部slave的全量复制操作  
> 内部优化调整方案：
> 
> 1.  master内部创建master\_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave
> 2.  在master关闭时执行命令 shutdown save，进行RDB持久化，将runid与offset保存到RDB文件中
> 
>  *  repl-id repl-offset
>  *  通过redis-check-rdb命令可以查看该信息
> 
> 1.  master重启后加载RDB文件，恢复数据。重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中
> 
>  *  master-repl-id = repl master-repl-offset = repl-offset
>  *  通过info命令可以查看该信息
> 
> 1.  本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master

*  频繁的全量复制(2)

> 当网络环境不佳，出现网络中断，slave不提供服务，原因是复制缓冲区过小，断网后slave的offset越界，触发全量复制，这个过程会导致死循环，slave反复进行全量复制，这个时候需要修改一下复制缓冲区的大小 `repl-backlog-size`，那么设置多大才算比较合理？
> 
> 1.  测算从master到slave的重连平均时长second
> 2.  获取master平均每秒产生写命令数据总量write\_size\_per\_second
> 3.  最优复制缓冲区空间 = 2 \* second \* write\_size\_per\_second

*  频繁的网络中断(1)

>  *  问题现象  
>        master的CPU占用过高 或 slave频繁断开连接
>  *  问题原因  
>        1. slave每秒发送REPLCONF ACK命令到maste  
>        2. 当slave接到了慢查询时(key \*, hgetall …)，会大量占用CPU性能  
>        3. master每秒调用复制定时函数replicationCron()，比对slave发现长时间没有进行响应
>  *  最终结果  
>        master各种资源(输出缓冲区、带宽、连接等)被严重占用
>  *  解决方案  
>       通过设置合理的超时时间，确认是否释放slave，`repl-timeout`该参数定义了超时时间的阈值(默认60秒)，超过该值，释放slave

*  频繁的网络中断(2)

> 问题现象  
>    slave与master连接断开  
> 问题原因  
>    1. master发送ping指令频度较低  
>    2. master设定超时时间较短  
>    3. ping指令在网络中存在丢包  
> 解决方案  
>    提高ping指令发送的频度 `repl-ping-slave-period`超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时

*  数据不一致

> 问题现象  
>    多个slave获取相同数据不同步  
> 问题原因  
>    网络信息不同步，数据发送有延迟  
> 解决方案  
>    优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象。监控主从节点延迟(通过offset)判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问 `slave-serve-stale-data yes|no`开启后仅响应info、slaveof等少数命令(慎用，除非对数据一致性要求很高)

--------------------

### \- 捐赠 - ###

--------------------

如果觉得还不错，请我喝杯水吧 ^ \_ ^ 您的鼓励是我不断前进的动力，如果有错误的地方，欢迎提出批评改正意见，[戳我][Link 1]，感谢您的支持

[Redis_-Windows_Linux]: https://blog.csdn.net/shiang_yan/article/details/106374531
[Redis]: https://blog.csdn.net/shiang_yan/article/details/106419289
[Redis_Java_Redis_Jedis]: https://blog.csdn.net/shiang_yan/article/details/106715945
[Redis_Redis]: https://blog.csdn.net/shiang_yan/article/details/106757561
[Redis_Redis_-multi_exec_discard]: https://blog.csdn.net/shiang_yan/article/details/106766022
[Redis 1]: https://blog.csdn.net/shiang_yan/article/details/106772467
[Redis_redis_-Bitmaps_HyperLogLog_GEO]: https://blog.csdn.net/shiang_yan/article/details/106781834
[Redis_redis_-]: https://blog.csdn.net/shiang_yan/article/details/106787637
[Redis_-]: https://blog.csdn.net/shiang_yan/article/details/106816943
[Redis_Redis_-]: https://blog.csdn.net/shiang_yan/article/details/106855953
[Redis_- 1]: https://blog.csdn.net/shiang_yan/article/details/106861236
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020061615202379.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2020061615420113.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[20200616155333336.png]: https://img-blog.csdnimg.cn/20200616155333336.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200616183343315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2020061619070569.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/2020061711305335.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200617165429932.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaWFuZ195YW4=,size_16,color_FFFFFF,t_70
[Link 1]: https://blog.csdn.net/shiang_yan