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

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

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

第一部分

什么是提示移交队列？

尽管提示移交 (HH) 队列的名字很酷，但它并没有引起太多关注。HH 队列的任务非常重要，但除非您是系统管理员，否则您很少直接与其交互。让我们深入了解一下提示移交队列到底是什么，以及它为什么对您很重要。

为了讨论 HH 队列，我们必须稍微谈谈分布式计算。像 InfluxDB 企业版这样的系统作为分布式系统存在的原因之一是为了消除单点故障。InfluxDB 企业版使用复制因子 (RF) 来确定应存在多少个数据副本。将 RF 设置为 1 以上意味着系统在数据节点中断期间更有可能成功处理请求且不返回错误，这意味着我们不再只有一个可能丢失或不可用的数据副本。分布式系统也带来了独特的挑战：我们如何知道数据在整个系统中是一致的，尤其是在存储多个数据副本时？

首先，我们必须理解最终一致性所做的一些承诺。剧透警告：系统中的数据最终必须是一致的。当我们从分布式系统请求信息时，在某些时间点，我们收到的答案可能无法一致地返回。随着数据在整个系统中存储和复制，我们收到的答案在术语上存在一些“漂移”，但随着时间的推移，这种“漂移”应该被消除。在实践中，这意味着最近的时间范围的结果可能变化最大，但随着系统通过确保相同信息在任何地方都可用的机制，这种变化会被消除。

如果我们承诺系统最终将是一致的，我们如何处理写入失败的情况？数据节点可能会因多种原因而脱机，从磁盘空间不足到普通的硬件故障。如果一个节点缺少其脱机期间的数据点，它将永远无法保持一致，因此，我们关于最终一致性的承诺将成为谎言。

写入失败也可能影响整个系统的复制因子。维护指定的 RF 是我们必须遵守的另一个承诺，如果数据节点脱机，这也是写入失败的另一个可能点。

示例

让我们探讨一个最简单的示例：具有 2 个数据节点的 InfluxDB 企业版和一个 RF = 2 的数据库。数据通过一些采集代理（例如 Telegraf）到达您最喜欢的负载均衡器，负载均衡器将写入（也包括读取，但在此示例中我们将使用写入）分发到基础数据节点。通常，负载均衡器以轮询方式分发写入。接收该数据的数据节点存储并复制它（将其发送到另一个数据节点），瞧：实现了 RF 为 2。

注意：图中未显示元节点，您可以在此处阅读相关信息。

我们仍然需要一个针对失败或延迟写入的解决方案。假设我们系统中的一个节点物理过热并脱机。如果没有备份，任何不成功的写入都会被完全丢弃，永远不会再出现。

引入 HH 队列。

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

现在，让我们重新审视我的集群中的一个数据节点脱机的情况。节点可能因多种原因而脱机：硬件缺陷、磁盘空间限制，甚至例行维护。如果没有提示移交队列，不成功的写入在存储之前就已死亡，但现在我们有一个安全的场所供它们落脚。

任何不成功的写入都会被定向到 HH 队列，当节点重新上线时，它会检查 HH 队列中是否有待处理的写入。然后，节点可以完成写入，直到队列被清空。砰——实现了最终一致性。

总结

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