Zookeeper_CAP原则

标签：节点   data   必须   可用性   exp   节点数据   and   就是   客户端   

CAP原则

简单介绍CAP

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

• 一致性（Consistency）

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

• 可用性（Availability）

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

• 分区容错性（Partition tolerance

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

三二原则

对于分布式系统，在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原则，牺牲了一致性，但是保证了可用性

Zookeeper_CAP原则

标签：节点   data   必须   可用性   exp   节点数据   and   就是   客户端   

原文地址：https://www.cnblogs.com/msi-chen/p/11048553.html