场景七：集群监控与Leader竞选
通过etcd来进行监控实现起来非常简单并且实时性强。
前面几个场景已经提到Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户。
节点可以设置TTL key，比如每隔30s发送一次心跳使代表该机器存活的节点继续存在，否则节点消失。
这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。
另外，使用分布式锁，可以完成Leader竞选。这种场景通常是一些长时间CPU计算或者使用IO操作的机器，只需要竞选出的Leader计算或处理一次，就可以把结果复制给其他的Follower。从而避免重复劳动，节省计算资源。
这个的经典场景是搜索系统中建立全量索引。如果每个机器都进行一遍索引的建立，不但耗时而且建立索引的一致性不能保证。通过在etcd的CAS机制同时创建一个节点，创建成功的机器作为Leader，进行索引计算，然后把计算结果分发到其它节点。
图9 Leader竞选
场景八：为什么用etcd而不用ZooKeeper？阅读了“ZooKeeper典型应用场景一览”一文的读者可能会发现，etcd实现的这些功能，ZooKeeper都能实现。那么为什么要用etcd而非直接使用ZooKeeper呢？
相较之下，ZooKeeper有如下缺点：
复杂。ZooKeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了Java和C两种语言的接口。
Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单，维护起来也不易出错。
发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。
而etcd作为一个后起之秀，其优点也很明显。
简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。
数据持久化。etcd默认数据一更新就进行持久化。
安全。etcd支持SSL客户端安全认证。
最后，etcd作为一个年轻的项目，真正告诉迭代和开发中，这既是一个优点，也是一个缺点。优点是它的未来具有无限的可能性，缺点是无法得到大项目 长时间使用的检验。然而，目前CoreOS、Kubernetes和CloudFoundry等知名项目均在生产环境中使用了etcd，所以总的来 说，etcd值得你去尝试。
etcd实现原理解读上一节中，我们概括了许多etcd的经典场景，这一节，我们将从etcd的架构开始，深入到源码中解析etcd。
1 架构
图10 etcd架构图
从etcd的架构图中我们可以看到，etcd主要分为四个部分。
HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。
Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。
Raft：Raft强一致性算法的具体实现，是etcd的核心。
WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中， 所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。
通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。
2 新版etcd重要变更列表获得了IANA认证的端口，2379用于客户端通信，2380用于节点通信，与原先的（4001 peers / 7001 clients）共用。
每个节点可监听多个广播地址。监听的地址由原来的一个扩展到多个，用户可以根据需求实现更加复杂的集群环境，如一个是公网IP，一个是虚拟机（容器）之类的私有IP。
etcd可以代理访问leader节点的请求，所以如果你可以访问任何一个etcd节点，那么你就可以无视网络的拓扑结构对整个集群进行读写操作。
etcd集群和集群中的节点都有了自己独特的ID。这样就防止出现配置混淆，不是本集群的其他etcd节点发来的请求将被屏蔽。
etcd集群启动时的配置信息目前变为完全固定，这样有助于用户正确配置和启动。
运行时节点变化(Runtime Reconfiguration)。用户不需要重启 etcd 服务即可实现对 etcd 集群结构进行变更。启动后可以动态变更集群配置。
重新设计和实现了Raft算法，使得运行速度更快，更容易理解，包含更多测试代码。
Raft日志现在是严格的只能向后追加、预写式日志系统，并且在每条记录中都加入了CRC校验码。
启动时使用的_etcd/* 关键字不再暴露给用户
废弃集群自动调整功能的standby模式，这个功能使得用户维护集群更困难。
新增Proxy模式，不加入到etcd一致性集群中，纯粹进行代理转发。
ETCD_NAME（-name）参数目前是可选的，不再用于唯一标识一个节点。
摒弃通过配置文件配置 etcd 属性的方式，你可以用环境变量的方式代替。
通过自发现方式启动集群必须要提供集群大小，这样有助于用户确定集群实际启动的节点数量。
3 etcd概念词汇表Raft：etcd所采用的保证分布式系统强一致性的算法。
Node：一个Raft状态机实例。
Member： 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。
Cluster：由多个Member构成可以协同工作的etcd集群。
Peer：对同一个etcd集群中另外一个Member的称呼。
Client： 向etcd集群发送HTTP请求的客户端。
WAL：预写式日志，etcd用于持久化存储的日志格式。
snapshot：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。
Proxy：etcd的一种模式，为etcd集群提供反向代理服务。
Leader：Raft算法中通过竞选而产生的处理所有数据提交的节点。
Follower：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。
Candidate：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。
Term：某个节点成为Leader到下一次竞选时间，称为一个Term。
Index：数据项编号。Raft中通过Term和Index来定位数据。
4 集群化应用实践etcd作为一个高可用键值存储系统，天生就是为集群化而设计的。由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群。
4.1 集群启动etcd有三种集群化启动的配置方案，分别为静态配置启动、etcd自身服务发现、通过DNS进行服务发现。
通过配置内容的不同，你可以对不同的方式进行选择。值得一提的是，这也是新版etcd区别于旧版的一大特性，它摒弃了使用配置文件进行参数配置的做法，转而使用命令行参数或者环境变量的做法来配置参数。
4.1.1. 静态配置这种方式比较适用于离线环境，在启动整个集群之前，你就已经预先清楚所要配置的集群大小，以及集群上各节点的地址和端口信息。那么启动时，你就可以通过配置initial-cluster参数进行etcd集群的启动。
在每个etcd机器启动时，配置环境变量或者添加启动参数的方式如下。
ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380" ETCD_INITIAL_CLUSTER_STATE=new参数方法：
-initial-cluster infra0=http://10.0.1.10:2380,:2380,infra2=http://10.0.1.12:2380 -initial-cluster-state new值得注意的是，-initial-cluster参数中配置的url地址必须与各个节点启动时设置的initial-advertise-peer-urls参数相同。（initial-advertise-peer-urls参数表示节点监听其他节点同步信号的地址）
如果你所在的网络环境配置了多个etcd集群，为了避免意外发生，最好使用-initial-cluster-token参数为每个集群单独配置一个token认证。这样就可以确保每个集群和集群的成员都拥有独特的ID。
综上所述，如果你要配置包含3个etcd节点的集群，那么你在三个机器上的启动命令分别如下所示。
$ etcd -name infra0 -initial-advertise-peer-urls :2380 -listen-peer-urls :2380 -initial-cluster-token etcd-cluster-1 -initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380 -initial-cluster-state new $ etcd -name infra1 -initial-advertise-peer-urls :2380 -listen-peer-urls :2380 -initial-cluster-token etcd-cluster-1 -initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380 -initial-cluster-state new $ etcd -name infra2 -initial-advertise-peer-urls :2380 -listen-peer-urls :2380 -initial-cluster-token etcd-cluster-1 -initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380 -initial-cluster-state new在初始化完成后，etcd还提供动态增、删、改etcd集群节点的功能，这个需要用到etcdctl命令进行操作。
4.1.2. etcd自发现模式通过自发现的方式启动etcd集群需要事先准备一个etcd集群。如果你已经有一个etcd集群，首先你可以执行如下命令设定集群的大小，假设为3.
$ curl -X PUT -d value=3然后你要把这个url地址作为-discovery参数来启动etcd。节点会自动使用目录进行etcd的注册和发现服务。
所以最终你在某个机器上启动etcd的命令如下。
$ etcd -name infra0 -initial-advertise-peer-urls :2380 -listen-peer-urls :2380 -discovery如果你本地没有可用的etcd集群，etcd官网提供了一个可以公网访问的etcd存储地址。你可以通过如下命令得到etcd服务的目录，并把它作为-discovery参数使用。
$ curl ?size=3同样的，当你完成了集群的初始化后，这些信息就失去了作用。当你需要增加节点时，需要使用etcdctl来进行操作。
为了安全，请务必每次启动新etcd集群时，都使用新的discovery token进行注册。另外，如果你初始化时启动的节点超过了指定的数量，多余的节点会自动转化为Proxy模式的etcd。
4.1.3. DNS自发现模式etcd还支持使用DNS SRV记录进行启动。关于DNS SRV记录如何进行服务发现，可以参阅RFC2782，所以，你要在DNS服务器上进行相应的配置。
(1) 开启DNS服务器上SRV记录查询，并添加相应的域名记录，使得查询到的结果类似如下。
$ dig +noall +answer SRV _etcd-server._tcp.example.com _etcd-server._tcp.example.com. 300 IN SRV 0 0 2380 infra0.example.com. _etcd-server._tcp.example.com. 300 IN SRV 0 0 2380 infra1.example.com. _etcd-server._tcp.example.com. 300 IN SRV 0 0 2380 infra2.example.com.(2) 分别为各个域名配置相关的A记录指向etcd核心节点对应的机器IP。使得查询结果类似如下。
$ dig +noall +answer infra0.example.com infra1.example.com infra2.example.com infra0.example.com. 300 IN A 10.0.1.10 infra1.example.com. 300 IN A 10.0.1.11 infra2.example.com. 300 IN A 10.0.1.12做好了上述两步DNS的配置，就可以使用DNS启动etcd集群了。配置DNS解析的url参数为-discovery-srv，其中某一个节点地启动命令如下。
$ etcd -name infra0 -discovery-srv example.com -initial-advertise-peer-urls :2380 -initial-cluster-token etcd-cluster-1 -initial-cluster-state new -advertise-client-urls :2379 -listen-client-urls :2379 -listen-peer-urls :2380当然，你也可以直接把节点的域名改成IP来启动。
4.2 关键部分源码解析etcd的启动是从主目录下的main.go开始的，然后进入etcdmain/etcd.go，载入配置参数。如果被配置为Proxy模式，则进入startProxy函数，否则进入startEtcd，开启etcd服务模块和http请求处理模块。
在启动http监听时，为了保持与集群其他etcd机器（peers）保持连接，都采用的transport.NewTimeoutListener启动方式，这样在超过指定时间没有获得响应时就会出现超时错误。而在监听client请求时，采用的是transport.NewKeepAliveListener，有助于连接的稳定。
在etcdmain/etcd.go中的setupCluster函数可以看到，根据不同etcd的参数，启动集群的方法略有不同，但是最终需要的就是一个IP与端口构成的字符串。
在静态配置的启动方式中，集群的所有信息都已经在给出，所以直接解析用逗号隔开的集群url信息就好了。
DNS发现的方式类似，会预先发送一个tcp的SRV请求，先查看etcd-server-ssl._tcp.example.com下是否有集群的域名信息，如果没有找到，则去查看etcd-server._tcp.example.com。根据找到的域名，解析出对应的IP和端口，即集群的url信息。
较为复杂是etcd式的自发现启动。首先就用自身单个的url构成一个集群，然后在启动的过程中根据参数进入discovery/discovery.go源码的JoinCluster函 数。因为我们事先是知道启动时使用的etcd的token地址的，里面包含了集群大小(size)信息。在这个过程其实是个不断监测与等待的过程。启动的 第一步就是在这个etcd的token目录下注册自身的信息，然后再监测token目录下所有节点的数量，如果数量没有达标，则循环等待。当数量达到要求 时，才结束，进入正常的启动过程。
配置etcd过程中通常要用到两种url地址容易混淆，一种用于etcd集群同步信息并保持连接，通常称为peer-urls；另外一种用于接收用户端发来的HTTP请求，通常称为client-urls。
peer-urls：通常监听的端口为2380（老版本使用的端口为7001），包括所有已经在集群中正常工作的所有节点的地址。
client-urls：通常监听的端口为2379（老版本使用的端口为4001），为适应复杂的网络环境，新版etcd监听客户端请求的url从原来的1个变为现在可配置的多个。这样etcd可以配合多块网卡同时监听不同网络下的请求。
4.3 运行时节点变更etcd集群启动完毕后，可以在运行的过程中对集群进行重构，包括核心节点的增加、删除、迁移、替换等。运行时重构使得etcd集群无须重启即可改变集群的配置，这也是新版etcd区别于旧版包含的新特性。
只有当集群中多数节点正常的情况下，你才可以进行运行时的配置管理。因为配置更改的信息也会被etcd当成一个信息存储和同步，如果集群多数节点损坏，集群就失去了写入数据的能力。所以在配置etcd集群数量时，强烈推荐至少配置3个核心节点。
4.3.1. 节点迁移、替换当你节点所在的机器出现硬件故障，或者节点出现如数据目录损坏等问题，导致节点永久性的不可恢复时，就需要对节点进行迁移或者替换。当一个节点失效以后，必须尽快修复，因为etcd集群正常运行的必要条件是集群中多数节点都正常工作。
迁移一个节点需要进行四步操作：
暂停正在运行着的节点程序进程
把数据目录从现有机器拷贝到新机器
使用api更新etcd中对应节点指向机器的url记录更新为新机器的ip
使用同样的配置项和数据目录，在新的机器上启动etcd。
4.3.2. 节点增加增加节点可以让etcd的高可用性更强。举例来说，如果你有3个节点，那么最多允许1个节点失效；当你有5个节点时，就可以允许有2个节点失效。同 时，增加节点还可以让etcd集群具有更好的读性能。因为etcd的节点都是实时同步的，每个节点上都存储了所有的信息，所以增加节点可以从整体上提升读 的吞吐量。
增加一个节点需要进行两步操作：
在集群中添加这个节点的url记录，同时获得集群的信息。
使用获得的集群信息启动新etcd节点。
4.3.3. 节点移除有时你不得不在提高etcd的写性能和增加集群高可用性上进行权衡。Leader节点在提交一个写记录时，会把这个消息同步到每个节点上，当得到多数节点的同意反馈后，才会真正写入数据。所以节点越多，写入性能越差。在节点过多时，你可能需要移除一个或多个。
移除节点非常简单，只需要一步操作，就是把集群中这个节点的记录删除。然后对应机器上的该节点就会自动停止。
4.3.4. 强制性重启集群当集群超过半数的节点都失效时，就需要通过手动的方式，强制性让某个节点以自己为Leader，利用原有数据启动一个新集群。
此时你需要进行两步操作。
备份原有数据到新机器。
使用-force-new-cluster加备份的数据重新启动节点
注意：强制性重启是一个迫不得已的选择，它会破坏一致性协议保证的安全性（如果操作时集群中尚有其它节点在正常工作，就会出错），所以在操作前请务必要保存好数据。