CAP定理

关于 CAP 定理，分为以下三点:

● 一致性(Consistency):分布式数据库的数据保持一致。
● 可用性(Availability):任何一个节点宕机，其他节点可以继续对外提供服务。
● 分区容错性(网络分区)Partition Tolerance:一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以添加一台机器，然后从其他正常的机器把备份 的数据同步过来。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解 CAP 定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态 会导致数据不一致，即丧失了 Consistency。如果为了保证数据一致性，将分区一侧 的节点设置为不可用，那么又丧失了 Availability。除非两个节点可以互相通信，才 能既保证 Consistency 又保证 Availability，这又会导致丧失 Partition Tolerance。

CAP 的选择

为了容灾上设计，集群节点的部署，会选择的异地多机房，所以「Partition tolerance」是不可能避免的。那么可选的是 AP 与 CP。
在 HIDS 集群的场景里，各个 Agent 对集群持续可用性没有非常强的要求，在 短暂时间内，是可以出现异常，出现无法通讯的情况。但最终状态必须要一致，不能 存在集群下发关停指令，而出现个别 Agent 不听从集群控制的情况出现。所以，我 们需要一个满足 CP 的产品。

满足 CP 的产品选择

在开源社区中，比较出名的几款满足 CP 的产品，比如 etcd、ZooKeeper、 Consul 等。我们需要根据几款产品的特点，根据我们需求来选择符合我们需求的 产品。

插一句，网上很多人说 Consul 是 AP 产品，这是个错误的描述。既然 Consul 支持分布式部署，那么一定会出现「网络分区」的问题，那么一定要支持「Partition tolerance」。另外，在 consul 的官网上自己也提到了这点 Consul uses a CP architecture, favoring consistency over availability.
Consul is opinionated in its usage while Serf is a more flexible and general purpose tool. In CAP terms, Consul uses a CP architecture, favoring consistency over availability. Serf is an AP system and sac- rifices consistency for availability. This means Consul cannot operate if the central servers cannot form a quorum while Serf will continue to function under almost all circumstances.

etcd、ZooKeeper、Consul 对比

借用 etcd 官网上 etcd 与 ZooKeeper 和 Consul 的比较图。