redis 主从复制

最新推荐文章于 2024-10-18 13:42:20 发布

QunKrys

最新推荐文章于 2024-10-18 13:42:20 发布

阅读量81

点赞数 1

分类专栏： redis 学习文章标签： redis 数据库 database

本文链接：https://blog.csdn.net/qq_38560825/article/details/121194786

版权

redis 学习专栏收录该内容

10 篇文章 0 订阅

订阅专栏

主从复制简介

高可用集群

slave 宕机不会影响整个集群
master 宕机由slave 暂时推选出新的master
为了减缓master 压力，可以给slave 增加从机（slave）
可以建立master 集群

主从复制的作用

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

主从复制工作流程

总述

三阶段
- 建立连接阶段（即准备阶段）
- 数据同步阶段
- 命令传播阶段

阶段一：建立连接阶段

建立slave 到 master 的连接，使master 能够识别slave，并保存slave 端口号
建立连接阶段的工作流程
- 设置master 的地址和端口号，保存master 信息
- 建立socket 连接
- 发送ping指令（定时器任务）
- 身份验证
- 发送slave 端口信息

连接之后的状态
- slave：保存master 的地址和端口
- master：保存slave 的端口
- 总体：slave 和 master 之间创建了连接的socket
主从连接方式
- 方式一：客户端发送连接命令，实例如下
1. 启动两个redis 服务（配置不同端口）
2. 使用客户端连接其中一个想要作为从服务器的服务器，输入命令 slaveof <masterip> <masterport> 即可。上述介绍的操作，会自动完成
- 方式二：启动服务器参数，实例如下：
1. 先启动一个redis 服务，配置好端口，作为master
2. 之后再启动另外一个redis 服务，但是在启动的时候直接进行连接。命令行如下：redis-server --slaveof <masterip> <masterport>
- 方式三：服务器配置（常用），实例如下：
1. 先启动一个redis 服务，配置好端口，作为master
2. 另一个启动时用的配置文件中加入 slaveof <masterip> <masterport> 语句，保存文件之后，使用该配置文件进行slave 服务的启动

阶段二：数据同步阶段工作流程

在slave 初次连接master 后，复制master 中所有的数据到slave
在slave 的数据库状态更新成master 当前的数据库状态
具体步骤
- 请求同步数据（slave）
- 创建RDB 同步数据（master）
- 恢复RDB 同步数据（slave）
- 请求部分同步数据，即复制缓冲区中的数据（slave）
- 恢复部分同步数据（slave）

数据同步完成之后的状态
- slave：具有master 端的全部数据，包含RDB 过程中接受的数据
  - 部分复制的过程其实就是在请求和发送RDB 过程中接受的数据的过程
  - 而复制缓冲区就是缓存在RDB 过程中的产生的新的数据
- master：保存slave 当前数据同步的位置
- 总体：slave 和 master 之间完成了数据的克隆
数据同步阶段master 说明
- 如果master 数据量巨大，数据同步阶段应避开流量高峰期，避免造成master 阻塞，影响业务正常执行。
- 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave 陷入死循环状态
数据同步阶段slave 说明
- 为避免slave 进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
- 多个slave同时对master 请求数据同步，master 发送的RDB 文件增多，会对带宽造成巨大冲击，如果master 带宽不足，因此数据同步需要根据业务需求，适量错峰

阶段三：命令传播阶段

定义：当master 数据库状态被修改之后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作叫命令传播
具体过程：master 将接受到的数据变更命令发送给slave，slave接受命令后执行命令
命令传播阶段的部分复制
- 命令传播阶段出现了断网现象
  - 网络闪断闪连（影响不大，忽略）
  - 长时间网络中断——全量复制
  - 短时间网络中断——部分复制
部分复制的三个核心要素
- 服务器的运行id（run id）
  - 概念：服务器运行ID 是每一台服务器每次运行的身份识别码，每次运行可能都不相同
  - 组成：运行id 由40 位字符组成，是一个随机的十六进制字符
  - 作用：运行id 被用于在服务器间进行传输，识别身份
  - 实现方式：运行id 在服务器启动时自动生成，master 在首次连接slave 时，会将自己的运行id 发送给slave，slave 保存此ID，通过info server 命令，可以查看节点的runid
- 主服务器的复制积压缓冲区
  - 概念：是一个先进先出的队列，用于存储服务器执行过的命令，每次传播命令，master 都会将传播的命令记录下来，并存储在复制缓冲区
  - 复制缓冲区内部工作原理
  - 组成
    - 偏移量
    - 字节值
  - 工作原理
    - 通过offset 区分不同的slave 当前数据传播的差异
- 主从服务器的复制偏移量
  - 概念：一个数字，描述复制缓冲区中指令字节位置
  - 分类
    - master 复制偏移量：记录发送给所有slave 的指令字节对应的位置（多个）
    - slave 复制偏移量：记录slave 接收master 发送过来的指令字节对应的位置（一个）
  - 数据来源：
    - master端：发送一次记录一次
    - slave 端：接收一次记录一次
  - 作用：同步信息，比对master 与slave 的差异，当slave 断线后，恢复数据使用

主从复制的全过程

心跳机制（维护命令传播阶段的核心）

进入命令传播阶段后，master 与slave 间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
master 心跳：
- 指令：ping
- 周期：由repl-ping-slave-period 决定，默认10秒
- 作用：判断slave 是否在线
- 查询：info replication
slave 心跳
- 指令：replconf ack {offset}
- 周期：1秒
- 作用1：汇报slave 自己的复制偏移量，获取最新的数据变更指令
- 作用2：判断master 是否在线
心跳阶段注意事项
- 当slave 多数掉线，或延迟过高，master 为保障数据稳定性，将拒绝所有信息同步操作
  - 通过以下配置项来判断什么时候关闭同步操作
    - min-slaves-to-write 2
    - min-slaves-max-lag 8
- slave 数量由slave 发送 replconf ack 命令做确认（之后和min-slaves-to-write 比较）
- slave 延迟由slave 发送 replconf ack 命令做确认（之后和min-slaves-max-lag 比较）

主从复制常见问题

频繁的全量复制

原因一：伴随着系统的运行，master 的数据量会越来越大，一但master 重启，runid 将发生变化，会导致全部slave 的全量复制操作

内部优化方案：

master 内部创建master_replid 变量，使用runid 相同的策略生成，长度为41 位，并发送给所有slave
在master 关闭时执行命令shutdown save，进行RDB持久化，将runid 与 offset 保存到RDB 文件中
- repl-id repl-offset
- 通过redis-check-rdb 命令可以查看该信息
master 重启后加载RDB 文件，恢复数据
- 重启后，将RDB 文件中保存的repl-id与repl-offset 加载到内存中
  - master_repl_id = repl master_repl_offset = repl-offset
  - 通过命令info 可以查看该信息
作用：保存本机保存上次runid，重启后恢复该值，使所有slave 认为还是之前的master

原因二：网络环境不佳，出现网络中断，slave不提供服务。而此时复制缓冲区过小，导致断网后slave 的offset 越界，触发全量复制。而严重时，会导致slave反复进行全量复制。

解决方案：修改复制缓冲区大小