CAP原理是设计和部署分布式应用时存在三个核心系统需求：consistent（一致性）、availability（可用性）、partition tolerance（分区容忍性）。一致性不满足就是多个分布式节点的数据不一致，一个节点的修改操作无法同步到另一个节点。当网络分区（网络断开，分布式节点之间失去联系）发生时，一致性很难满足。除非牺牲可用性，就是暂停节点的服务，当网络恢复时重启。所以，网络分区发生时（集群中出现不能相互通信的两部分，即不满足分区容忍性），一致性和可用性难以同时满足。
大多数网站的架构都是AP，放弃对一致性的严格要求。
redis的主从数据是异步同步的，所以并不满足一致性的要求，在主从网络断开的条件下，主节点依然可以正常对外提供修改服务，满足可用性。
主动同步（严格意义上讲分为主从同步和从从同步）主要分为增量同步和快照同步两种。
增量同步会将那些修改性指令存在本地的内存缓冲区中，然后异步的将其同步到从节点，从节点一边执行同步指令一边向主节点反馈偏移量。因为内存缓冲区是有限的，所以主库不可能装入太多指令，实际上这个缓冲区是一个环形数组，如果满了就会覆盖开始的内容。如果网络长时间断开就有可能缓冲区的指令被覆盖掉，此时就需要使用快照同步。
快照同步将主库中的内存数据全部装入磁盘中，然后将其传送到从节点，从节点拿到快照文件后清空内存然后执行全量加载。在执行快照同步时，主库的修改指令还在不断的装入buffer中，如果buffer太小或者同步时间过长都会导致buffer的数据再次被覆盖，于是又要进行快照同步，陷入死循环，所以要合理设置buffer的值以避免。
当一个新节点加入集群时先来一次快照同步，再进行增量同步。
redis2.8版本中快照同步改为了无盘复制，无需写入磁盘，直接通过套接字将内容发给从节点，从节点取出写入磁盘，然后一次性完成加载。
wait指令是强行手动同步，可以设置从库个数和最多等待时间，允许无限等待。
sentinel的作用：监控从节点的健康（判断是否满足可用性）、进行主从切换、查询主节点的地址。
它负责监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。
客户端连接集群时首先连接sentinel，然后由其来查询主节点的地址，完成交互。客户端连接时首先查主库地址，如果发现主库地址和内存中的不一样就认为主库地址改变了，客户端会断开连接与主库建立新的连接。
sentinel也可以完成主动进行主从切换，主从切换后，主库降级为从库，修改性指令在从库执行会抛出异常，然后客户端会切换连接。
在主从互换时，可能会因为网络延迟导致同步消息丢失，sentinel可以设置必须至少有x个节点正常复制，否则就失去可用性，还可以设置正常复制的标准，就是每隔x秒收到从节点的反馈就代表合格。
原文：https://www.cnblogs.com/shizhuoping/p/11523922.html