1.1.1. 11.主从同步


CAP 原理

所谓 CAP 即:

  1. C - Consistent ,一致性
  2. A - Availability ,可用性
  3. P - Partition tolerance ,分区容忍性

分布式系统节点往往分布在不同机器上,当机器间网络断开时,则称之为「网络分区」。 一旦网络分区,将会导致主从系统之间无法同步数据,导致「一致性」无法满足。除非牺牲「可用性」,暂停分布式节点服务,在网络分区时不在提供修改数据功能,知道网络恢复为止。 s 网络分区

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

最终一致性

Redis 的主从同步是异步的,所以分布式的 Redis 不满足「一致性」要求。但是 Redis保证「最终一致性」。即使网络分区时,主节点依旧可以对外提供正常服务保证「可用性」。当网络恢复时,从节点会努力追赶主节点,最终达到一致。

主从同步

Redis 同步支持主从同步和从从同步,从从同步是后续版本增加的。

主从同步

增量同步 AOF

Redis 同步是指令流,主节点会将对自己产生修改性的指令记录在本地内存的 buffer 中,然后异步的同步给从节点。从节点一边执行同步指令,一边向主节点反馈自己同步到哪了。

但是由于内存的 buffer 是有限的,Redis 的复制内存 buffer 是一个环形数组,如果该数组满了,则会从头覆盖前面的指令。

增量同步

如因为网络分区,导致从节点无法与主节点进行同步,当网络恢复时,主节点中没有同步的指令在 buffer 中被后续指令给覆盖了。

快照同步 RDB

快照同步是一种非常耗资源的操作,其过程是在主节点上进行一次 bgsave,将当前内存的数据全部快照到磁盘文件中,然后将快照文件传给从节点,从节点接收完毕后,立即执行全量加载,加载之前会将当前内存的数据清空。加载完毕后通知主节点进行增量同步。

整个快照同步过程中,主节点的复制 buffer 还是在一直向前一定,如果快照同步时间过长或者复制 buffer 过小,也会导致增量指令在 buffer 中被覆盖,导致增量同步无法完成,又会再一次发起快照同步,如此可能造成死循环。

快照同步

所以,需要设置一个合适的复制 buffer 大小,避免快照复制死循环。

增加从节点

当从节点加入到集群时,先执行一次快照同步,再进行增量同步。

无盘复制

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

所以从 redis 的 2.8.18 版开始支持无盘复制。所谓无盘复制是指,主节点直接通过套接字(socket)连接从节点,生成快照是一个遍历的过程,主节点会一边遍历内存,一边将序列化的内容发送给从节点,从节点还是跟之前一样,接收完毕后,再一次性加载。

wait

Redis 的复制是异步的,wait 指令可以使其变成同步复制,却表系统的一致性(不严格)。

> 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主从同步:

  1. 增量追赶,写指令流同步
  2. 增量太慢了,全量追赶,快照同步
  3. 无盘复制,生产快照是一个遍历的过程 主从主要是为了保障Redis的高可用性,同时也能兼顾提升性能
Copyright © Kagami丶 2019 all right reserved,powered by Gitbook该文件修订时间: 2019-12-10 21:45:40

results matching ""

    No results matching ""