etcd是什么意思？和ZooKeeper有什么区别？
etcd
etcd作为最近很火的一个高可用性?键值对服务发现系统被Kubernetes等系统广泛使用
他相比与zookeeper来说更加简单，在面对较小集群时可能会效率更高些?，而且他的编写语言Go本身就是一种多线程编程语言，确实有很大吸引人的地方（虽然我不懂Go语言，但是在学习docker时也是一睹其风采了）
在Raft中，任何时候一个服务器可以扮演下面角色之一：
Leader: 处理所有客户端交互，日志复制等，一般一次只有一个Leader.
Follower: 类似选民，完全被动
Candidate候选人: 类似Proposer律师，可以被选为一个新的领导人。
leader选举阶段
消息同步阶段
Leader要求Followe遵从他的指令，都将这个新的日志内容追加到他们各自日志中：
大多数follower服务器将日志写入磁盘文件后，确认追加成功，发出Commited Ok:
在下一个心跳heartbeat中，Leader会通知所有Follwer更新commited 项目。对于每个新的日志记录，重复上述过程。
zookeeper：
zookeeper是基于paxos的简化版zab，我觉得确实很难理解?，以前看了好多遍《从paxos到zookeper》才感觉似懂非懂了，然而过了几个月发现又一脸蒙蔽了，在这里在整理一下（仅表示我自己的理解）
ZAB协议中存在着三种状态，每个节点都属于以下三种中的一种：
Looking ：系统刚启动时或者Leader崩溃后正处于选举状态
Following ：Follower节点所处的状态，Follower与Leader处于数据同步阶段；
Leading ：Leader所处状态，当前集群中有一个Leader为主进程；
在开始时，所有的节点都是looking状态并且每个节点都希望自己能成为leader节点，所有每个节点都会向集群中发送一个提案内容是选取自己作为leader节点，提案编号是ZXID(ZAB协议中使用ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1，高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID；ZAB使用epoch来区分不同的Leader周期),如果得到的提案的zxid比自己的大则说明发出这个题案的节点数据更新，则进行同意的投票，否则继续投自己，先得到多数的同意的节点当选为leader
现在leader就可以进行管理了，zookeeper也是两段提交的实现，客户端提交事务请求时Leader节点为每一个请求生成一个事务Proposal，将其发送给集群中所有的Follower节点，收到过半Follower的反馈后开始对事务进行提交，ZAB协议使用了原子广播协议
