- C - Consistent ，一致性
- A - Availability ，可用性
- P - Partition tolerance ，分区容忍性
- 分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有 网络断开的风险，这个网络断开的场景的专业词汇叫着「网络分区」。
- 在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操 作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的 数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务，在网络分区发 生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。
- 网络分区发生时，一致性和可用性两难全。
- Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足「一致性」要求。
- Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节 点依旧可以正常对外提供修改服务，所以 Redis 满足「可用性」。
- Redis 保证「最终一致性」，从节点会努力追赶主节点，最终从节点的状态会和主节点 的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢 复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。
- Redis 同步支持主从同步和从从同步，从从同步功能是 Redis 后续版本增加的功能，为 了减轻主库的同步负担。
- Redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本 地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指 令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了 (偏移量)。
- 因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆 盖前面的内容。
- 如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢 复时，Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉 了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制 — — 快照同步。
- 快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当前内 存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完 毕后通知主节点继续进行增量同步。
- 在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同 步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆 盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有 可能会陷入快照同步的死循环。
- 所以务必配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。
- 当从节点刚刚加入到集群时，它必须先要进行一次快照同步，同步完成后再继续进行增量同步。
- 主节点在进行快照同步时，会进行很重的文件 IO 操作，特别是对于非 SSD 磁盘存储 时，快照会对系统的负载产生较大影响。
- 所谓无盘复制是指主服务器直接通过套接字 将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序 列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中， 再进行一次性加载。
- Redis 的复制是异步进行的，wait 指令可以让异步复制变身同步复制，确保系统的强一 致性 (不严格)。
- wait 提供两个参数，第一个参数是从库的数量 N，第二个参数是时间 t，以毫秒为单 位。它表示等待 wait 指令之前的所有写操作同步到 N 个从库 (也就是确保 N 个从库的同 步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到 N 个从库同步完成达成 一致。
如果你将 Redis 只用来做缓存，跟 memcache 一样来对 待，也就无需要从库做备份，挂掉了重新启动一下就行。但是只要你使用了 Redis 的持久化 功能，就必须认真对待主从复制，它是系统数据安全的基础保障。