第二部分 

实战篇

本部分着重讲解etcd的常见功能及使用场景，包括etcd的架构分析、命令行使用、API调用、运维部署等内容，主要包括以下章节：

第2章　为什么使用etcd

第3章　etcd初体验

第4章　etcd开放API之v2

第5章　etcd开放API之v3

第6章　etcd集群运维与稳定性

第7章　etcd安全

第2章

为什么使用etcd

       开发分布式系统是一件比较困难的事情，其中的困难主要体现在分布式系统的“部分失败”上。“部分失败”是指信息在网络的两个节点之间传送的时候，网络出现了故障，发送者无法知道接收者是否收到了这个信息，而且导致这种故障的原因很复杂，接收者可能在出现网络错误之前就已经收到了信息，也可能没有收到，又或者接收者的进程结束而没能接收。

       现代的键值（Key-Value）存储系统都是分布式的，ZooKeeper是其中历史最悠久的项目之一，它起源于Hadoop。

       ZooKeeper的主要优势是其具有成熟、健壮以及丰富的特性，然而，它也有自己的缺点，具体体现在如下几个方面。

      复杂。ZooKeeper的部署维护比较复杂，管理员必须掌握一系列的知识和技能；而它所使用的Paxos强一致性算法素来也是以复杂难懂而闻名于世的；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了Java和C两种语言的接口。

       Java编写。这里不是对Java有偏见，而是Java本身就偏向重型应用，它会引入大量的依赖。而运维人员则普遍希望机器集群能尽可能地简单，维护起来也不容易出错。另外，它对资源的占用也非常高，这一点下面会有实际数据的说明。

       发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构和松散的管理导致项目发展缓慢。这一点在对比GitHub和etcd项目的star、fork和release的数据时就一目了然。

       现在，我们有了更好的选择—etcd。与ZooKeeper相比，它更简单，安装、部署和使用更加容易，并且etcd的某些功能是ZooKeeper所没有的。因此，在很多场景下，etcd比ZooKeeper更受用户的青睐，具体表现在如下几个方面。

       etcd更加稳定可靠，它的唯一目标就是把分布式一致性KV存储做到极致，所以它更注重稳定性和扩展性。

       在服务发现的实现上，etcd使用的是节点租约（Lease），并且支持Group（多key）；而ZooKeeper使用的是临时节点，临时节点存在不少的问题，这些问题后面会提到。

       etcd支持稳定的watch，而不是ZooKeeper一样简单的单次触发式（one time trigger）watch。因为在未来微服务的环境下，通过调度系统的调度，一个服务随时可能会下线，也可能为应对临时访问压力而增加新的服务节点，而很多调度系统是需要得到完整节点历史记录的，在这方面，etcd可以存储数十万个历史变更。

       etcd支持MVCC（多版本并发控制），因为有协同系统需要无锁操作。

       etcd支持更大的数据规模，支持存储百万到千万级别的key。

       相比ZooKeeper，etcd的性能更好。在一个由3台8核节点组成的云服务器上，etcd v3版本可以做到每秒数万次的写操作和数十万次的读操作。

       etcd这个名字由两部分组成：etc和d，即UNIX/Linux操作系统的“/etc”目录和分布式（distributed）首字母的“d”。我们都知道，/etc目录一般用于存储UNIX/Linux操作系统的配置信息，因此etc和d合起来就是一个分布式的/etc目录。由此可见，etcd的寓意是为大规模分布式系统存储配置信息。

       etcd是由一家位于旧金山的初创公司CoreOS公司（现已被Red Hat收购）于2013年6月发起的开源项目，旨在构建一个高可用的分布式键值（key-value）存储系统。CoreOS系统通过etcd来解决分布式系统配置信息共享、服务发现等问题。目前etcd托管在GitHub上，仓库地址为github.com/coreos/etcd。etcd作为一个相对较新的项目，在本书出版之际已有超过15 000的star数，超过3000的fork数，超过100的release版本数，社区非常活跃。

       熟悉Cloud Foundry和Kubernetes的读者必定都听说过etcd。谷歌的开源集群容器管理软件Kubernetes和Pivotal的开源PaaS软件Cloud Foundry不约而同地都使用了etcd，它们都依赖etcd来进行集群管理。

       CoreOS的前CEO Alex Polvi曾说过，etcd是Chubby的开源实现，Chubby是谷歌为处理分布式系统中的一致性问题而开发的基于Paxos协议的分布式锁系统。

       CoreOS的前etcd项目主管Blake Mizerany在他的一篇博客中解释道：“分布式系统集群管理是一项复杂的业务，etcd通过创建一个hub跟踪一个集群中每个节点的状态并管理这些状态，将会使得这项工作变得简单易行。etcd会复制集群中所有节点的状态数据，防止单个节点故障影响整个组”。

       那么，etcd到底是什么？下面就让我们一探究竟。

2.1　etcd是什么

       etcd的官方定义如下：

       A highly-available key value store for shared configuration and service discovery.

很多人看到上述官方定义的第一反应可能是，etcd是一个键值存储仓库，却没有重视官方定义的后半句—用于配置共享和服务发现。

       也就是说，etcd是一个Go语言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值（key-value）存储、配置共享和服务发现等功能。etcd可以用于存储关键数据和实现分布式调度，它在现代化的集群运行中能够起到关键性的作用。本书后面的篇幅中，将会详细介绍etcd的应用和实践，其中会涉及etcd的安装、部署，API的使用介绍，以及如何对运行的etcd集群进行监控等。

       etcd以一致和容错的方式存储数据。分布式系统可以使用etcd实现一致性键值存储、配置管理、服务发现和分布式系统的协同等功能。常见的etcd使用场景包括：服务发现、分布式锁、分布式数据队列、分布式通知和协调、主备选举等。

       etcd基于Raft协议，通过复制日志文件的方式来保证数据的强一致性。当客户端应用写一个key时，首先会存储到etcd的Leader上，然后再通过Raft协议复制到etcd集群的所有成员中，以此维护各成员（节点）状态的一致性与实现可靠性。虽然etcd是一个强一致性的系统，但也支持从非Leader节点读取数据以提高性能，而且写操作仍然需要Leader的支持，所以当发生网络分区时，写操作仍可能失败。etcd实现了一个Go语言版的Raft程序库，并广泛应用于各种项目，除了etcd之外，各项目中还包括docker swarm kit等。

       etcd具有一定的容错能力，假设集群***有n个节点，即便集群中（n-1）/2个节点发生了故障，只要剩下的（n+1）/2个节点达成一致，也能操作成功。因此，它能够有效地应对网络分区和机器故障带来的数据丢失风险。

       etcd默认数据一更新就落盘持久化，数据持久化存储使用WAL（write ahead log，预写式日志）格式。WAL记录了数据变化的全过程，在etcd中所有数据在提交之前都要先写入WAL中；etcd的Snapshot（快照）文件则存储了某一时刻etcd的所有数据，默认设置为每10 000条记录做一次快照，经过快照后WAL文件即可删除。