作者：来自 Elastic Henning Andersen
在最近的博客文章中，我们宣布了支持 Elastic Cloud Serverless 产品的无状态架构。通过将持久性保证和复制卸载到对象存储（例如 Amazon S3），我们获得了许多优势和简化。
从历史上看，Elasticsearch 依靠本地磁盘持久性来确保数据安全并处理陈旧或孤立的节点。在本博客中，我们将讨论无状态的数据持久性保证，包括我们如何使用安全检查隔离新的写入和删除，以防止陈旧节点不安全地确认这些操作。
在以下博客文章中，我们将介绍持久性承诺的基础知识以及 Elasticsearch 如何使用操作日志 (translog) 来快速安全地确认对客户端的写入。接下来，我们将深入研究问题，介绍对我们有帮助的概念，最后解释额外的安全检查，使我们能够自信地确认对客户端的写入。
持久性承诺和 translog
当客户端将数据写入 Elasticsearch 时（例如使用 _bulk API），Elasticsearch 将为该请求提供 HTTP 响应代码。Elasticsearch 仅在数据已安全存储时才提供成功的 HTTP 响应代码 (200/201)。我们使用操作日志（称为 translog），请求在确认写入之前附加并存储在其中。translog 允许我们重放未成功持久化到底层 Lucene 索引的操作（例如，如果在我们确认写入到客户端后节点崩溃）。有关 translog 和 Lucene 索引的更多信息，请参阅我们最近关于薄索引分片的博客文章中的此部分，其中我们解释了我们现在如何在对象存储中存储 Lucene 索引和 translog。
不知道是最糟糕的 - 问题
主节点将分片分配给索引节点，然后该节点负责将传入的数据索引到该分片中。但是，我们必须考虑此节点与主节点和/或集群其余部分失去通信的情况。
在这种情况下，主节点将（在超时后）假定该节点不再运行，并将受影响的分片重新分配给其他节点。先前的分配现在将被视为过时或陈旧（stale）。过时的节点可能仍在运行，试图索引和保存它收到的数据。
在这种情况下，可能有两个分片所有者试图确认写入但彼此失去通信，我们有两个问题需要解决：
- 避免对象存储中的文件覆盖
- 确保已确认的写入不会丢失
Primary terms - 数量增加以求得救
Elasticsearch 多年来一直使用我们称为 primary terms 的东西。每当将主分片分配给节点时，都会为其分配一个 primary term。如果主分片发生故障或从未分配（unassigned）变为已分配（assiined），主服务器（master）将在重新分配主分片之前增加 promary term 的值。这给出了主分片分配和所有权的严格顺序，在较低的 primary terms 之后分配较高的 primary terms。
对于无状态（stateless），我们在写入对象存储的索引文件路径中使用 primary terms，以确保不会发生上述第一个问题。如果分片发生故障并被重新分配，我们知道它将具有更高的 primary term。分片只会在 primary term 特定的路径中写入文件，因此较旧的分片分配和较新的分片分配不可能写入相同的文件。它们只是写入不同的路径。
Primary term 也用于最终提供耐用性保证，稍后会详细介绍。
请注意，主分片重定位不会增加 primary term 的值，而是涉及主分片重定位的两个节点通过明确的协议交接所有权。
Coordination term 和节点离开生成（ node-left generation）
Elasticsearch 中的协调子系统是一种用于集群级别协调的强一致性机制，包括集群成员资格和集群元数据（均称为集群状态）。
在无状态（stateless）中，此系统还建立在对象存储之上，上传新的集群状态版本。与有状态一样，它为称为 “term” 的选举维护一个不断增加的数字（我们在此将其称为 coordination term，以将其与上一节中描述的 primary term 区分开来）。每当一个节点决定开始新的选举时，它都会在新的 coordination term 内这样做，该 term 高于之前看到的任何 term（有关有状态中此工作的更多详细信息，请参阅此处的博客文章）。
在无状态中，选举通过我们称为租约（lease file）文件的对象存储文件进行。此文件包含 coordination term 和声称该 term 是该 term 的当选主节点的节点。
此文件将有助于我们在此处感兴趣的安全检查。如果 coordination term 仍然相同，我们就知道当选主节点没有改变。
然而，仅有协调项是不够的，因为即使节点离开集群，这也不一定会发生改变。为了检测数据节点是否未离开集群，我们还将节点离开生成添加到租约文件中。这是一个递增的数字，每次节点离开集群时都会增加。当 term 发生变化时，它会从零重置（但在这里我们可以忽略这一点）。
租约文件作为持久化新集群状态的一部分写入对象存储。此写入发生在根据新集群状态采取任何操作（如分片恢复）之前。
对象存储先读后写语义
我们使用对象存储以无状态存储所有数据，因此对象存储的可见性保证非常重要。最终，安全检查建立在这些保证之上。
- 先读后写：成功写入后，任何读取都将返回新内容。
- 先列表后写入：成功写入后，任何与新文件匹配的列表都将返回该文件。
这些在几年前并不是必然的，但现在已在 AWS S3、GCP 和 Azure blob 存储中提供。
安全检查
有了上述必要的构建块，我们现在可以进行实际的安全检查和安全论证。虽然 translog 保证了写入的持久性，但在确认写入之前，我们需要确保节点仍然是指定的索引节点。事实来源是集群状态，因此数据节点需要确定它具有足够新的集群状态，以确定确认写入是否安全。
我们只对非优雅事件感兴趣，例如节点崩溃、网络分区等。分片重定位等优雅事件通过显式交接来处理，以保证其正确性（我们不会在本篇博文中深入讨论这个问题）。
让我们考虑一个非优雅事件，例如主节点检测到保存分片的数据节点不再响应，因此它将节点从集群中弹出。我们将在这种情况下检查安全检查，看看它如何避免陈旧的节点可能错误地确认对客户端的写入。
安全检查在响应客户端之前添加了一项额外检查：
- 从对象存储中读取租约文件。如果 coordination term 或节点左代已超过节点本地集群状态中的值，则它不能依赖集群状态，直到收到具有更高或相等coordination term 和节点离开生成的更新版本。有了足够新的集群状态，可以使用它来检查分片的 primary term 是否已更改。如果已更改，则写入将失败。
在理想情况下，这里不会有任何等待，因为与正常写请求的频率相比，term 和节点离开生成的变化非常不频繁。因此，这个检查的开销很小。
请注意，顺序是重要的：在安全检查之前，translog 文件已经成功上传。稍后我们将解释原因。
非正常的节点离开事件会导致租约文件中的节点离开生成编号递增。之后，一个新节点可能会被分配到该分片并开始恢复数据（这可能只是一次集群状态更新，但这里唯一重要的部分是租约文件写入和节点开始恢复的顺序，这一点是有保证的）。
新分配的节点随后会读取分片数据并恢复 translog 中包含的数据。
我们看到事件的顺序如下：
- 原始数据节点在读取租约文件之前写入 translog。
- 主节点在新数据节点开始恢复之前（因此也在读取 translog 之前）将递增的节点离开生成写入租约文件。
- 对象存储保证了对租约文件和 translog 文件的先读后写（read-after-write）。
这里需要考虑两种主要情况：
- 原始数据节点写入了 translog 文件，并读取了一个租约文件，表明它仍在集群中且是分片的拥有者（primary term 没有改变）。
- 我们可以确定主节点在数据节点读取之前未成功更新租约文件。因此，原始数据节点对 translog 的写入发生在新节点分配读取 translog 之前，保证这些操作可供新节点进行恢复。
- 原始数据节点写入了 translog 文件，但在等待租约文件中的信息反映的新集群状态后，它不再是分片的拥有者（导致写入请求失败）。
- 我们不会成功响应该写入请求，因此不会承诺持久性。
- translog 数据可能在恢复期间对新节点分配可用，但这没问题。写入失败的请求实际上持久化了数据，这也是可以接受的。
因此，我们可以看到，Elasticsearch 成功响应的任何写入将对同一分片的未来拥有者可用，进而证明了我们的安全性论点。
同样，我们可以论证主节点故障转移的情况也是安全的。在这种情况下，coordination term 而不是节点离开生成会发生变化。我们这里不再详细说明。
这种相同的安全检查也应用于其他一些关键情况：
- 在索引文件删除期间。当 Lucene 合并段时，旧段可以被删除。我们在这里添加了安全检查，以防止删除新节点分配可能需要的文件。
- 在 translog 文件删除期间。当对象存储中的索引数据包含所有操作时，translog 可以被删除。同样，我们在这里添加了安全检查，以防止删除新节点分配可能需要的 translog 文件。
结论
恭喜，你已经读到了最后，希望你喜欢这里的深入研究。我们描述了一种新颖的机制，用于确保 Elasticsearch 持久安全地将写入持久化到对象存储，即使在出现任何类型的中断导致 Elasticsearch 有两个节点拥有对同一分片的索引的情况下也是如此。我们非常关心这些方面，如果你也这样做，也许可以看看我们的开放职位。
向 David Turner、Francisco Fernández Castaño 和 Tim Brooks 致敬，他们在这里完成了大部分实际工作。
准备好自己尝试一下了吗？开始免费试用。
想要获得 Elastic 认证？了解下一次 Elasticsearch 工程师培训何时开始！