Redis从菜鸟到大神-主从同步

很多企业都没有使用到 Redis 的集群,但是至少都做了主从。有了主从,当 master 挂 掉的时候,运维让从库过来接管,服务就可以继续,否则 master 需要经过数据恢复和重启 的过程,这就可能会拖很长的时间,影响线上业务的持续服务。

在了解 Redis 的主从复制之前,让我们先来理解一下现代分布式系统的理论基石—— CAP 原理。

一、CAP 原理

CAP 原理就好比分布式领域的牛顿定律,它是分布式存储的理论基石。自打 CAP 的论 文发表之后,分布式存储中间件犹如雨后春笋般一个一个涌现出来。理解这个原理其实很简 单,本节我们首先对这个原理进行一些简单的讲解。

C - Consistent ,一致性
A - Availability ,可用性
P - Partition tolerance ,分区容忍性分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的,这意味着必然会有网络断开的风险,这个网络断开的场景的专业词汇叫着「网络分区」。

  在网络分区发生时,两个分布式节点之间无法进行通信,我们对一个节点进行的修改操
作将无法同步到另外一个节点,所以数据的「一致性」将无法满足,因为两个分布式节点的
数据不再保持一致。除非我们牺牲「可用性」,也就是暂停分布式节点服务,在网络分区发
生时,不再提供修改数据的功能,直到网络状况完全恢复正常再继续对外提供服务。

一句话概括 CAP 原理就是——网络分区发生时,一致性和可用性两难全。

最终一致

Redis 的主从数据是异步同步的,所以分布式的 Redis 系统并不满足「一致性」要求。 当客户端在 Redis 的主节点修改了数据后,立即返回,即使在主从网络断开的情况下,主节 点依旧可以正常对外提供修改服务,所以 Redis 满足「可用性」。

Redis 保证「最终一致性」,从节点会努力追赶主节点,最终从节点的状态会和主节点 的状态将保持一致。如果网络断开了,主从节点的数据将会出现大量不一致,一旦网络恢 复,从节点会采用多种策略努力追赶上落后的数据,继续尽力保持和主节点一致。

二、主从同步

Redis 同步支持主从同步和从从同步,从从同步功能是 Redis 后续版本增加的功能,为 了减轻主库的同步负担。后面为了描述上的方便,统一理解为主从同步。

增量同步

Redis 同步的是指令流,主节点会将那些对自己的状态产生修改性影响的指令记录在本 地的内存 buffer 中,然后异步将 buffer 中的指令同步到从节点,从节点一边执行同步的指 令流来达到和主节点一样的状态,一遍向主节点反馈自己同步到哪里了 (偏移量)。

因为内存的 buffer 是有限的,所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组,如果数组内容满了,就会从头开始覆 盖前面的内容。

如果因为网络状况不好,从节点在短时间内无法和主节点进行同步,那么当网络状况恢 复时,Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉 了,从节点将无法直接通过指令流来进行同步,这个时候就需要用到更加复杂的同步机制 — — 快照同步。

快照同步

快照同步是一个非常耗费资源的操作,它首先需要在主库上进行一次 bgsave 将当前内 存的数据全部快照到磁盘文件中,然后再将快照文件的内容全部传送到从节点。从节点将快照文件接受完毕后,立即执行一次全量加载,加载之前先要将当前内存的数据清空。加载完 毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中,主节点的复制 buffer 还在不停的往前移动,如果快照同 步的时间过长或者复制 buffer 太小,都会导致同步期间的增量指令在复制 buffer 中被覆 盖,这样就会导致快照同步完成后无法进行增量复制,然后会再次发起快照同步,如此极有 可能会陷入快照同步的死循环。

所以务必配置一个合适的复制 buffer 大小参数,避免快照复制的死循环。

增加从节点

  当从节点刚刚加入到集群时,它必须先要进行一次快照同步,同步完成后再继续进行增
量同步。

无盘复制

主节点在进行快照同步时,会进行很重的文件 IO 操作,特别是对于非 SSD 磁盘存储 时,快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果 发生快照,fsync 将会被推迟执行,这就会严重影响主节点的服务效率。

所以从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是指主服务器直接通过套接字 将快照内容发送到从节点,生成快照是一个遍历的过程,主节点会一边遍历内存,一遍将序 列化的内容发送到从节点,从节点还是跟之前一样,先将接收到的内容存储到磁盘文件中, 再进行一次性加载。

三、总结

主从复制是 Redis 分布式的基础,Redis 的高可用离开了主从复制将无从进行。后面的 章节我们会开始讲解 Redis 的集群模式,这几种集群模式都依赖于本节所讲的主从复制。

不过复制功能也不是必须的,如果你将 Redis 只用来做缓存,跟 memcache 一样来对 待,也就无需要从库做备份,挂掉了重新启动一下就行。但是只要你使用了 Redis 的持久化 功能,就必须认真对待主从复制,它是系统数据安全的基础保障。

 

————————————————————————————————————

参考文章:https://blog.csdn.net/shenchaohao12321/article/details/87927324

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值