zookeeper基础介绍

zookeeper是分布式系统中常用的数据管理应用。它本身也是分布式服务。

学习zookeeper除了会使用它提供的API外，还需要对它的底层实现原理有个大概的认识。

三个重要的数据

zxid：这是一个64位的Long型数据，高32位是epoch，低32位是xid

epoch：这是每个leader选举结束后都会生存一个新的epoch，并通知给集群中所有其他server，包含所有的follower、observer。可以理解为年号。

xid：事务流水号，每个leader的修改操作都会生成一个新的xid，并将其广播给集群中的所有其他server，这个ID只会增加。

当集群中的leader宕机，新leader的选举会取xid最大的（保证已经修改的操作不会丢失），如果xid相同，则比较serverId。

zookeeper的数据同步

leader节点接收到事务后，会生成一个自增的zxid。然后将事务封装成一个一个Proposal发送给给所有的follower（leader中有个follower列表）

follower收到Proposal后，会将其中的zxid与本地日志中最大的zxid进行比较，如果该zxid大于follower本地的zxid，那么会将该zxid保存在本地日志中。并给leader返回一个ack。

leader收到数量大于一半的ACK后，会向follower发送COMMIT消息、向observer发送proposal。

follower收到COMMIT消息后，会将事务更新到本地。同样Observer收到proposal后会直接将事务更新到本地。

ABA问题（解释数据同步的时候为什么会比较ZXID）

leader向follower发送了事务A（例如：将数据改成5）、B（例如：将数据改成8）去修改同一份数据。

先发送的事务A，但是由于网络问题事务A发送给其中一个follower的时候卡主了，后发送的事务B，先于事务A更新到follower本地，修改了数据。之后事务A才到达，又会修改数据。这导致了数据最终错误。

由于每次都会比较zxid，事务B的zxid大于事务A的zxid，事务A的会被丢掉，所以这种问题不会存在.

ABA问题丢事务A问题解决

zxid比较解决了同一份数据网络原因造成数据被覆盖的问题，但是如果事务A、事务B修改的是不同数据。事务A后到达被丢弃，那么岂不是就会造成数据不一致？

其实不是，当事务zxid最大的事务完成后，follower会进行递归，与leader比较【zxid-1】的事务中数据事务是否相同。如果不相同(或者follower不存在该zxid的事务)，则从leader同步到本地，再比较【zxid-1-1】的事务。如果相同，则退出。

CAP定理

C（Consistency）：一致性。分布式系统中，各节点之间数据是否一致。即：当系统数据变化后，各节点的数据仍然处于一致性状态。

A（Availability）：可用性。每个服务必须一致处于可用状态。即：对于用户的没一个请求，都能在有限的时间内做出响应。

P（Partition tolerance）：分区容错性。分布式系统遇到网络分区故障时，仍然能够对外提供满足一致性和可用性的服务。

分布式系统中CAP定理是无法全都满足的，一般根据业务需求满足其中的两个：CP、AP。zookeeper满足了CP（一致性、分区容错性）：

         1.当leader挂掉、重新选举的阶段，zookeeper集群是不对外提供服务的。zookeeper选举时长一般是200毫秒，一般不超过60秒。

         2.客户端的事务请求（节点变化），zookeeper集群同步数据的期间也是不提供服务的，只是这个时间很短。

eureka满足了AP

BASE理论

BA（Basiclly Available）：基本可用。当分布式基本出现不可预知的故障时，允许损失部分可用性。保证重要功能可用的前提下，允许部分功能不可用。

S（Soft state）：软状态。允许数据同步的过程存在一定延时。

E（Eventually consistent）：最终一致性。数据副本，在经过一段时间后，最终能达到一致的状态。

zookeeper中的三个原则

Leader的主动出让原则：当leader发现心跳检测出的follower少于半数的时候，会觉得自己网络存在问题，将状态改为LOOKING

已被处理过的消息不能丢：当leader的事务（leader写数据完成）并同步给了一个follower，同时leader挂了，那么新选出的leader肯定是xid最大的，所以不会丢失。

被丢弃的消息不能再现：当leader的事务完成，但是数据并没有同步给任何一个follower，那么leader挂后，又重新加入节点，此时leader的这条数据（xid号相同）会被覆盖（会根据leader的数据进行同步）

 

zookeeper中的脑裂

zookeeper集群是存在脑裂问题的。即：当出现故障的时候（例如网络连接问题），一个集群产生大于1个的leader。此时，会出现数据不一致问题。但脑裂是短暂的。

举例：zookeeper集群部署在机房：A、B、C，leader存在A机房。当B机房与A机房之间的网络断了。此时，B机房的节点状态都是LOOKING，不会对外提供服务。但是A、C机房是正常的，可以提供服务。接着A、C之间网络断了，那么B、C机房会重新选举出一个leader，而A机房的leader也也正常的。此时B、C机房可以对外提供读写服务，A机房能提供短暂的读服务（因为节点不过半，无法通过写操作），且存在两个leader。这就是脑裂现象。