etcd VS zookeeper

背景

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