Anti-Entropy（反熵）

Consul使用先进的方法来维护服务和健康信息。 此页面详细说明了服务和检查是如何注册的，目录的填充是如何填充的，以及健康状况信息在更改时是如何更新的。

解释下两个词的意思：

熵：混乱

反熵：有序

»Components（组件）

首先要了解服务和健康检查中涉及的移动部分：代理和目录。 这些在下面概念性地描述，以使反熵更容易理解。

»Agent（代理）

每个Consul代理都维护自己的服务和检查注册以及健康信息。 代理负责执行自己的运行状况检查并更新其本地状态。

代理上下文中的服务和检查具有丰富的可用配置选项。 这是因为代理负责通过使用运行状况检查生成有关其服务及其健康状况的信息。

»Catalog（目录）

Consul的服务发现由服务目录支持。 该目录是通过汇总代理提交的信息而形成的。 目录维护群集的高级视图，包括可用的服务，运行这些服务的节点，运行状况信息等。 该目录用于通过Consul提供的各种接口（包括DNS和HTTP）公开此信息。

与代理相比，目录上下文中的服务和检查具有更有限的字段集。 这是因为目录仅负责记录和返回有关服务，节点和运行状况的信息。

目录仅由服务器节点维护。 这是因为通过Raft日志复制目录，以提供集群的统一且一致的视图。

»Anti-Entropy（反熵）

熵是系统变得越来越混乱的趋势。 Consul的反熵机制旨在抵消这种趋势，即使通过其组件的故障也能保持集群的状态。

如上所述，Consul在全局服务目录和代理的本地状态之间有明确的区分。反熵机制协调了这两个世界观：反熵是本地代理状态和目录的同步。例如，当用户注册新服务或与代理进行核对时，代理会依次通知目录此新检查存在。同样，当从代理中删除检查时，它也会从目录中删除。

反熵还用于更新可用性信息。当代理运行其运行状况检查时，它们的状态可能会发生变化，在这种情况下，它们的新状态将同步到目录。使用此信息，目录可以根据其可用性智能地响应有关其节点和服务的查询。

在此同步期间，还会检查目录的正确性。如果代理程序不知道的目录中存在任何服务或检查，则会自动删除它们以使目录反映该代理程序的正确服务集和运行状况信息。Consul将代理人的状态视为权威;如果代理程序和目录视图之间存在任何差异，则将始终使用代理程序本地视图。

»Periodic Synchronization（定期同步）

除了在代理发生更改时运行，反熵也是一个长时间运行的进程，它会定期唤醒以同步服务并检查目录的状态。 这可确保目录与代理的真实状态紧密匹配。 即使在完全数据丢失的情况下，这也允许Consul重新填充服务目录。

为了避免饱和，周期性反熵运行之间的时间量将根据集群大小而变化。 下表定义了集群大小和同步间隔之间的关系：

以上间隔是近似值。 每个Consul代理将在间隔窗口内选择随机交错的开始时间，以避免雷鸣般的群体。

»Best-effort sync（尽力同步）

在许多情况下，反熵可能会失败，包括代理配置错误或其操作环境，I / O问题（完整磁盘，文件系统权限等），网络问题（代理无法与服务器通信）等。 因此，代理尝试以尽力而为的方式进行同步。

如果在反熵运行期间遇到错误，则会记录错误并且代理继续运行。 定期运行反熵机制以自动从这些类型的瞬态故障中恢复。

»Enable Tag Override（启用标记覆盖）

可以部分修改服务注册的同步，以允许外部代理更改服务的标记。 这在外部监控服务需要成为标签信息真实来源的情况下非常有用。 例如，Redis数据库及其监控服务Redis Sentinel具有这种关系。 Redis实例负责其大部分配置，但Sentinels确定Redis实例是主要实例还是次要实例。 使用Consul服务配置项enable_tag_override，您可以指示运行Redis数据库的Consul代理在反熵同步期间不更新标记。 有关更多信息，请参阅服务页面