CAP定理

C - Consistent ，一致性：数据在多个副本之间能够保持一致的特性

A - Availability ，可用性：系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应。

P - Partition tolerance ，分区容忍性：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有

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

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

BASE定理

BASE定理是对CAP定理的延伸：即使无法做到强一致性（Strong Consistency），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。CAP中提到的一致性是强一致性，所谓“牺牲一致性”指牺牲强一致性保证弱一致性。

BASE是指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）

基本可用：出现故障的时候，允许损失部分可用性，即保证核心可用。

软状态：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

最终一致

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

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

主从同步

Redis主从同步分为增量同步和快照同步

增量同步

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

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

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

快照同步

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

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

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

client-output-buffer-limit slave 256MB 64mb 60mb

slave参数代表该配置项是针对复制缓冲区的。256mb代表将缓冲区大小的上限设置为256MB；64mb和60表示如果连续60秒内的写入量超过64MB的话，就会触发缓冲区溢出，全量复制连接被关闭，全量复制失败

增加从节点

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

量同步。

无盘复制

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

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