目录

Zookeeper

1.ZK结构

2.ZK的消息广播和崩溃恢复

Nacos

1.存储和数据更新

2.注册中心

---

 

Zookeeper

1.ZK结构

Zookeeper的功能主要是通过它的树形节点来实现的，当有节点数据变化时或者说节点过期的时候会通过事件触发通知对应的客户端数据变化了，然后客户端再请求zk获取最新数据，采用push-pull来做数据更新

2.ZK的消息广播和崩溃恢复

1.Client和Server是通过NIO的方式通信的

(55条消息) NIO学习_Fairy要carry的博客-CSDN博客

(55条消息) 为什么NIO比BIO效率高_Fairy要carry的博客-CSDN博客_nio比bio优势

2.消息时FIFO方式执行的（先进先出）

3.读消息可通过zk的leader和所有follower

4.写消息必须通过leader

消息广播主要是两段机制：1.当客户端接收到请求后，follower会先将请求给到leader，2.然后我们的leader进行处理生成Proposal——>3.发送给follower（收到过半follower针对这个Proposal的消息）——>leader让follower进行提交

(55条消息) zookeeper Zab协议—消息广播_L25809的博客-CSDN博客_zk消息广播

 崩溃恢复

当leader挂了，或者超半数follower投票得出leader不可用，那么会重新选举，这段期间zk服务是不可用的。通过最新的 xid来选举出新的leader，选举出来后需要将新的leader中的数据更新给超过半数的follower节点才能对外提供服务

Nacos

Nacos的配置中心和注册中心实现的是两套代码，和Zk不同

1.存储和数据更新

Nacos：依赖Mysql数据库做数据存储，当你有数据更新的时候，直接更新数据库中的数据，然后将数据更新的信息异步广播——>给Nacos集群中所有服务节点数据变更——>再由Nacos服务节点更新本地缓存，然后将通知客户端节点数据变化

Zookeeper：利用zk的树型结构做数据存储，当有数据更新的时候使用过半机制保证各个节点的数据一致性；然后通过zk的事件机制通知客户端——>先ack给follower，转到leader，过半再提交

差异：

服务器存储位置不同，分别采用mysql和zk本身存储
消息发送，一个有采用过半机制保持一致性，另外一个异步广播，通过后台线程重试保证；

2.注册中心

(55条消息) Nacos注册中心_Fairy要carry的博客-CSDN博客_nacos注册中心

Eureka遵从AP原则，追求可用性；Zookeeper遵从CP原则，追求一致性（es也是cp，利用分片集群，每个节点有副本）；
体现在获取服务注册列表上，当ZK的master挂掉后，会触发选举，选举期间无法从ZK获取服务列表信息，这就是为了一致性放弃了可用性；Eureka则追求可用性，只存在Eureka Server，就可以获取到服务注册列表信息，但是可能获取到不是最新的，这就是为了可用性放弃了一致性