zookeeper 集群一致性原理

zk集群存在的问题？

1. 每个节点数据一致性同步问题。
2. zookeeper 如何解决分布式一致性问题
3. 后期扩展新增zk 节点需要注意哪些问题

分布式理论

强一致性:强一致性也叫做线性一致性，。所谓强一致性，即复制是同步的。也就是主库修改完数据之后，从库能立刻将对应的数据修改完成。注意:在分布式领域中不可能保证强一致性。

弱一致性:弱一致性，即复制是异步的。读取数据库数据时，如果该数据正好被修改时，主库和从库的数据允许在一段时间内存在不同，也就是可能会读取到以前的数据。

最终一致性:当用户从异步从库读取时，如果此异步从库落后，他可能会看到过时的信息。这种不一致只是一个暂时的状态——如果等待一段时间，从库最终会赶上并与主库保持一致。这称为最终一致性。

CAP与Base理论

1、C：在分布式系统中所有的数据备份，在同一时刻必须要一致；
2、A：在集群中部分节点宕机之后仍然能够保证服务可用；
3、P：分区容错，在分布式系统中网络分区存在的脑裂的问题，部分 Server 与集群其他节点失去联系，无法组成一个群体；

两者平衡： CP（保证数据一致）/AP（保证服务可用）
为什么不能保证CA？
因为服务器节点宕机之后，很难保证同一时刻数据的同步问题。

ZAB原子广播协议

Zookeeper 核心是原子广播协议（ZAB原子广播协议），这种机制保证了各个节点的数据同步的问题，ZAB协议有两种模式
，分别为恢复模式（选主Leader）和广播模式（同步数据）。

恢复模式：也就是zk 集群的leader 节点宕机之后，会重新在剩余的 follower 节点中选出新的 leader，新的leader ，也就是zookeeper集群的leader选举。

广播模式：选出之后采用广播模式实现各个节点与新的 leader 同步，使用2PC两阶段提交协议实现数据同步。

2PC两阶段提交协议

主要作用：实现各个节点数据同步
使用2PC两阶段提交协议实现数据同步过程

原理：

1. Leader 处理写事务请求（创建一个全局的zxid），zk 已经使用锁的机制对 zxid 保证了足够线程安全问题。
2. Leader 发出第一阶段通知带上 zxid 告诉每一个 Follower 和 ObServer 节点是否允许可以同步数据。
3. Leader 节点只需要接受超过半数以上的 Follower 允许同步数据的话，这时候 Leader 给 Follower 开始同步数据

zk同步数据怎么解决分布式事务问题？
答：使用2PC两阶段提交协议解决。

为什么写的请求统一交给Leader 处理？
答：利于使用2PC两阶段提交协议，从而解决zk 集群中数据一致性问题。也利于解决分布式事务问题，leader 充当协调者的角色。这样可以采用借鉴在分布式事务中2pc（两阶段提交协议）解决分布式数据同步问题。

zxid的作用？
答：全局事务id，每一次写的操作都会在原来的基础上加1，也可以用来判断哪一个 zk 节点的数据是最新的。

Zookeeper数据如何实现同步
答：

1. 所有follower节点写的请求统一交个leader实现，并且创建一个全局zxid（事务id）
2. Leader节点在第一阶段通知阶段，会带上zxid向每位follower节点发出确认同步通知
3. 只要有过半数的follower节点确认同步ack，这时候leader就会向所有的follower发出commit事务数据提交；
   这个和两阶段提交非常类似

网络抖动脑裂

在集群的情况下，一般只会选举一个master 节点，其他节点都是为从节点，那么如果网络发生抖动或者部分节点无法
实现通讯，那么就会导致部分节点重新实现选举，这样就会存在多个 master 节点。

Eureka 与 zookeeper的区别

相同点：都可以实现服务注册中心。
不同点：
zookeeper 保证CP 数据一致性问题（原理：ZAB原子广播协议），当zk 在某种情况下出现了宕机，会重新实现对 zk 选举新的领导（恢复机制），如果 zk 选举的新的领导时间过长的话，或者投票没有过半数，那么会导致整个 zk 集群环境不可用，这也意味着服务注册中心不可用，所以zk 必须保证数据一致性。

Eureka保证 ap，设计思想优先考虑可用性、完全去中心化服务注册中心，每个节点都是均等的，Eureka 集群是没有主从之分，几个节点挂掉了也不会影响整个 Eureka 的使用，Eureka 客户端发现连接时不可用的话，自动切换到下一个 eureka 连接，只要保证Eureka 有一个节点存在的话，就能保证整个服务注册中心的使用。

中心化：级别层次关系