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

标签: 服务 etcd vs | 发表时间:2017-03-10 01: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 vs] 推荐:

服务发现:Zookeeper vs etcd vs Consul

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

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

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

[转]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更加关注一下几点:.

转 redis vs memcached

- - 数据库 - ITeye博客
传统MySQL+ Memcached架构遇到的问题.   实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:.   1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间.

NOSQL数据库大比拼:Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase

- - 博客园_Ruby's Louvre
话说,尽管 SQL 数据库一直是我们IT行业中最有用的工具,然而,它们这样在行业中超过15年以上的“转正”终于就要寿终正寝了. 现在,虽然关系型数据库仍然无所不在,但它越来越不能满足我们的需要了. 但是,各种 "NoSQL" 数据库之间的差异比当年众多关系型数据库之间的差异要大许多.

普通 vs 文艺 vs 二逼

- 貝殼 - The Only Exception

学界 vs. 商界

- Yuli - 科学松鼠会
汉化: Oicebot & Ent. 0x5f375a86来自一个传奇算法,出自John Carmack开发的《雷神之锤3》的3D引擎. 这个引擎的源代码里包括一个反平方倒数的算法,其速度要比标准的牛顿迭代法快上几十倍,而其中的关键是一行神秘的代码和一个莫名其妙的数字:[ i   = 0x5f3759df - ( i >> 1 ); // what the fuck.

颈椎vs坐姿

- nanoac - 小步的漫画日记