最终一致性：提示移交队列

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

在这个博客系列中，我们将探讨最终一致性这个术语，没有适当的词汇很难定义。这是InfluxDB企业版等许多分布式系统使用的致性模型。为了理解最终一致性，我们需要了解两个概念：提示移交队列和反熵，这两个都需要特别注意。

第一部分

什么是提示移交队列？

尽管名字听起来很酷，但提示移交（HH）队列并没有得到很多关注。HH队列有一个相当重要的任务，除非你是系统管理员，否则你很少直接与之互动。让我们深入了解提示移交队列到底是什么，以及为什么它对你很重要。

为了讨论HH队列，我们必须谈谈分布式计算——只是稍微一点。系统如InfluxDB企业版之所以作为分布式系统存在，一个原因是消除单点故障。InfluxDB企业版使用复制因子（RF）来确定任何一组数据应存在多少副本。将RF设置为大于1意味着系统有更高的成功率来处理请求，并在数据节点故障期间不会返回错误，这意味着我们不再只有一个可能丢失或不可用的数据副本。分布式系统也提出了独特的挑战：我们如何知道数据在系统中的致性，尤其是在存储多个数据副本的情况下？

首先，我们需要理解最终一致性承诺中的一些内容。剧透一下：系统中的数据最终必须是一致的。当我们从分布式系统请求信息时，可能会有某些时间点收到的答案并不一致。随着数据在系统中的存储和复制，我们会收到一些“漂移”的答案，但随着时间的推移，这种“漂移”应该被消除。在实践中，这意味着最近的时间范围可能会有最大的结果差异，但随着系统通过确保相同的信息在各个地方都可用这一机制工作，这种差异应该会被消除。

如果我们承诺系统最终会是一致的，我们如何处理失败的写入？数据节点可能会因多种原因离线，从磁盘空间不足到硬件故障。如果一个节点在离线期间丢失了数据点，它永远无法保持一致，因此，我们的最终一致性承诺就变成了一句谎言。

失败的写入也可能影响系统中的复制因子。维护指定的RF是我们必须遵守的另一项承诺，如果数据节点离线，它也是写入的另一个可能的故障点。

示例

让我们看看最简单的例子：具有2个数据节点和RF = 2的数据库的InfluxDB Enterprise。数据通过某些收集代理（例如Telegraf）到达您喜欢的负载均衡器，负载均衡器将写入（也是读取，但我们将使用写入作为示例）分布到底层数据节点。通常，负载均衡器以轮询方式分配写入。接收该数据的数据节点将其存储并复制（发送到另一个数据节点），然后：RF为2的复制因子就实现了。

注意：图中未显示元节点，您可以在这里了解更多信息。

我们仍然需要一个解决方案来处理失败的或延迟的写入。假设我们系统中的一个节点因物理过热而离线。如果没有备份，任何未成功的写入都将完全丢失，永远不会再次出现。

引入HH队列。

HH队列是一个持久、基于磁盘的队列。它是InfluxDB Enterprise的一个基本组成部分，旨在确保最终一致性，这是一种确保所有数据节点最终在它们之间拥有一个一致数据集的机制。对于InfluxDB Enterprise，HH队列是实现最终一致性和确保每个数据库的数据复制因子最终实现的一个重要部分。

现在，让我们回顾一下我的集群中一个数据节点离线的情况。节点离线可能有多种原因：硬件缺陷、磁盘空间限制，甚至常规维护。没有提示性传递队列，失败的写入在它们能够存储之前就死亡了，但现在我们有一个安全的地方可以存放它们。

任何未成功的写入都会被定向到HH队列，当节点重新上线时，它会检查HH队列中挂起的写入。节点可以完成写入，直到队列被清空。嘭——实现了最终一致性。

总结

这是对最终一致性集群内部发生的事情的观察，但还有一些来自外部需要考虑的问题：当数据成功写入一个节点但未能正确复制时，用户会看到成功还是失败？HH队列中的健康模式是什么样的？如果HH队列不断填充和清空，这意味着整体系统健康状况如何？在下一篇文章中，我们将讨论如何排查和识别我们InfluxDB Enterprise集群中的问题模式。