Consul和Raft介绍

在本文中，我们展示了具有多个实例的高性能应用程序中的领导选举基础。我们演示了Consul的会话管理和KV存储功能如何帮助获得锁并选择领导者。

Consul和Raft介绍

Consul解决的问题多种多样，但是每个单独的功能已由许多不同的系统解决。尽管没有一个单一的系统可以提供Consul的所有功能，但是还有其他选项可以解决其中的一些问题。

我们将Consul与其他一些选项进行比较。在大多数情况下，Consul不会与任何其他系统互斥。

quorum在本文被翻译成了法定人数，即达到共识所需要的最少要求

Consul与ZooKeeper，doozerd等

ZooKeeper，doozerd和etcd的体系结构都相似。这三个系统的服务器节点都需要一定数量的节点才能运行（通常是简单多数，与之相似的是绝对多数）。它们具有强一致性，并公开了可通过应用程序中的客户端库用于构建复杂的分布式系统的各种原语。

Consul还可使用单个数据中心内的服务器节点。在每个数据中心，Consul服务器都需要一个法定人数（quorum）来运行并提供强一致性。然而，Consul有对多个数据中心的本地支持，以及一个功能更丰富的gossip系统，将服务器节点和客户端连接起来。

当提供K/V存储时，这些系统都具有大致相同的语义：读取具有强一致性，并且面对网络分区，为了一致性而牺牲了可用性。但是，当这些系统用于高级案例时，差异变得更加明显。

这些系统提供的语义对于构建服务发现系统很有吸引力，但是必须强调，使用者必须构建这些功能，这一点很重要。对于ZooKeeper等，仅提供原始的K/V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。相反，Consul为服务发现提供了一个武断（opinionated）的框架，并消除了猜测和开发工作。客户端只需注册服务，然后使用DNS或HTTP接口执行服务发现。而其他系统需要本地解决方案。

一个引人注目的服务发现框架必须包含运行状况检查以及故障的可能性。如果该节点发生故障或服务崩溃，知道节点A提供Foo服务是没有用的。单纯的系统使用心跳，并使用定期更新和TTL。这些方案需要与节点数量成线性关系的工作，并将需要放在固定数量的服务器上。另外，故障检测窗口至少与TTL一样长。

ZooKeeper提供了临时节点，这些临时节点是在客户端断开连接时被删除的K/V条目。它们比心跳系统更复杂，但仍然存在固有的可拓展性问题，并增加了客户端的复杂性。所有客户端必须维持与ZooKeeper服务器的活跃连接并执行保活。另外，这需要“厚（thick）客户端”，这些客户端很难编写，并且经常带来调试挑战。

Consul使用非常不同的体系结构进行健康检查。Consul客户端不仅在服务器节点上运行，而且还在集群中的每个节点上运行。这些客户端是gossip池的一部分，该池具有多种功能，包括分布式运行状况检查。gossip协议实现了一个有效的故障检测器，该检测器可以扩展到任何规模的集群，而无需将工作集中在任何选定的服务器组上。客户端还允许在本地运行更丰富的健康检查集，而ZooKeeper临时节点是非常原始的存活检查。使用Consul，客户端可以检查Web服务器是否正在返回200状态码以便检测内存利用率，磁盘空间等（这里不清楚，原文是that memory utilization is not critical, that there is sufficient disk space, etc）。Consul客户端公开了一个简单的HTTP接口，并避免以与ZooKeeper相同的方式向客户端公开系统的复杂性。

Consul为服务发现&