分布式配置服务etcd VS 分布式协调服务zookeeper

标签: 分布 服务 etcd | 发表时间:2017-03-10 09:37 | 作者:weitao1026
出处:http://www.iteye.com

etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。

etcd 集群的工作原理基于 raft 共识算法 (The Raft Consensus Algorithm)。etcd 在 0.5.0 版本中重新实现了 raft 算法,而非像之前那样依赖于第三方库  go-raft 。raft 共识算法的优点在于可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时,也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题,仍可保证其余大多数节点正确的步进。甚至当更多的节点(一般来说超过集群节点总数的一半)出现故障而导致集群不可用时,依然可以保证节点中的数据不会出现错误的结果。

 

背景

coreOS中使用了etcd作为集群配置服务,拥有众多出色的特点,etcd是一个key,value的数据服务器,单实例可达每秒 1000 次写操作,以及方便的REST接口。 zookeeper则是在Hadoop中大放光彩的分布式协调服务,提供了分布式锁,数据同步,等服务。

从功能上看,二者都可以很好的完成集群中分布式中遇到的同步,配置问题,但是不可否认,这2种服务在设计的时候的目的不同,也让这2中服务有着不小的差异。

etcd

目的:  一个高可用的 Key/Value 存储系统,主要用于分享配置和服务发现

接口:  REST接口(HTTP+JSON)方便集群中每一个主机访问

功能:  提供了key,value存储服务,集群队列同步服务,观察一个key的数值变化,以及查询历史key值信息等

分布式协议:  Raft一致性协议。提供强一致性保证

部署形态:  采用小集群(etcd server节点组成一个集群)+大集群(其它节点来直接使用服务)的形式,集群可以达到上千节点

实现语言:  go 拥有几乎不输于C的效率,特别是go语言本身就是面向多线程,进程通信的语言。在小规模集群中性能非常突出

zookeeper

目的:  高有效和可靠的协同工作系统

接口:  基于TCP的自协议,需要安装相应客户端程序

功能:  提供了key,value存储服务,集群中简历临时节点,观察key值变化等

分布式协议:  集运Paxos一致性协议,改进的Zab协议。提供强一致性保证

部署形态:  采用小集群(zookeeper server节点组成一个集群)+大集群(其它节点来直接使用服务)的形式,集群可以达到上千节点

实现语言:  java,实现代码量要多于go,在小规模集群中性能一般,但是在大规模情况下,使用对多线程的优化后,也和go相差不大

总结:

可以看到因为设计思路的不同,在原生接口和提供服务方式方面,etcd更适合作为集群配置服务器,用来存储集群中的大量数据。方便的REST接口也可以让集群中的任意一个节点在使用key value服务时获取方便。zookeeper则更加的适合于提供分布式协调服务,他在实现分布式锁模型方面较etcd要简单的多。所以在实际使用中应该根据自身使用情况来选择相应的服务。

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [分布 服务 etcd] 推荐:

分布式配置服务etcd VS 分布式协调服务zookeeper

- - 操作系统 - ITeye博客
etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现. etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性. Raft是一个来自Stanford的新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader.

服务发现:Zookeeper vs etcd vs Consul

- - 企业架构 - ITeye博客
服务发现:Zookeeper vs etcd vs Consul. 【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口. 管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.

还不会使用分布式锁?从零开始基于 etcd 实现分布式锁

- - 掘金 后端
在单进程的系统中,当存在多个线程可以同时改变某个变量时,就需要对变量或代码块做同步,使其在修改这种变量时能够线性执行消除并发修改变量. 为了实现多个线程在一个时刻同一个代码块只能有一个线程可执行,那么需要在某个地方做个标记,这个标记必须每个线程都能看到,当标记不存在时可以设置该标记,其余后续线程发现已经有标记了则等待拥有标记的线程结束同步代码块取消标记后再去尝试设置标记.

[转]consul VS zookeeper、etcd、doozerd

- - Xiao_Qiang_的专栏
  zookeeper、doozerd、etcd都有着相似的架构,这三者的服务节点都需要一个仲裁节点来操作,它们是强一致的,并提供各种操作原语. 应用程序可以通过客户端lib库来构建分布式的系统. 在一个单datacenter中,consul的server节点工作在一种简单的方式下,consul server需要一个仲裁操作,并提供强一致性.

[原]etcd系统简介

- - 用心做事
etcd是一个分布式可靠的键值存储系统. 它提供了与ZooKeeper相似的功能,但是使用Go语言编写而不是Java语言. Etcd使用Raft协调算法而不是ZooKeeper采用的Paxos算法. 在云计算方面,Go是一个大有前景的语言,被誉为云时代的C语言. 对比与ZooKeeper,etcd更轻量级,etc更加关注一下几点:.

解读Google分布式锁服务

- XiaoHui - NoSQLfan
在2010年4月,Google的网页索引更新实现了实时更新,在今年的OSDI大会上,Google首次公布了有关这一技术的论文. 在此之前,Google的索引更新,采用的的批处理的方式(map/reduce),也就是当增量数据达到一定规模之后,把增量数据和全量索引库Join,得到最新的索引数据. 采用新的索引更新系统之后,数据的生命周期缩短了50%,所谓的数据生命周期是指,数据从网页上爬下来,到展现在搜索结果中这段时间间隔,但是正如Google所强调的,这一系统仅仅是为增量更新所建立的,并没有取代map/reduce的批量作业处理模式.

分布式服务框架:Zookeeper

- - 标点符
Zookeeper是一个高性能,分布式的,开源分布式应用协调服务. 它提供了简单原始的功能,分布式应用可以基于它实现更高级的服务,比如同步,配置管理,集群管理,名空间. 它被设计为易于编程,使用文件系统目录树作为数据模型. 服务端跑在java上,提供java和C的客户端API. Zookeeper是Google的Chubby一个开源的实现,是高有效和可靠的协同工作系统,Zookeeper能够用来leader选举,配置信息维护等,在一个分布式的环境中,需要一个Master实例或存储一些配置信息,确保文件写入的一致性等.

阿里巴巴Dubbo分布式服务框架已开源

- tangfl - ITeye论坛最新精华讨论帖
Serving services with invocations everyday, Dubbo becomes the key part of Alibaba's SOA solution and has been deployed to the whole alibaba.com family:.

分布式服务框架的4项特性

- - Tim[后端技术]
在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在. 比如一个新的项目,用PHP或JSP实现了基本功能,部署在Apache或Tomcat等容器上,在业界这种部署在一个容器内的功能模块通常可以称为一个service. 服务容器很容易通过EC2或者docker等方式来扩展部署更多的实例.

pomelo分布式聊天服务器详解

- - snoopyxdy的博客
说来也惭愧,知道pomelo框架已经一年有余了,最近因为有开发IM的需求,但却是第一次部署安装pomelo框架,对不起网易开发团队的朋友~ pomelo的wiki上有一个分布式chat聊天室的例子,开发团队写的很仔细,详细对比了传统单进程聊天服务器的弊端,并给出pomelo框架分布式聊天服务器的优势,相关wiki地址如下:.