Zookeeper_CAP原则

CAP原则

简单介绍CAP

• 想要进行分布式事务控制，CAP理论是我们必须要知道的；

CAP原则：也叫CAP定理，指的是在一个分布式系统中，一致性、可用性、分区容错性三者不可兼得

• 一致性（Consistency）

  分布式系统中的所有主机在同一时刻是否可以保证具有完全相同的数据备份，若具有，则该分布式系统具有一致性

• 可用性（Availability）

  在集群中，部分节点发生故障后，是否会影响对客户端读写请求的响应，注意，若在短时间内会影响，其也不具有这里说说的"可用性"

• 分区容错性（Partition tolerance

  分布式系统中的一台主机称为一个分区，分布式系统中各个主机无法保证数据的一致性，即不具有一致性是一种错误；分布式系统无法及时响应客户端请求，即不具有可用性也是一种错误；对于分布式系统，必须要具有对这些错误的"包容性",即容错性，这是必须得

• 为什么不能面面俱到

上面已经说明，分区容错性是分布式系统必须考虑的，此外，当我们想要保证高可用的时候，无非就是增加很多的节点，高可用的确是满足了，但带来的问题是，这么多的节点之间的数据同步是一个很多的消耗，极其容易造成数据不一致，当我们强调一致性的时候，节点越少，数据同步的消耗就小，但带来的节点少却又造成服务的可用性差，所以一致性和可用性是不可兼顾的，他们处于一个对立面；

• CAP的组合

CA ：不是分布式架构，就使用这种，关系数据库按照CA进行设计 ，放弃分区容错性，因为没有分区呀！！

AP：加强可用性和分区容错性,放弃立即一致性（强一致性），追求最终一致性，比如Eureka

• 比如微信提现，提示两个小时到账，而不是马上到账

CP：强调强一致性和分区容错性，放弃可用性，比如Zookeeper,master在宕机后选举Leader期间不提供服务

• 比如跨行转账，就是立即到账，你这边转出，那边收进，方认为一个事务才算完成

简单说说：先说结论，在分布式系统中AP运用的最多，因为他放弃的是强一致性，追求的是最终一致性，性价比最高，比如12小时内退款，微信2小时内提现到账，只要在用户的可接受范围内，保证一致性即可

三二原则

对于分布式系统，在CAP原则中分区容错性P是必须保证的，但其并不能同时保证一致性和可用性，因为现在的分分布式系统在满足一致性的前提下，会牺牲可用性，在满足了可用性的前提下，会牺牲一致性，所以CAP原则对于一个分布式系统来说，只可能满足两项，要么CP，要么AP，这就是CAP的三二原则

ZK与CP的缘分

ZK遵循的是CP原则，即一致性和分区容错性，牺牲了可用性，具体牺牲在哪里呢？

当Leader宕机以后，集群机器马上会进去到新的Leader选举中，但是选举时长在30s — 120s之间，这个选取Leader期间，是不提供服务的，不满足可用性，所以牺牲了可用性

经过上面的简单讲解，会射门选举时长会长达半分钟到2分钟呢？

当然是为了保证一致性，为了保证集群中各个节点数据的一致性，ZK做了两类数据同步，初始化同步和更新同步。

• 1：当新的Leader选举出来后，各个Follower需要将新的Leader的数据同步到自己的缓存中，这就是初始化同步

• 2：当Leader数据被客户端修改后，其会向Follower发出广播，然后各个Follwer会竹筒去同步更新的数据，这是更新同步

无论是初始化同步还是更新同步，ZK集群为了保证数据的一致性，若发现超过半数的Follower同步超时，则其会再次进行同步，而这个过程中ZK集群同样出去不可用状态

由于ZK采用的是CP原则，所以其可用性降低，这是其致命的问题，Spring Cloud集成的Eureka采用的就是AP原则，牺牲了一致性，但是保证了可用性