zookeeper基于paxos的化简版zab，etcd基于raft算法、consul也是基于raft算法。etcd和consul作为后起之秀，并没有因为已经有了zookeeper而放弃自己，而是采用更为直接的raft算法。
Raft算法的头号目标就是容易理解（UnderStandable），这从论文的标题就可以看出来。当然，Raft增强了可理解性，在性能、可靠性、可用性方面是不输于Paxos的。
Raft more understandable than Paxos and also provides a better foundation for building practical systems
为了达到易于理解的目标，raft做了很多努力，其中最主要是两件事情：
- 问题分解
- 状态简化
问题分解是将"复制集中节点一致性"这个复杂的问题划分为数个可以被独立解释、理解、解决的子问题。在raft，子问题包括，leader election， log replication，safety，membership changes。而状态简化更好理解，就是对算法做出一些限制，减少需要考虑的状态数，使得算法更加清晰，更少的不确定性（比如，保证新选举出来的leader会包含所有commited log entry）
Raft implements consensus by first electing a distinguished leader, then giving the leader complete responsibility for managing the replicated log. The leader accepts log entries from clients, replicates them on other servers, and tells servers when it is safe to apply log entries to their state machines. A leader can fail or become disconnected from the other servers, in which case a new leader is elected.
上面的引文对raft协议的工作原理进行了高度的概括：raft会先选举出leader，leader完全负责replicated log的管理。leader负责接受所有客户端更新请求，然后复制到follower节点，并在“安全”的时候执行这些请求。如果leader故障，followes会重新选举出新的leader。
这就涉及到raft最新的两个子问题：leader election和log replication
leader election
log replication
这里就平时经常用到的服务发现的产品进行下特性的对比，首先看下结论:
- 服务的健康检查
Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
- 多数据中心支持
Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；
- KV 存储服务
除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。
- 产品设计中 CAP 理论的取舍
Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性，并能 k-v store 服务保证一致性。而Zookeeper,Etcd则是CP类型 牺牲可用性，在服务发现场景并没太大优势；
- 多语言能力与对外提供服务的接入协议
Zookeeper的跨语言支持较弱，其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。Consul除了标准的Rest服务api,还提供了DNS的支持。
- Watch的支持（客户端观察到服务提供者变化）
Zookeeper 支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知；
- 自身集群的监控
除了 Zookeeper ,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的；
- 安全
Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.
- Spring Cloud的集成
目前都有相对应的 boot starter，提供了集成能力。
总的来看，目前Consul 自身功能，和 spring cloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。
Etcd 和 Zookeeper 提供的能力非常相似，在软件生态中所处的位置也几乎是一样的，可以互相替代的。
都是通用的一致性元信息存储，
都提供watch机制用于变更通知和分发，
也都被分布式系统用来作为共享信息存储，
二者除了实现细节，语言，一致性协议上的区别，最大的区别在周边生态圈。
Zookeeper 是apache下的，用java写的，提供rpc接口，最早从hadoop项目中孵化出来，在分布式系统中得到广泛使用(hadoop, solr, kafka, mesos 等)。
Etcd 是coreos公司旗下的开源产品，比较新，以其简单好用的rest接口以及活跃的社区俘获了一批用户，在新的一些集群中得到使用(比如kubernetes)。
虽然v3为了性能也改成二进制rpc接口了，但其易用性上比 Zookeeper 还是好一些。
而 Consul 的目标则更为具体一些，Etcd 和 Zookeeper 提供的是分布式一致性存储能力，具体的业务场景需要用户自己实现，比如服务发现，比如配置变更。
而Consul 则以服务发现和配置变更为主要目标，同时附带了kv存储。
在软件生态中，越抽象的组件适用范围越广，但同时对具体业务场景需求的满足上肯定有不足之处。
------------------- 消息中间件Rabbitmq ----------------------------------
消息中间件Rabbitmq（01）
消息中间件Rabbitmq（02）
消息中间件Rabbitmq（03）
消息中间件Rabbitmq（04）
消息中间件Rabbitmq（05）
消息中间件Rabbitmq（06）
消息中间件Rabbitmq（07）
------------------- ---------- 云计算 -------------------------------------
云计算（1）——docker的前世今生
云计算（2）—— 体系结构
云计算（3）—— 容器应用
云计算（4）—— LAMP
云计算（5）—— Dockerfile云计算（6）—— harbor
关注公众号 soft张三丰
