Redis（5）——Redis复制的原理与优化

一、课程目录

• 什么是主从复制
• 全量复制和部分复制
• 复制的配置
• 故障处理
• 开发运维常见问题

二、什么是主从复制

一主一从

主从复制的作用：

• 数据副本
• 扩展读性能

【总结】

• 一个master可以有多个slave
• 一个slave只能有一个master
• 数据流向是单向的，master到slave

三、 runid和复制偏移量

每个redis在启动的时候都会有一个随机地runid，来表示redis的标志

四、全量复制

全量复制过程：

• 【步骤一】如果设置了一个Slave，无论是第一次连接还是重连到Master，它都会发出一个PSYNC命令‘
• 【步骤二】当Master收到SYNC命令手，会做两个事情：
  • Master执行BGSAVE，即在后台保存数据到磁盘（RDB快照文件）
  • Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）
• 【步骤三】当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中
• 【步骤四】而Master/Slave此后会不断通过异步的方式进行命令的同步，达到最终的数据同步一致

先将RDB文件同步给slave，然后在同步RDB期间，再有向master中写入的数据就单独记录下来，然后当RDB复制完后，观察master和slave的偏移量。

在全量复制的时候，如果发生了网络抖动，那么连接可能会发生断开。

部分复制的过程

• 【步骤一】当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步
• 【步骤二】Master端为复制刘维护一个内存缓冲区，记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量（replication offset）和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时：
  • 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓存区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了。
  • 否则，依然需要全量复制操作。

五、故障处理

当出现故障的时候，我们希望故障可以自动转移。

六、主从复制常见问题

• 读写分离：读流量分摊到从节点
• 可能遇到问题
  • 复制数据延迟
  • 读到过期数据
  • 从节点故障

6.2 配置不一致

• 例如maxmemory不一致：丢失数据

6.3 规避全量复制

• 第一次全量复制

  • 第一次不可避免
  • 小主节点：即maxmemory不要设置的过大。低峰：在用户比较少的时候，比如夜间

• 节点运行ID不匹配

  • 主节点重启（运行runID变化）
  • 采取措施：故障转移，例如哨兵或者集群

• 复制积压缓冲区不足

  • 网络中断，部分复制无法满足
  • 采取措施：增大复制缓冲区配置：rel_backlog_size,网络“增强”。

6.4 规避复制风暴

当master挂了很多slave的时候，master宕机了，这个时候所有的slave都需要重新全量复制。

• 单主节点复制风暴：
  • 问题：主节点重启，多从节点复制
  • 解决：更换复制拓扑

可以更改为右边的架构，但是还是有一个问题，当slave1出现问题了，那么怎么解决。

• 单机器复制风暴
  • 机器宕机后，大量全量复制

参考并感谢

https://blog.csdn.net/Stubborn_Cow/article/details/50442950