增量同步 Redis 同步的是指令流,主节点会将那些对自己的状态产生修改性影响的指令记录在本 地的内存 buffer 中,然后异步将 buffer 中的指令同步到从节点,从节点一边执行同步的指 令流来达到和主节点一样的状态,一遍向主节点反馈自己同步到哪里了 (偏移量)。 因为内存的 buffer 是有限的,所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组,如果数组内容满了,就会从头开始覆 盖前面的内容。
如果因为网络状况不好,从节点在短时间内无法和主节点进行同步,那么当网络状况恢 复时,
Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉 了,从节点将无法直接通过指令流来进行同步,这个时候就需要用到更加复杂的同步机制 — — 快照同步。
快照同步
快照同步 快照同步是一个非常耗费资源的操作,它首先需要在主库上进行一次 bgsave 将当前内 存的数据全部快照到磁盘文件中,然后再将快照文件的内容全部传送到从节点。从节点将快 照文件接受完毕后,立即执行一次全量加载,加载之前先要将当前内存的数据清空。加载完 毕后通知主节点继续进行增量同步。
在整个快照同步进行的过程中,主节点的复制 buffer 还在不停的往前移动,如果快照同 步的时间过长或者复制 buffer 太小,都会导致同步期间的增量指令在复制 buffer 中被覆 盖,这样就会导致快照同步完成后无法进行增量复制,然后会再次发起快照同步,如此极有 可能会陷入快照同步的死循环。
所以务必配置一个合适的复制 buffer 大小参数,避免快照复制的死循环。
增加从节点
当从节点刚刚加入到集群时,它必须先要进行一次快照同步,同步完成后再继续进行增 量同步。
无盘复制
主节点在进行快照同步时,会进行很重的文件 IO 操作,特别是对于非 SSD 磁盘存储 时,快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果 发生快照,fsync 将会被推迟执行,这就会严重影响主节点的服务效率。
所以从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是指主服务器直接通过套接字 将快照内容发送到从节点,生成快照是一个遍历的过程,主节点会一边遍历内存,一遍将序 列化的内容发送到从节点,从节点还是跟之前一样,先将接收到的内容存储到磁盘文件中, 再进行一次性加载。
Wait 指令
Redis 的复制是异步进行的,wait 指令可以让异步复制变身同步复制,确保系统的强一 致性 (不严格)。wait 指令是 Redis3.0 版本以后才出现的。
set key value OK > wait 1 0 (integer) 1 wait 提供两个参数,
第一个参数是从库的数量 N,第二个参数是时间 t,以毫秒为单 位。
它表示等待 wait 指令之前的所有写操作同步到 N 个从库 (也就是确保 N 个从库的同 步没有滞后),最多等待时间 t。如果时间 t=0,表示无限等待直到 N 个从库同步完成达成 一致。 假设此时出现了网络分区,wait 指令第二个参数时间 t=0,主从同步无法继续进行, wait 指令会永远阻塞,Redis 服务器将丧失可用性。
小结 主从复制是 Redis 分布式的基础,Redis 的高可用离开了主从复制将无从进行。后面的 章节我们会开始讲解 Redis 的集群模式,这几种集群模式都依赖于本节所讲的主从复制。 不过复制功能也不是必须的,如果你将 Redis 只用来做缓存,跟 memcache 一样来对 待,也就无需要从库做备份,挂掉了重新启动一下就行。但是只要你使用了 Redis 的持久化 功能,就必须认真对待主从复制,它是系统数据安全的基础保障