Nacos对比Zookeeper、Eureka之间的区别

一、CAP定律

CAP定律是指的是在一个分布式系统中、Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

  • 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
  • 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
  • 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。
  • 在分布式系统中网络会存在脑裂的问题,部分Server与整个集群失去节点联系,无法组成一个群体。只有在AP和CP选择一个平衡点

二、Eureka与Zookepper对比

1、相同点

  • 都可以实现分布式服务注册中心

2、不同点

  • Zookeeper采用CP保证数据的一致性的问题,原理采用Zab原子广播协议,当zk领导因为某种原因宕机的情况下,会自动触发重新选一个新的领导角色,整个选举的过程为了保证数据的一致性问题,在选举的过程中整个zk环境是不可使用的可短暂可能无法使用到zk。意味着微服务采用该模式情况下,可能无法实现通讯(本地有缓存除外)。注意:可运行的节点必须满足过半机制,整个zk采用使用。
  • Eureka采用AP的设计理念架构注册中心,完全去中心化思想,也就是没有主从之分。每个节点都是均等,采用相互注册的原理,你中有我我中有你,只要最后有一个eureka节点存在就可以保证整个微服务可以实现通讯。

在使用注册中心,可用性在优先级最高,可以读取数据短暂不一致性,但是至少要能够保证注册中心可用性。

三、Nacos与Eureka的区别

1、定律的区别

  • Eureka采用AP模式形式实现注册中心。
  • Nacos默认采用AP模式。在1.0版本之后采用AP+CP模式混合实现注册中心。

2、Eureka与Nacos底层实现集群协议

  • 去中心化对等。
  • Raft协议实现集群产生领导角色。

3、Raft:分布式一致性协议的算法

  • 分布式系统一致性算法 应用于系统软件实现集群保持每个节点数据的同步性。
  • 保持我们的集群中每个节点的数据的一致性的问题,专业的术语分布式一致性的算法。
  • 场景:Redis集群、nacos集群、mongdb集群等。

4、大多的注册中心都是AP

  • CP情况下:虽然我们服务不能用,但是必须要保证数据的一致性
  • AP情况下:可以短暂保证数据不一致性,但是最终可以一致性,不管怎么样,要能够保证我们的服务可用

四、ZAB(Zookeeper Atomic Broadcast)协议集群原理

在分布式系统,存在多个系统之间的集群保持数据一致性,采用CP一致性算法保持数据的一致性问题。Zookeeper基于ZAB协议实现保持每个节点的数据同步的问题,中心化思想集群模式;分为领导和跟随角色。

Nacos对比Zookeeper、Eureka之间的区别插图

1、在程序中如何取决某个节点能力比较强

  • 对每个节点配置一个myid或者serverid还有数值越大表示能力越强或者随机时间
  • 整个集群中为了保持数据的一致性的问题,必须满足过半可运行的节点环境下才可以使用
  • ZAB的协议实现原理事通过比较myid,myid谁最大谁就是为可能是领导角色,只要满足过半的机制就可以成为领导角色,后来启动的节点不会参与选举的。

2、Zab协议如何保持数据的一致性问题

所有写的请求统一交给领导角色实现,领导角色写完数据之后,领导角色再将数据同步给每个节点。注意:数据之间同步采用2pc两个阶段提交协议。

1)选举过程
  • 先去比较zxid, zxid谁最大谁就是为领导角色
  • 如果zxid相等的情况下,myid谁最大谁就为领导角色
2)如果领导角色在同步过程中宕机了怎么办?
  • 如果有同步完成的从机,那么会在从机里面选
  • 如果都没有,那么就重新选举

五、Raft协议选举的基本概念

1、Raft协议算法

  • 1、状态:分为三种 跟随者、竞选者(候选人)、领导角色
  • 2、大多数:>=n/2+1 3/2=1+1=2
  • 3、任期:每次选举一个新的领导角色,任期都会实现增加
  • 4、竞选者谁的票数最多,谁就是为领导角色

存在的疑问

  • 多个竞选者,产生的票数都完全一样,这到底谁是领导角色?
  • ​ 当集群节点总数,如果是奇数情况下,就算遇到了该问题也不用担心。
  • 当节点是偶数的情况下,可能会存在该问题,如果两个竞选者获取的票数相等的情况下,开始重置竞选的超时时间,一直到谁的票数最多谁就为领导。

2、默认情况下选举的过程

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

核心的设计原理:谁超时时间最短,谁就有非常大的概率为领导角色。

那么在随机数有可能一样的情况下,如何选举呢?

  • 1、如果所有的节点的超时随机数都是一样的情况下,当前投票全部作废,重新进入随机生成超时时间。
  • 2、如果有多个节点生成的随机数都是一样的情况下,比较谁的票数最多,谁就是领导。如果票数完全一样的情况,直接作废,重新进入随机生成超时时间。
  • 注意:建议集群节点为奇数。偶数节点容易造成死循环。

3、故障重新实现选举

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

数据是如何保持一致性的?类似于ZAP两阶段提交协议。

如何实现日志的复制:

  • 1、所有的写的请求都是统一的交给领导角色完成,写入该对应的日志,标记该日志为被提交状态。
  • 2、为了提交该日志,领导角色就会将该日志以心跳的形式发送给其他的跟随者节点,只要满足过半的跟随者节点写入该目志,则直接通知其他的跟随者节点同步该数据,这个过程称为日志复制的过程。

发表评论