最终一致性：反熵

作者：Katy Farmer / 产品，用例，开发者
2018年8月21日

在这个博客系列中，我们将探讨最终一致性这个难以定义的术语。这是许多分布式系统（包括InfluxDB企业版）使用的共识模型。理解最终一致性需要两个概念：提示性传递队列和反熵，这两者都值得特别关注。

注意

本系列的第Ⅰ部分深入探讨了最终一致性的概念以及它在分布式计算中的重要性。您可以在此这里重温第Ⅰ部分。

第Ⅱ部分

什么是反熵？

如果您已经阅读了本系列第Ⅰ部分关于提示性传递队列的内容，您已经知道提示性传递队列如何在数据节点故障期间保存数据并帮助您确保最终一致性，但在分布式系统中存在许多出错的方式。尽管我们尽了最大努力，仍然有可能丢失数据，我们希望在可能的情况下尽量减少这种情况。这就是维护最终一致性的另一半：反熵（AE）。

如果我们反对熵，那么我们应该对它是怎么回事有所了解。根据互联网和我的科学界朋友们的说法，熵由热力学第二定律定义。基本上，有序系统随着时间的推移倾向于熵增加的状态；因此，熵越高，无序度越大。我们反对我们的时间序列数据中的无序，因此我们反对熵。

忘记这个词本身可能带来的任何恐惧因素，反熵只是我们可以在InfluxDB Enterprise中运行的一种服务，用于检查不一致性。我们知道，当我们从一个分布式系统请求信息时，我们收到的答案可能不会一致地返回。由于“漂移”可以引入的广泛方式，我们需要一个英雄来识别和修复潜在的数据差异。AE可以成为这样的英雄。

示例1

让我们回顾一下我们经典的集群：InfluxDB Enterprise与2个数据节点和一个复制因子=2的数据库。

系统健康快乐，数据正在发送并被存储和复制。这是我们数据的幸福结局，但有时我们不得不努力才能实现这一点。分布式系统经常发生变化，而处理这种变化往往是首先破坏一致性的原因。

系统中最常见的变化之一是硬件，因此让我们看看新改进的AE可以在哪里发挥作用。假设节点2有一些硬件故障。也许它是损坏的，或者只是过时了，但它在中夜停止工作（因为当然它会在半夜）。

当节点2离线时，任何新的写入都会发送到HHQ，在那里它们等待节点2再次可用。读取被导向节点1，它拥有与节点2相同的数据（因为我们的RF = 2）。

这是我们的英雄反熵的起源故事，它是作为解决我们能够想到的所有边缘情况的解决方案开发的，并且希望还有很多我们没有想到的。

在我们的例子中，我们的首要任务是让节点2重新上线，以便它可以在系统中恢复其应有的读写数据的位置。我们可以使用InfluxDB Enterprise中的‘replace-node’命令，用新的硬件重新加入节点2。

在这种情况下，AE检查复制因子和分片分布的组合，以查看是否应该存在所有分片都已适当复制。在这种情况下，由于节点2有一个新的、快速的、空白的且无缺陷的SSD，节点1上存在的所有分片都复制到节点2，并且在HHQ中等待的数据很快被清空。我们的AE英雄确保两个节点将返回相同的信息，并存在适当数量的副本。万岁！

示例2

但是HHQ不能永远保留数据——它有一些实际限制。在InfluxDB Enterprise中，它默认为10GB，这意味着如果大小超过10GB，最旧的数据点将被删除以腾出空间给新数据。或者，如果数据在HHQ中放置时间过长（在InfluxDB Enterprise中的默认值为168小时），它将被删除。HHQ是为了处理可以迅速解决的临时故障和修复而设计的，所以它不应该无限期地填满。它解决了最常见的场景，但HHQ只能承担这么多负担。

在存在较长时间“故障”的情况下，我们希望保持一致的节点之间有更多的数据漂移空间。如果一个节点宕机并且长时间未被检测到，HHQ 可能会超出存储、时间限制、并发或速率限制，在这种情况下，它打算转发的数据就会消失在无形中。这并不理想。当然，存在大量可能发生的潜在边缘情况：HHQ 和 AE 服务的目标是提供一种方法，以最少的努力确保最终一致性。

在其他系统中，一旦节点 2 消失，用户就有责任确保该节点得到修复并恢复到一致状态，这通常是通过手动识别和复制数据来实现的。让我们面对现实：谁有那么多时间呢？我们还有工作要做，还要吃华夫饼。

从 InfluxDB 企业版 1.5 开始，AE 会检查集群中的每个节点，以查看它是否拥有元存储应该拥有的所有分片。不同之处在于，如果任何分片丢失，AE 会从具有数据的另一个节点复制现有的分片。任何丢失的分片都将由服务自动复制。从 InfluxDB 企业版 1.6 开始，AE 服务可以指示检查跨节点分片中包含的数据的一致性。如果发现任何不一致性，AE 可以修复这些不一致性。

在我们的第二个示例中，AE 服务会将节点 1 和 2 与由数据节点上的分片构建的摘要进行比较。然后，它会报告节点 2 缺失信息，并使用相同的摘要找出它应该拥有的信息。然后，它将从好的分片（节点 1）复制信息到节点 2。砰！最终一致性。

用更基本的话来说，AE 服务现在可以识别丢失或不一致的分片并修复它们。这是自我修复的最佳表现。我们不必担心集群的当前状态，而是可以调查导致故障的原因（在这种情况下，我们可能是在睡觉或吃华夫饼，尽管情况并不总是这么简单）。

关于 AE 有一些重要的事情要了解。只有在至少还有一份分片的副本可用时，AE 才能表现出英雄般的壮举。在我们的例子中，我们有 2 的副本因子，因此我们可以依赖节点 1 来复制健康分片。如果节点 2 有该分片的部分副本，这些分片将被比较，并且任何缺失的数据将在节点之间交换，以确保返回一致的结果。如果用户选择将副本因子设置为 1，他们就是在选择节省存储，但会失去高可用性，并受到更有限的查询量的限制。这也意味着 AE 将无法进行修复，因为一旦数据不一致，就没有真理的来源。另一个注意事项是 AE 不会比较或修复热分片，这意味着分片不能有活跃的写入。热分片更容易变化，在任何给定时刻，新数据的到来都会影响 AE 的摘要比较。当一个分片变得冷或非活动时，数据不再变化，AE 服务可以更准确地比较摘要。

总结

最终一致性是一个承诺高可用性的模型，并且如果我们的数据始终可用，它也必须始终准确。像任何优秀的超级英雄搭档一样，HHQ 和 AE 在一起更好，它们在后台打击数据不一致的罪行，这样我们就可以相信我们的数据，继续做我们关心的事情（即华夫饼）。