Redis学习之四 —— AOF、RDB

 

CAP 原理

CAP原理是分布式存储的理论基石。

C - Consistent ，一致性

A - Availability ，可用性

P - Partition tolerance ，分区容忍性

分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这种情况称为网络分区。当两个节点无法进行通信时，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据【一致性】将无法满足。除非我们牺牲【可用性】，也就是暂停分布式节点服务，在网络断开时不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。

CAP 原理就是 -- 网络分区发生时，一致性 和 可用性两难全。

最终一致

Redis 的主从数据是异步同步的，所以分布式的Redis 系统并不满足【一致性】要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，所以 Redis 满足【可用性】。

Redis 保证【最终一致性】，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。

主从同步

Redis 同步支持主从同步和从从同步，从从同步功能是 Redis后续版本增加的功能，为了减轻主库的同步负担。

增量同步

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

因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

当网络恢复时，Redis的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这时候就需要用到更加复杂的同步机制 —— 快照同步。

快照同步

快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当期内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。从节点将快照文件接收完毕后，立即执行一次全量加载，加载之前先要将当期内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停地往前移动，如果快照同步的时间过长或者复制buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。

所以务必配置一个合适的 复制 buffer 大小参数，避免快照复制的死循环。

增加从节点

当从节点刚刚加入到集群时，它必须先要进行一次快照同步，同步完成后再继续进行增量同步。

无盘复制

主节点在进行快照同步时，会进行很重的文件 I/O 操作，特别是对于 非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。

所以从 Redis2.8.18 版开始支持无盘复制。无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一边将序列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中再进行一次性加载。