Nacos、Eureka与Zookeeper区别

---

CAP定律

CAP定律的内容指的是在一个分布式系统中、Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
C：在分布式系统中，服务器集群的每个节点在同时刻访问必须要保持数据的一致性；
A：集群节点中，部分节点出现故障后仍然可以使用（高可用性）；
P：在分布式系统中网络会存在脑裂的问题，部分Server与整个集群失去节点联系，无法组成一个群体。
只有在CP和AP中选择一个平衡点。
CP情况下：虽然服务不能用，但是必须要保证数据的一致性；
AP情况下：可以短暂保证数据不一致性，但是最终可以一致性，不管怎么样都要保证服务的可用。

什么情况下选择CP和AP呢?

必须要求读取接口的地址保证强一致性的问题，则可以采用CP模式；
一般情况下采用AP模式就可以。

相同点：

都可以实现分布式注册中心框架

不同点：

Zookeeper采用CP保证数据的一致性的问题，原理是采用ZAB（原子广播）协议。
当Zk领导者宕机或出现故障时，会自动重新实现选举新的领导角色，整个选举的过程中为了保证数据一致性的问题，客户端暂时无法使用Zookeeper，这就意味着整个微服务无法实现通讯（本地有缓存除外）。
注意：可运行的节点必须满足过半机制

Eureka采用AP实现分布式注册中心，完全去中心化、每个节点都是相等的，采用你中有我、我中有你相互注册设计思想，只要最后有一台Eureka节点存在，整个微服务就可以实现通讯。
中心化：必须围绕一个领导角色作为核心，选举为领导和跟随者角色；
去中心化：每个角色都是均等的。

Nacos从1.0版本选择AP和CP混合形式实现注册中心，默认情况下采用AP，CP则采用Raft协议实现数据的一致性。
如果选择为AP模式，注册服务的实例仅支持临时模式，在网络分区产生了抖动的情况下，允许注册服务实例；
如果选择CP模式，可以支持注册服务的实例为持久模式，在网络分区产生了抖动的情况下，不允许注册服务实例。

常见的分布式一致性算法：

1. ZAB协议（原子广播协议）底层就是基于Paxos实现，核心底层基于2PC两阶段提交协议实现。
2. Nacos中集群保证一致性算法采用Raft协议模式，采用心跳机制实现选举的。

ZAB整个底层实现原理：

Zookeeper Atomic Boradcast（原子广播协议）
Zookeeper基于ZAB协议实现保持每个节点的数据同步，中心化思想集群模式，分为领导和跟随者角色。
● 在程序中如何取绝某个节点能力比较强?
对每个节点配置一个myid或者serverid，数值越大表示能力越强；
对整个集群中为了保持数据的一致性的问题，必须满足大多数情况 > n/2 + 1 可运行的节点环境才可以使用；
ZAB的协议实现原理是通过比较myid谁最大，谁就可能成为领导角色，只要满足过半机制就可以成为领导角色，后来启动的节点不会参与选举。

● 如何保持数据的一致性问题?
所有的写的请求统一交给领导角色实现，领导角色写完数据后，领导角色再将数据同步到每个节点。
注意：数据之间同步采用2PC两阶段提交协议。

● 选举过程：
先去比较zxid谁最大谁就是领导角色；
如果zxid相等的情况下，myid谁最大谁就是领导角色。

● 如果领导角色在同步过程中宕机了怎么办?
如果有同步完成的从机，那么会在从机里选；
如果都没有，那么就重新选举。

Raft整个底层实现原理：

1. 分为了三种角色：跟随者、竞选者、领导；
2. 过半机制： n/2 + 1；
3. 每次选举一个新的领导角色，任期都会增加；
4. 竞选者谁的票数最多，谁就是领导角色。

默认情况下选举的过程：
a. 默认情况下每个节点都是跟随者角色；
b. 每个节点随机生成一个选举的超时时间，大概为100-300ms，在这个超时时间内必须要等待。
c. 超时时间过后，当前节点的状态由跟随者变为竞选者状态，会给其他节点发出选举的投票通知，只要该竞选者有超过半数以上即可选为领导角色。

核心的设计原理就是谁超时时间最短谁成为领导角色的概率就最大。

● 故障的重新实现选举：
如果跟随者节点不能够及时的收到领导角色消息，那么这时候跟随者就会将当前自己的状态由跟随者变为京选择角色，会给其他节点发出选举的投票通知，只要该竞选者有超过半数以上即可选为领导角色。

疑问：是否可能会产生两个同事的竞选者呢?
a. 如果所有的节点的超市随机数都一样的情况下，当前投票全部作废，重新进入随机生成超时时间；
b. 如果有多个节点生成的随机数都是一样的情况下，比较谁的票数最多，谁就是领导。如果票数完全一样的情况下，直接作废，重新进入随机生成超时时间。
注意：建议集群节点为奇数，偶数节点容易造成死循环。

● 如何实现日志的复制：
a. 所有的写的请求都是统一交给领导角色完成，写入该对应的日志，标记该日志为被提交状态；
b. 为了提交该日志，领导角色就会将该日志以心跳的形式发送给其他的跟随者节点，只要超过半数的跟随者节点写入该日志，则直接通知其它跟随者节点同步该数据，这个过程称为日志复制的过程。

---