概述
CAP是Consistency、Availablity和Partition Tolerance的缩写。一般的分布式系统最多满足其中两条。而Partition Tolerance是分布式系统的关键,因此都会保留此特性。
Eureka是基于AP原则构建的,而ZooKeeper是基于CP原则构建的。这些可以从他们的特性中得到体现。
ZK有一个Leader,而且在Leader无法使用的时候通过Paxos(ZAB)算法选举出一个新的Leader。这个Leader的目的就是保证写信息的时候只向这个Leader写入,Leader会同步信息到Followers。这个过程就可以保证数据的一致性。
对比下ZK,Eureka不用选举一个Leader。每个Eureka服务器单独保存服务注册地址,Eureka也没有Leader的概念。这也因此产生了无法保证每个Eureka服务器都保存一直数据的特性。当Eureka与注册者心跳无法保持的时候,依然保存注册列表的信息很长一段时间。当然了,客户端中必须用有效的机制屏蔽坏掉的服务器,这个Spring Cloud中的体现是Ribbon。
Eureka因为没有选举过程来选举Leader,因此写的信息可以独立进行。因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候,每台服务器也可以完成独立的服务。当然了,一些客户端的负载平衡和Fail Over机制需要来辅助完成额外的功能。相较之下,ZK因为基于CP原则,能保证很好的数据一致性,但是可用性支持力度不高。而在一个内部系统中,主要是服务的注册与发现,而不是配置(文件)共享,因此Eureka更适用于内部服务的建设。
最后
以上就是欢喜泥猴桃为你收集整理的SOA之路 -- 为什么Eureka比ZooKeeper更适合做服务发现与注册服务的全部内容,希望文章能够帮你解决SOA之路 -- 为什么Eureka比ZooKeeper更适合做服务发现与注册服务所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复