有备无患——主从同步
主从同步,可以避免主节点挂了之后,运维让从节点接管,服务可以继续。否则主节点需要经过数据恢复和重启的过程,就可能拖延很长的时间,从而影响线上业务
CAP原理
CAP原理好比分布式领域的牛顿定律,是分布式存储的理论基石。
- C:Consistent 一致性
- A:Availablity 可用性
- P:Partition tolerance 分区容忍性
分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的,这意外着必然会有网路断开的风险,这个网络断开的场景的专业词汇叫做网络分区。
在网络分区发生时,两个节点无法通信,我们对一个节点进行修改操作时将无法同步到另一个节点,所以数据的一致性将无法满足,除非牺牲可用性,暂停分布式节点服务。
CAP理论:当网络分区发生时,一致性和可用性两难全
最终一致
Redis的主从数据是异步同步的,所以分布式的Redis系统并不满足一致性要求。
当客户端在Redis的主节点修改数据后,立即返回,即使在主从网络断开的情况下,主节点依旧可以正常对外提供修改服务,所以Redis满足可用性
Redis保证最终一致性,从节点会努力追赶主节点,最终从节点的状态和主节点的状态保持一致,如果网络断开,会出现大量的数据不一致,但一旦网络恢复,从节点会采用多种策略继续追赶,尽力保持主节点一致
主从同步与从从同步
Redis同步支持主从同步和从从同步,从从同步功能是Redis后续版本增加的功能,以减轻主节点的同步负担。
增量同步
Redis同步的是指令流,主节点将对自己的状态产生修改性影响的指令记录到本地的内存buffer中,然后异步将buffer中的指令同步到从节点,从节点一边执行同步的指令流来达到主节点一样的状态,一边向从节点反馈自己同步到哪里。
因为内存的buffer是有限的,所以Redis主节点不能将所有的指令记录在内存buffer中,Redis的复制内存buffer是一个定长的环形数组,如果数组内容满了,就会从头开始覆盖前面的内容。
如果因为网络状况不好,从节点在短时间内无法和主节点进行同步,从节点需要通过快照同步
快照同步
快照同步是一个非常耗费资源的操作,它首先需要在主节点上进行bgsave,将当前内存的数据全部快照到磁盘上,然后再将快照文件的内容全部传送到从节点。从节点将快照文件接收完毕后,立即执行一次全量加载,加载之前需要将当前内存的数据清空,加载完毕后通知主节点继续进行增量同步。
在整个快照同步进行的过程中,主节点的复制buffer还在不停地往前移动,如果快照同步的时间过长或者复制buffer太小,都会导致同步期间的增量指令再复制buffer中被覆盖,这样就会导致快照同步完成后无法进行增量复制,然后会再次发起快照同步,就有可能进入快照同步的死循环。
所以务必配置一个合适的赋值buffer大小参数,避免快照复制的死循环
增加从节点
当从节点刚刚加入到集群时,它必须先进行一次快照同步,同步完成后再继续进行增量同步
无盘复制
主节点在进行快照同步时,会很耗文件的IO操作,在非SSD磁盘存储时,快照同步会对系统的负载产生较大影响。当进行AOF的fsync操作时将会推迟fsync
Redis2.8支持无盘复制,主服务直接通过套节字将快照内容发送到从节点,主节点一边遍历内存,一边序列化内存发送给从节点。从节点和之前一样,先将接收到的内容存储到磁盘文件中,再进行一次性加载
wait指令
Redis的复制是异步进行的,wait指令可以让异步复制变身同步复制,确保系统的强一致性。提供两个参数,第一个参数是从节点的数量N,第二个参数是时间t,以毫秒为单位。两个参数的含义是:等待wait指令之前的所有写操作同步到N个从节点,最多等待时间t。如果时间t=0,表示无限等待直到N个从节点同步完成
假设此时出现了网络分区,wait指令第二个参数时间t=0,主从同步无法继续进行,wait指令会永远阻塞,Redis服务器丧失可用性