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

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要简单的多。所以在实际使用中应该根据自身使用情况来选择相应的服务。