背景

随着微服务架构盛行，也面临着分布式环境当中多个进程之间的同步控制问题, 目前常见的分布式协调方案有Apache ZooKeeper，etcd，consul 和 Hazelcast，尽管这些系统中有些不是直接的分布式协调系统，但是它们提供了有效的协调方案。在分布式协调中有两个极为出色的系统：Apache ZooKeeper 和 etcd。ZooKeeper 源于 Hadoop 生态系统，被广泛应用到各大系统中，而 etcd 则是 Google Kubernetes 使用的分布式协调方案，接下来将围绕着这两个系统展开介绍。

Apache ZooKeeper

介绍

ZooKeeper 最初是 Hadoop 的一个子项目，并发展成为 Apache Software Foundation 的顶级项目。目前，大多数 Apache 项目都在使用它，包括 Hadoop，Kafka，Solr 等等。由于其良好的跟踪记录和稳定性，ZooKeeper 已成为世界上顶级的分布式协调系统之一。

应用场景

消息发布与订阅：数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的

负载均衡：首先建立 Servers 节点，在每个服务器启动时，在 Servers 节点下建立临时子节点 Worker Server，并在该子节点下存入服务器的相关信息（IP，端口等等），在每个请求过来时从 ZooKeeper 服务器中获取当前集群服务器列表，根据自定义负载均衡算法选出其中一个服务器来处理请求，以达到负载均衡的目的

命名服务：命名服务就是提供名称的服务。ZooKeeper 的命名服务有两个应用方面，第一，提供类 JNDI 功能，可以把系统中各种服务的名称、地址以及目录信息存放在 Zookeeper，需要的时候去 ZooKeeper 中读取，第二，制作分布式的序列号生成器

分布式通知与协调：基于其临时节点的特性，不同机器在 ZooKeeper 的一个指定节点下创建临时子节点，不同机器之间可以根据这个临时节点来判断客户端机器是否存活

分布式锁：分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，一般需要通过一些互斥的手段来防止彼此之间的干扰，以保证一致性

数据模型

Zookeeper的数据模型是树结构，在内存数据库中，存储了整棵树的内容，包括所有的节点路径、节点数据、ACL信息，Zookeeper会定时将这个数据存储到磁盘上。

分布式集群

ZooKeeper 使用采用Paxos 强一致性算法实现分布式集群。为了实现高可用性，ZooKeeper 在一个集合中运行——也就是说，一组节点共同运行 ZooKeeper 工作以提供其分布式特性。这组节点被称为 ZooKeeper 集合体。一个 ZooKeeper 集合体应该总是包含奇数个节点。运行时，这些节点首先相互通信并选举一个 leader，这就是为什么 ZooKeeper 需要在奇数个节点的集合中运行。之后，其他节点被称为 Followers，而选出的节点被称为 Leader。现在连接到 ZooKeeper 的客户端可以连接到任何一个节点。客户端读取请求可以由任何节点处理，但写入请求只能由 Leader 来负责。因此，向 ZooKeeper 集合体添加更多节点将提高读取速度，但不会提高写入速度。

性能

zookeeper原本不是为高可用性设计的，选举过程速度很慢，zookeeper的选举流程通常耗时30到120秒，期间zookeeper由于没有master，都是不可用的，zookeeper的性能是有限的，典型的zookeeper的tps大概是一万多，无法覆盖系统内部每天动辄几十亿次的调用。因此每次请求都去zookeeper获取业务系统master信息是不可能的

优缺

ETCD

介绍

etcd 是用 Go 编写的 一个高可用强一致性的键值仓库，在很多分布式系统架构中得到了广泛的应用，其最经典的使用场景就是服务发现。我们将讨论最新版本的etcd（etcd v3），与之前的etcd v2相比，它有很大的变化。

应用场景

服务发现：服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。从本质上说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以进行查找和连接。

消息发布与订阅：在分布式系统中，最为适用的组件间通信方式是消息发布与订阅机制。具体而言，即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦相关主题有消息发布，就会实时通知订阅者。通过这种方式可以实现分布式系统配置的集中式管理与实时动态更新

负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。这样的实现虽然会导致一定程度上数据写入性能的下降，但是却能实现数据访问时的负载均衡。因为每个对等服务节点上都存有完整的数据，所以用户的访问流量就可以分流到不同的机器上

分布式通知与协调：这里讨论的分布式通知与协调，与消息发布和订阅有些相似。两者都使用了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更进行实时处理。实现方式通常为：不同系统都在etcd上对同一个目录进行注册，同时设置Watcher监控该目录的变化（如果对子目录的变化也有需要，可以设置成递归模式），当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并作出相应处理

分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

数据模型

etcd 设计用于可靠存储不频繁更新的数据，并提供可靠的观察查询，ectd 使用多版本持久化键值存储来存储数据。当键值对的值被新的数据替代时，持久化键值存储保存先前版本的键值对。键值存储事实上是不可变的;它的操作不会就地更新结构，替代的是总是生成一个新的更新后的结构。为了缓解压力，etcd会定期进行压缩，清理过旧的数据。存储的逻辑视图是一个扁平的二进制键空间。键空间有一个在 byte string 键上的语义排序的索引，因此范围查询不是太昂贵。ETCD采用B树索引加速查询，存储的状态的每个修订版本仅仅包含和它的前一个修订版本的增量以求高效。单个修订版本可能对应到 tree 上的多个 key。在查询时，先在内存索引中通过用户指定的Key值，查找到该Key值对应的全部版本号，然后根据用户指定的版本号，从底层存储中查找到具体的Value值。在etcd v3版本中，底层存储使用的是BoltDB，其中的Key是版本信息（main revision+subrevision）。这样，在查询时先通过上述B树索引查询到对应的版本信息，然后在BoltDB中通过版本信息查找相应的Value值

分布式集群

ETCD 采用 raft 一致性算法，基于 Go 语言实现。etcd作为一个高可用键值存储系统，天生就是为集群化而设计的。由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群，Raft算法将Server分为三种类型：Leader、Follower和Candidate。Leader处理所有的查询和事务，并向Follower同步事务。Follower会将所有的RPC查询和事务转发给Leader处理，它仅从Leader接受事务的同步。数据的一致性以Leader中的数据为准实现。在节点初始启动时，节点的Raft状态机将处于Follower状态等待来来自Leader节点的心跳。如果在一定时间周期内没有收到Leader节点的心跳，节点将发起选举。Follower节点选举时会将自己的状态切换为Candidate，然后向集群中其它Follower节点发送请求，询问其是否选举自己成为Leader。当收到来自集群中过半数节点的接受投票后，节点即成为Leader，开始接收Client的事务处理和查询并向其它的Follower节点同步事务。Leader节点会定时向Follower发送心跳来保持其地位。众所周知的 Google 的容器编排平台 Kubernetes 使用 etcd v2 作为分布式存储来获取其 master 组件的分布式锁。这是 etcd 功能强大的一个例子。

性能

etcd 提供稳定的，持续的高性能。两个定义性能的因素：延迟(latency)和吞吐量(throughput)。延迟是完成操作的时间。吞吐量是在某个时间期间之内完成操作的总数量。当 etcd 接收并发客户端请求时，通常平均延迟随着总体吞吐量增加而增加。在通常的云环境，比如 Google Compute Engine (GCE) 标准的 n-4 或者 AWS 上相当的机器类型，一个三成员 etcd 集群在轻负载下可以在低于1毫秒内完成一个请求，并在重负载下可以每秒完成超过 30000 个请求。

优缺

总结

etcd 实现的这些功能，ZooKeeper 都能实现。那么为什么要用 etcd 而非直接使用 ZooKeeper 呢？

Zookeeper缺点：

1. 复杂：ZooKeeper 的部署维护复杂，管理员需要掌握一系列的知识和技能；而 Paxos 强一致性算法也是素来以复杂难懂而闻名于世；另外，ZooKeeper 的使用也比较复杂，需要安装客户端，官方只提供了 Java 和 C 两种语言的接口。和Raft算法相比，有点过度设计了，解决的是一个标准的拜占庭问题，不仅仅可以处理节点故障问题，还可以防止节点作弊。代价是消息交互的次数大大增加

2. java 编写：这里不是对 Java 有偏见，而是 Java 本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单，维护起来也不易出错。

3. 发展缓慢：Apache 基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。

Etcd3优点:

1. 简单：使用 Go 语言编写部署简单；使用 HTTP 作为接口使用简单；使用 Raft 算法保证强一致性让用户易于理解。

2. 数据持久化：etcd 默认数据一更新就进行持久化。

3. 安全：etcd 支持 SSL 客户端安全认证。

最后，etcd 作为一个年轻的项目，真正告诉迭代和开发中，这既是一个优点，也是一个缺点。优点是它的未来具有无限的可能性，缺点是无法得到大项目长时间使用的检验。然而，目前 CoreOS、Kubernetes 和 CloudFoundry 等知名项目均在生产环境中使用了 etcd，所以总的来说，etcd 值得你去尝试。

推荐阅读

更多内容查看公众号，请关注同名公众号

ZooKeeper vs. Etcd3

Java vs. Python

Redis vs. Memcached