Nacos对比Zookeeper、Eureka之间的区别

CAP定律

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

一致性(C):在分布式系统中,如果服务器集群,每个节点在同时刻访问必须要保持数据的一致性。

可用性(A):集群节点中,部分节点出现故障后任然可以使用 (高可用)

分区容错性(P):在分布式系统中网络会存在脑裂的问题,部分Server与整个集群失去节点联系,无法组成一个群体。
只有在CP和AP选择一个平衡点

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

Nacos与Zookeeper,Eureka区别

相同点:三者都可以实现分布式注册中心框架

不同点:
Zookeeper采用CP保证数据的一致性的问题,原理采用(ZAP原子广播协议),当我们ZK领导者因为某种情况下部分节点出现了故障,会自动重新实现选举新的领导角色,整个选举的过程中为了保证数据一致性的问题,客户端暂时无法使用我们的Zookeeper,那么这以为着整个微服务无法实现通讯。
注意:可运行的节点必须满足过半机制,整个zk采用使用。

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

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

什么情况下选择cp和ap呢

必须要求读取接口的地址保证强一致性的问题,可以采用cp模式, 一般情况下采用ap就可以了

常见分布式一致性算法:

  1. ZAP协议(底层就是基于Paxos实现),核心底层基于2PC两阶段提交协议实现。

  2. Nacos中集群保证一致性算法采ratf协议模式,采用心跳机制实现选举的。

Zap整个底层实现原理

Zookeeper基于ZAP协议实现保持每个节点的数据同步,中心化思想集群模式,分为领导和跟随者的角色

  • 在程序中如何成为某个节点能力比较强:
    对每个节点配置一个myid或者serverid, 数据越大表示能力越强
    整个集群中为了保持数据的一致性的问题,必须满足大多数情况 >n/2+1 可运行的节点环境才可以使用
    ZAP的协议实现原理是通过比较myid谁最大,谁就是可能领导角色,只要满足过半的机制就可以成为领导角色,后来启动的节点不会参与选举。

  • 如何保持数据的一致性的问题
    所有的写的请求统一交给我们的领导角色实现,领导角色写完数据之后,领导角色再将数据同步给每个节点
    注意:数据之间同步采用2pc两阶段提交协议

  • 选举过程:
    先去比较zxid谁最大谁就是领导角色
    如果zxid相等的情况下,myid谁最大谁就为领导角色;

image.png

Ratf整个底层实现原理:

在Raft协议中分为的角色

1.状态:分为三种 跟随者、竞选者、领导

2.大多数: >n/2+1

3.任期:每次选举一个新的领导角色 任期都会增加。

默认情况下选举的过程:

  1. 默认的情况下每个节点都是为跟随者角色

  2. 每个节点随机生成一个选举的超时时间 大概分为100-300ms,在这个超时时间内必须要等待。

  3. 超时时间过后,当前节点的状态由跟随者变为竞选者角色,会给其他的节点发出选举的投票的通知,只要该竞选者有超过半数以上即可选为领导角色。

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

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

疑问:是否可能会产生两个同时的竞选者呢,同时实现拉票呢?

注意当我们的集群节点总数,如果是奇数情况下 就算遇到了该问题也不用担心。

当我们的节点是为偶数的情况下,可能会存在该问题,如果两个竞选者获取的票数相等的情况下,开始重置竞选的超时时间,一直到谁的票数最多谁就为领导。

  • 如何实现日志的复制
  1. 所有的写的请求都是统一的交给我们的领导角色完成,写入该对应的日志,标记该日志为被提交状态。

  2. 为了提交该日志,领导角色就会将该日志以心跳的形式发送给其他的跟随者节点,只要超过跟随者节点写入该日志,则直接通知其他的跟随者节点同步该数据,这个过程称做为日志复制的过程。

本文参考蚂蚁课堂:http://www.mayikt.com/#

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,290评论 6 491
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,107评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,872评论 0 347
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,415评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,453评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,784评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,927评论 3 406
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,691评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,137评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,472评论 2 326
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,622评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,289评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,887评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,741评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,977评论 1 265
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,316评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,490评论 2 348

推荐阅读更多精彩内容