【Redis学习笔记】第十一章 Redis主从复制

川长思鸟来 2024-04-08 10:37 67阅读 0赞

#### 文章目录 ####

*  1、主从复制的简介
 *  2、主从复制的作用
 *  3、主从复制工作流程
 *   *  3.1 建立连接阶段
     *  3.2 数据同步阶段
     *  3.3 命令传播阶段
     *  3.4 数据同步+命令传播整体流程梳理
 *  4、心跳机制
 *  5、主从复制的常见问题

![在这里插入图片描述][da94e96120864b07a4e4980d21ddef73.png]

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

## 1、主从复制的简介 ##

互联网“三高”架构：

*  高并发
 *  高性能
 *  高可用

对于单机的Redis，机器故障，很可能数据丢失，对业务造成灾难性打击。且内存容量也存在瓶颈问题。  
![在这里插入图片描述][b62ac207cfe9422cbd12446a0abada1c.png]  
基于以上问题，准备多台服务器，互相连通。**将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的**。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

![在这里插入图片描述][1d9445be3d154ee8b3ecadccee603dfd.png]  
主从复制即：将master中的数据即时、有效的复制到slave中，master也叫主服务器，slave也叫从服务器。master与slave之间是一对多的关系。

职责：

*  master:  
    写数据  
    执行写操作时，将出现变化的数据自动同步到slave  
    读数据可忽略
 *  slave：  
    读数据  
    写数据（禁止）

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

![在这里插入图片描述][9fb8218c5c214ea49246afa33929d6ad.png]

*  读写分离：master写、slave读，提高服务器的读写负载能力
 *  负载均衡：并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载
 *  故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
 *  数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
 *  高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

## 3、主从复制工作流程 ##

**① 建立连接阶段  
② 数据同步阶段  
③ 命令传播阶段**  
![在这里插入图片描述][01ad1a4c974043c8a4821cfb474b0f5e.png]

### 3.1 建立连接阶段 ###

> 步骤①：设置master的地址和端口，保存master信息  
> 步骤②：建立socket连接  
> 步骤③：发送ping命令（定时器任务，确认连接还正常）  
> 步骤④：身份验证  
> 步骤⑤：发送slave端口信息

至此，主从连接成功！具体示意图：  
![在这里插入图片描述][02d01e94ef9549e7abf51f2093023af6.png]  
这时：

*  状态：  
    slave端：保存master的地址与端口  
    master端：保存slave的端口
 *  总体：  
    之间创建了连接的socket

> **`搭建主从结构`**  
> 以6379和6380两个端口模拟两台Redis服务器,daemonize参数设置为no，方便在控制台直接看日志  
>   
>   
> **方式一**：客户端发送指令`slaveof <masterip> <masterport>`  
> ![在这里插入图片描述][df55c68a2e4f4beabf29a342550cc4a7.png]  
> ![在这里插入图片描述][d9789f9b635145ad82138dc1824fbce9.png]  
>   
>   
> **方式二**：修改启动slave服务器的指令。`redis-server -slaveof <masterip> <masterport>`  
> ![在这里插入图片描述][6a97e163177c47ae86b929ed6cf8caca.png]  
>   
>   
> **方式三**：走配置文件：`slaveof <masterip> <masterport>`  
> ![在这里插入图片描述][3facd5feed9b4b6e8bb5c73d4f39dd2e.png]  
>   
>   
> 搭建完连接后，查看slave或者master的info  
> ![在这里插入图片描述][a9982d270f354998a86516094092a1cd.png]  
>   
> 主从断开连接，`slave端执行slaveof no one`,slave断开连接后，不会删除已有数据，只是不再接受master发送的数据

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

> **`关于身份验证，授权访问！！！！`**
> 
>  *  master配置文件中设置密码  
>     requirepass <password>
>  *  master客户端发送命令设置密码  
>     config set requirepass <password>  
>     config get requirepass  
>       
>     master端设置完密码后，slave端访问就要带上密码
>  *  slave客户端发送命令带密码获得授权  
>     auth <password>
>  *  slave配置文件设置密码  
>     masterauth <password>  
>     \-slave启动指令带密码  
>     redis-server –a <password>

### 3.2 数据同步阶段 ###

> 步骤①：请求同步数据  
> 步骤②：创建RDB同步数据  
> 步骤③：恢复RDB同步数据  
> 步骤④：请求部分同步数据  
> 步骤⑤：恢复部分同步数据

至此，数据同步工作完成！具体如图：  
![在这里插入图片描述][4b4725856d724a65b094402c5a890e2a.png]

同步数据过程中的这些日志，在建立连接后的控制台中可以看到：  
![在这里插入图片描述][05068fc198bc435f84ca24bdf07bc494.png]  
**注–master：**

*  如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
 *  复制缓冲区大小设定不合理，会导致数据溢出。修改master配置文件中的 repl-backlog-size 1mb![在这里插入图片描述][da92fa6242fd41f29854586a1cd1c6ee.png]
 *  master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

**注–slave：**

*  为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务，改slave配置文件 slave-serve-stale-data yes|no
 *  slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是  
    slave。但由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟较大，数据一致性变差

### 3.3 命令传播阶段 ###

master将接收到的数据变更命令发送给slave，slave接收命令后执行命令。让主从数据同步到一致的  
状态，同步的动作称为命令传播。

命令传播阶段出现断网，影响了数据传输如何处理？

<table> 
 <thead> 
  <tr> 
   <th>场景</th> 
   <th>处理措施</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>网络闪断闪连</td> 
   <td>忽略</td> 
  </tr> 
  <tr> 
   <td>短时间网络中断</td> 
   <td>部分复制</td> 
  </tr> 
  <tr> 
   <td>长时间网络中断</td> 
   <td>全量复制</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][8b514a038465402a9807a1308d0ac71e.png]  
**服务器运行ID（runid）**：

*  是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
 *  运行id由40位字符组成，是一个随机的十六进制字符，被用于在服务器间进行传输，识别身份
 *  运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发  
    送给slave，slave保存此ID。通过info Server命令，可以查看节点的runid

![在这里插入图片描述][c3facfaf511c47e989bf109aa90cf361.png]

**复制缓冲区：**

复制缓冲区是一个用来备份的先进先出的队列，该区大小在配置文件中写死了，当入队元素超过时，最先入队的元素会被弹出。

![在这里插入图片描述][f6ce345a56d149ba918afffee8eff22f.png]  
复制缓冲区的内部原理如图：

![在这里插入图片描述][94d39a9a05cb40e4aa0a0cd4ed28ada3.png]  
**注：**

*  每台服务器启动时，如果开启有AOF或被连接成为master节点，会创建复制缓冲区

**偏移量：**  
![在这里插入图片描述][3420e275eef94a4c9c82785e7fab7892.png]

### 3.4 数据同步+命令传播整体流程梳理 ###

![在这里插入图片描述][cdb95475983c445b9c7c442d8f3a3b2f.png]

## 4、心跳机制 ##

*  进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，确定双方连接保持在线
 *  **master心跳**：

指令：PING
    周期：由repl-ping-slave-period决定，默认10秒
    作用：判断slave是否在线
    查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

![在这里插入图片描述][6dbeeeb17cc04304909bd2834d274aa3.png]

*  **slave心跳任务**：

指令：REPLCONF ACK {
        offset}
    周期：1秒
    作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
    作用2：判断master是否在线

*  **处理措施**：  
    当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作。

min-slaves-to-write 2
    min-slaves-max-lag 8
    slave数量少于2个，或者所有slave的延迟都大于等于8秒时：
    ***强制关闭master写功能，停止数据同步***
    
    slave数量和延迟由slave发送REPLCONF ACK命令做确认

## 5、主从复制的常见问题 ##

**①master重启导致全量复制**

问题：  
master重启，runid将发生变化而不匹配，会导致全部slave的全量复制  
  
方案：

*  master内部创建master\_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave
 *  在master关闭时执行命令 shutdown save，进行RDB持久化,将runid与offset保存到RDB文件中的repl-id 和 repl-offset![在这里插入图片描述][afecf639aa7b462db2b6ad665ecb83dc.png]
 *  master重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中，master\_repl\_id = repl master\_repl\_offset = repl-offset。这样使所有slave认为还是之前的master了

**②缓冲区大小设置不合理导致频繁全量复制**

*  问题现象  
    网络环境不佳，出现网络中断，slave不提供服务
 *  问题原因  
    复制缓冲区过小，断网后slave的offset越界，触发全量复制
 *  最终结果  
    slave反复进行全量复制
 *  解决方案  
    修改复制缓冲区大小 repl-backlog-size

**③slave导致频繁的网络中断**

*  问题现象  
    master的CPU占用过高 或 slave频繁断开连接
 *  问题原因  
    slave会每1秒发送REPLCONF ACK命令到master，但当slave接到了慢查询时（keys \* ，hgetall等），会大量占用CPU性能，太忙的slave，被master发现长时间没有进行响应
 *  最终结果  
    master各种资源（输出缓冲区、带宽、连接等）被严重占用，类比一个学生旷课，老师忙着打听他，浪费了上课时间
 *  解决方案  
    设置 repl-timeout，定义超时时间的阈值（默认60秒），超过该值，释放slave

**④master导致频繁的网络中断**

*  问题现象  
    slave与master连接断开
 *  问题原因  
    master发送ping指令频度较低且master设定超时时间较短，或者ping指令在网络中存在丢包
 *  最终结果  
    slave很容易判定超时
 *  解决方案  
    提高ping指令发送的频度 repl-ping-slave-period。超时时间repl-time的时间至少是ping指令频度的5到10倍

**⑤数据不一致**

*  问题现象  
    多个slave获取相同数据不同步
 *  问题原因  
    网络信息不同步，数据发送有延迟
 *  最终结果  
    slave很容易判定超时
 *  解决方案  
    \-优化主从间的网络环境，通常放置在同一个机房部署，特别注意云服务器  
    \-监控主从节点延迟（通过offset）判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问：`slave-serve-stale-data yes|no`，开启后仅响应info、slaveof等少数命令，达到屏蔽效果。

[da94e96120864b07a4e4980d21ddef73.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/4dca02f1de3748afb1ae7fdf1d8faf4d.png
[b62ac207cfe9422cbd12446a0abada1c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a1e26b26b6624e4d8b704342efcb7b39.png
[1d9445be3d154ee8b3ecadccee603dfd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/ad14bfd71f5e40a0a90fcb4588cd7d07.png
[9fb8218c5c214ea49246afa33929d6ad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/6c333b0f171044df949f7b78db99b36e.png
[01ad1a4c974043c8a4821cfb474b0f5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/173afdcfbf8340f98b6c4881a1c7ad7d.png
[02d01e94ef9549e7abf51f2093023af6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/b555aeb17fc641bdbed60654820b53ac.png
[df55c68a2e4f4beabf29a342550cc4a7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/7d1f28f6a0f6485280e0a6c151e89b15.png
[d9789f9b635145ad82138dc1824fbce9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/9b4975121e384b799c261aaf26ee892d.png
[6a97e163177c47ae86b929ed6cf8caca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/118ce397144b489c960fa96c39816d0d.png
[3facd5feed9b4b6e8bb5c73d4f39dd2e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/6b6f6372479e4bffb1be4c41ef598424.png
[a9982d270f354998a86516094092a1cd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/0827efa124aa479a8a1fb19b60cf5f15.png
[4b4725856d724a65b094402c5a890e2a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/286a8ed58bec466a84983323999a623d.png
[05068fc198bc435f84ca24bdf07bc494.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e19674ee1b1a4559b5c41b6be10fe2bf.png
[da92fa6242fd41f29854586a1cd1c6ee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/34648348f36e44859ddc34b0fe1ac48d.png
[8b514a038465402a9807a1308d0ac71e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/aa735126c31a4007aae29d426a903efd.png
[c3facfaf511c47e989bf109aa90cf361.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/41b13e412dc14c4f9a1ca5fc34998539.png
[f6ce345a56d149ba918afffee8eff22f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/6b86eb1b97af433ca2e4373740295a1d.png
[94d39a9a05cb40e4aa0a0cd4ed28ada3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/1a7b996c47b7417bb1ef412eb29de428.png
[3420e275eef94a4c9c82785e7fab7892.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/9f89914c456746398e98c411e01ed7e7.png
[cdb95475983c445b9c7c442d8f3a3b2f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a311e24ba98543a180bb7ab9076a9291.png
[6dbeeeb17cc04304909bd2834d274aa3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/b00743e16ba74e8091cb217829a5527c.png
[afecf639aa7b462db2b6ad665ecb83dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/d3424cec74dd46b1a823aa86cd3437a1.png