Redis 主从同步
CAP原理
- C: Consistent，一致性
- A: Availability，可用性
- P: Partition tolerance, 分区容忍性
分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然有网络断开的风险，这个网络断开的场景的专业词汇叫做网络分区。
在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另一个节点，所以数据的一致性将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲可用性，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络情况完全恢复正常再继续对外提供服务。
用一句话概括CAP原理就是：当网络分区发生时，一致性和可用性两难全。
Redis的主从同步
redis的主从数据是异步同步的，所以分布式的redis系统并不满足一致性要求。当客户端在redis的主节点修改了数据后，立即返回，即时在主从网络断开的情况下，主从节点依旧可以正常对外提供服务，所以redis满足可用性。
redis保证最终一致性，从节点会女里追赶主节点，最终从节点的状态会和主节点的状态保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，单一旦网络恢复，从节点会采用多从策略努力追赶，继续尽力保持和主节点一致。
redis同步支持主从同步和从从同步。从从同步是为了减轻主节点的同步负担，所以我们工作中一般选用的结构是：master--slave--slave--slave。
-
增量同步
redis同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存buffer中，然后异步将buffer中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了（偏移量）
因为内存的buffer是有限的，所以redis主节点不能将所有的指令都记录在buffer中。redis的复制内存buffer是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖之前的内容。
主从服务器刚刚连接时，或者主从服务器长时间断开时，当Slave节点给定的run_id和Master的run_id不一致时，或者Slave给定的上一次增量同步的offset的位置在Master的环形内存中无法定位时，Master就会对Slave发起全量同步操作。 -
快照同步（全量同步）
- 从服务器连接主服务器，发送SYNC命令；
- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
redis2.8.18版本开始，redis支持无盘复制。主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一边将序列化的内容发送到从节点，从节点还是和以前一样，先将收到的内容存储到磁盘文件中，再进行一次性加载。
在整个快照同步的过程中，主节点的复制buffer还在不停地向前移动，如果快照同步的时间过长或者复制buffer太小，都会导致同步期间的增量指令在复制fubber中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此机油可能会陷入快照同步的死循环。所以务必配置一个合适的复制buffer大小参数，避免快照复制的死循环。
-
Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。 -
wait指令
redis3.0版本之后出现，将异步复制变身同步复制。
wait N t
N：从节点数量
t：最多等待时间，单位毫秒，0为无限等待
