主从复制与sentinel

主从复制与sentinel

CAP原理

CAP原理是设计和部署分布式应用时存在三个核心系统需求：consistent（一致性）、availability（可用性）、partition tolerance（分区容忍性）。一致性不知足就是多个分布式节点的数据不一致，一个节点的修改操做没法同步到另外一个节点。当网络分区（网络断开，分布式节点之间失去联系）发生时，一致性很难知足。除非牺牲可用性，就是暂停节点的服务，当网络恢复时重启。因此，网络分区发生时（集群中出现不能相互通讯的两部分，即不知足分区容忍性），一致性和可用性难以同时知足。

大多数网站的架构都是AP，放弃对一致性的严格要求。

增量同步和快照同步

redis的主从数据是异步同步的，因此并不知足一致性的要求，在主从网络断开的条件下，主节点依然能够正常对外提供修改服务，知足可用性。

主动同步（严格意义上讲分为主从同步和从从同步）主要分为增量同步和快照同步两种。

增量同步会将那些修改性指令存在本地的内存缓冲区中，而后异步的将其同步到从节点，从节点一边执行同步指令一边向主节点反馈偏移量。由于内存缓冲区是有限的，因此主库不可能装入太多指令，实际上这个缓冲区是一个环形数组，若是满了就会覆盖开始的内容。若是网络长时间断开就有可能缓冲区的指令被覆盖掉，此时就须要使用快照同步。

快照同步将主库中的内存数据所有装入磁盘中，而后将其传送到从节点，从节点拿到快照文件后清空内存而后执行全量加载。在执行快照同步时，主库的修改指令还在不断的装入buffer中，若是buffer过小或者同步时间过长都会致使buffer的数据再次被覆盖，因而又要进行快照同步，陷入死循环，因此要合理设置buffer的值以免。

当一个新节点加入集群时先来一次快照同步，再进行增量同步。

redis2.8版本中快照同步改成了无盘复制，无需写入磁盘，直接经过套接字将内容发给从节点，从节点取出写入磁盘，而后一次性完成加载。

wait指令是强行手动同步，能够设置从库个数和最多等待时间，容许无限等待。

抵抗节点故障：sentinel

sentinel的做用：监控从节点的健康（判断是否知足可用性）、进行主从切换、查询主节点的地址。

它负责监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。

客户端链接集群时首先链接sentinel，而后由其来查询主节点的地址，完成交互。客户端链接时首先查主库地址，若是发现主库地址和内存中的不同就认为主库地址改变了，客户端会断开链接与主库创建新的链接。

sentinel也能够完成主动进行主从切换，主从切换后，主库降级为从库，修改性指令在从库执行会抛出异常，而后客户端会切换链接。

在主从互换时，可能会由于网络延迟致使同步消息丢失，sentinel能够设置必须至少有x个节点正常复制，不然就失去可用性，还能够设置正常复制的标准，就是每隔x秒收到从节点的反馈就表明合格。