Redis主从复制的原理

更多内容，欢迎关注微信公众号：全菜工程师小辉。公众号回复关键词，领取免费学习资料。

在Redis集群中，让若干个Redis服务器去复制另外一个Redis服务器，咱们定义被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave），这种模式叫作主从复制模式。

数据流向是单向的，只能是从master到slave

一个slave只能有一个master

主从复制的做用

• 为数据提供多个副本，实现高可用
• 实现读写分离（主节点负责写数据，从节点负责读数据，主节点按期把数据同步到从节点保证数据的一致性）

主从复制的方式

• 命令slaveof。
  优势：无需重启。缺点：不便于管理

// 命令行使用
slaveof ip port // 使用命令后自身数据会被清空，但取消slave只是中止复制，并不清空复制代码

• 修改配置。
  优势：统一配置。缺点：须要重启

// 配置文件中配置
slaveof ip port
slave-read-only yes //只容许从节点进行读操做复制代码

全量复制

用于初次复制或其它没法进行部分复制的状况，将主节点中的全部数据都发送给从节点，是一个很是重型的操做，当数据量较大时，会对主从节点和网络形成很大的开销

全量复制过程：

1. Redis内部会发出一个同步命令，刚开始是Psync命令，Psync ? -1表示要求master主机同步数据
2. 主机会向从机发送run_id和offset，由于slave并无对应的 offset，因此是全量复制
3. 从机slave会保存主机master的基本信息
4. 主节点收到全量复制的命令后，执行bgsave（异步执行），在后台生成RDB文件（快照），并使用一个缓冲区（称为复制缓冲区）记录从如今开始执行的全部写命令
5. 主机发送RDB文件给从机
6. 发送缓冲区数据
7. 刷新旧的数据。从节点在载入主节点的数据以前要先将老数据清除
8. 加载RDB文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。

全量复制开销

• 主节点须要bgsave
• RDB文件网络传输占用网络io
• 从节点要清空数据
• 从节点加载RDB
• 全量复制会触发从节点AOF重写

部分复制

部分复制是Redis 2.8之后出现的，用于处理在主从复制中因网络闪断等缘由形成的数据丢失场景，当从节点再次连上主节点后，若是条件容许，主节点会补发丢失数据给从节点。由于补发的数据远远小于全量数据，能够有效避免全量复制的太高开销，须要注意的是，若是网络中断时间过长，形成主节点没有可以完整地保存中断期间执行的写命令，则没法进行部分复制，仍使用全量复制

部分复制过程：

1. 若是网络抖动（链接断开 connection lost）
2. 主机master 仍是会写 replbackbuffer（复制缓冲区）
3. 从机slave 会继续尝试链接主机
4. 从机slave 会把本身当前 run_id 和偏移量传输给主机 master，而且执行 pysnc 命令同步
5. 若是master发现你的偏移量是在缓冲区的范围内，就会返回 continue命令
6. 同步了offset的部分数据，因此部分复制的基础就是偏移量 offset。

服务器运行ID(runid)：每一个Redis节点(不管主从)，在启动时都会自动生成一个随机ID(每次启动都不同)，由40个随机的十六进制字符组成；runid用来惟一识别一个Redis节点。 经过info server命令，能够查看节点的run_id。

开发运维常见的问题

1. 读写分离

• 复制数据存在延迟（若是从节点发生阻塞）
• 从节点可能发生故障

1. 主从配置不一致

• 例如maxmemory不一致，可能会形成丢失数据
• 例如数据结构优化参数不一致：形成主从内存不一致

1. 规避全量复制

• 第一次全量复制不可避免，因此分片的maxmemory减少，同时选择在低峰（夜间）时，作全量复制。
• 复制积压缓冲区不足
  增大复制缓冲区配置relbacklogsize

例如若是网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，能够设置为12MB，来保证绝大多数断线状况均可以使用部分复制。

1. 复制风暴
   master节点重启，master节点生成一份rdb文件，可是要给全部从节点发送rdb文件。对cpu，内存，带宽都形成很大的压力

更多内容，欢迎关注微信公众号：全菜工程师小辉。公众号回复关键词，领取免费学习资料。