Redis深度历险-Redis主从同步

本文大部分内容引自《Redis深度历险：核心原理和应用实践》，感谢作者！！！

CAP理论

• C - Consistent ， 一致性
• A - Availability ， 可用性
• P - Partition tolerance， 分区容忍性

1、分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫着“网络分区”

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

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

Redis保证数据最终一致性

Redis的主从同步数据是异步的，分布式的Redis系统不满足“一致性”要求；Redis会保证“最终一致性”，从节点会努力追赶主节点，最终从节点状态会和主节点保持一致；如果主从出现了网络断开，网络恢复之后从节点将会继续追赶主节点，使主从节点数据保持一致

Redis主从同步

 

Redis支持主从同步和从从同步，从从同步减轻主节点的同步负担，主从复制是Redis高可用的根本，Redis几种集群模式都依赖于主从复制，主从复制是Redis系统数据安全的基础保障

增量同步

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

2、Redis的复制内存buffer是一个环形的定长数组，数组内容满了以后会从头开始覆盖

3、考虑网络不通的情况，如果主从节点之间长时间断开连接，主节点的指令buffer可能被覆盖了很多遍导致数据不准，这时候需要用到快照同步

快照同步

快照同步非常消耗IO资源

1、主节点进行一次bgsave保存当前内存快照到磁盘中，将快照文件的内容全部传送到从节点。从节点将接收到的快照文件进行一次性全量加载，加载之前会将当前内存的数据清空；加载完毕之后通知主节点继续进行增量同步

2、如果内存中Redis的数据过大可能会造成快照同步的死循环，因为从节点加载主节点快照文件耗时过长，主节点的增量同步buffer有可能会被覆盖掉。解决办法，设置一个合适的复制buffer

3、在从节点加入集群时，需要先进行快照同步再进行增量同步

无盘复制

无盘复制是指主服务器直接通过套接字将快找内容发送到从节点，生成快照是一个遍历的过程，主节点一边遍历内存一遍将序列化的内容发送到从节点；从节点还是和有盘复制的时候一样，先将接收到的内容存储到磁盘文件中再进行一次性加载

Wait指令

Redis 的复制是异步进行的，wait 指令可以让异步复制变身同步复制，确保系统的强一致性 (不严格)

> set key value
OK
> wait 1 0
(integer) 1

1、wait 提供两个参数，第一个参数是从库的数量 N，第二个参数是时间 t，以毫秒为单位。它表示等待 wait 指令之前的所有写操作同步到 N 个从库 (也就是确保 N 个从库的同步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到 N 个从库同步完成达成一致

2、假设此时出现了网络分区，wait 指令第二个参数时间 t=0，主从同步无法继续进行，wait 指令会永远阻塞，Redis 服务器将丧失可用性