分布式架构解析

分布式架构

分布式的一致性

在90年代中期，随着大型互联网系统的兴起，这些做法被重新审视。那时，人们开始考虑可用性可能是这些系统最重要的属性，但他们也在为它应该与什么进行交换而挣扎。系统教授Eric Brewer的加州大学伯克利分校,当时Inktomi,带来了不同的交换在主题演讲PODC 2000.1(分布式计算的原则)会议上他提出上限定理,即三个属性的数据共享系统数据一致性、系统可用性和公差网络partition-only两个可以实现在任何给定的时间。Seth Gilbert和Nancy lynch在2002年的一篇论文中给出了更正式的确认

不能容忍网络分区的系统可以实现数据一致性和可用性，通常是通过使用事务协议实现的。要做到这一点，客户端和存储系统必须是同一个环境的一部分;在某些场景下，它们作为一个整体失败，因此，客户端无法观察分区。一个重要的观察结果是，在较大的分布式系统中，网络分区是给定的;因此，一致性和可用性不能同时实现。这意味着对于放弃什么有两种选择:放松一致性将允许系统在可分区条件下保持高可用性，而将一致性作为优先级意味着在某些条件下系统将不可用。

这两个选项都要求客户端开发人员知道系统提供了什么。如果系统强调一致性，开发人员就必须处理这样一个事实，即系统可能无法进行写入操作。如果由于系统不可用而导致写入失败，那么开发人员将不得不处理如何处理要写入的数据。如果系统强调可用性，它可能总是接受写操作，但在某些条件下，读操作不会反映最近完成的写操作的结果。然后开发人员必须决定客户端是否一直需要访问绝对最新的更新。有一系列应用程序可以处理稍微陈旧的数据，它们在此模型下得到了很好的服务。

原则上，ACID属性(原子性、一致性、隔离性、持久性)中定义的事务系统的一致性属性是一种不同类型的一致性保证。在ACID中，一致性指的是保证事务完成时数据库处于一致状态;例如，当从一个账户向另一个账户转账时，两个账户中的总金额不应改变。在基于acid的系统中，这种一致性通常是编写事务的开发人员的责任，但是数据库管理完整性约束可以帮助实现这种一致性。

一致性：客户端和服务器
有两种观察一致性的方法。一个是从开发人员/客户的角度:他们如何观察数据更新。第二种方法来自服务器端:更新如何流经系统，以及系统对更新可以提供哪些保证。

客户端一致性
客户端有以下组件:

一个存储系统。目前，我们将把它看作一个黑盒，但是我们应该假设它是一个大规模的、高度分布式的东西，并且构建它是为了保证持久性和可用性。
进程a。这是一个读写存储系统的进程。
进程B和进程c是独立于进程A的两个进程，它们对存储系统进行读写。它们是同一个进程中的进程还是线程无关紧要;重要的是，他们是独立的，需要交流来共享信息。
客户端一致性与观察者(在本例中是进程A、B或C)如何以及何时看到存储系统中数据对象的更新有关。在下面演示不同类型一致性的例子中，进程A对数据对象进行了更新:
强烈的一致性。更新完成后，任何后续访问(A、B或C)都将返回更新后的值。
弱一致性。系统不保证后续访问将返回更新后的值。在返回值之前，需要满足许多条件。从更新到保证任何观察者都能看到更新值这段时间被称为不一致窗口。
最终一致性。这是弱一致性的一种特殊形式;存储系统保证，如果没有对对象进行新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，可以根据通信延迟、系统负载和复制方案中涉及的副本数量等因素确定不一致窗口的最大大小。实现最终一致性的最普遍的系统是DNS(域名系统)。对名称的更新根据配置的模式进行分发，并与时间控制的缓存相结合;最终，所有客户端都将看到更新。
最终一致性模型有许多重要的变化需要考虑:

因果一致性。如果进程A通知进程B它已经更新了一个数据项，那么进程B的后续访问将返回更新后的值，并且保证一次写操作将取代之前的写操作。进程C的访问与进程A没有因果关系，遵循通常的最终一致性规则。
“读己之所写”一致性。这是一个重要的模型，流程A在更新了数据项之后，总是访问更新后的值，永远不会看到旧的值。这是因果一致性模型的一个特例。
会话一致性。这是前一个模型的实际版本，其中进程在会话上下文中访问存储系统。只要会话存在，系统就保证“读己之所写”一致性。如果会话因为某种失败场景而终止，则需要创建一个新的会话，并且保证会话不会重叠。
单调读一致性。如果进程已经看到了该对象的特定值，那么任何后续访问都不会返回任何以前的值。
单调写一致性。在这种情况下，系统保证序列化同一个进程的写操作。不能保证这种级别一致性的系统是出了名的难以编程。
这些属性中有许多是可以组合的。例如，可以结合会话级别一致性获得单调的读取。从实际的角度来看，这两个属性(单调读取和read-your-write)在最终的一致性系统中是最理想的，但并不总是必需的。这两个属性使开发人员更容易构建应用程序，同时允许存储系统放松一致性并提供高可用性。

正如您可以从这些变化中看到的，相当多的不同场景是可能的。能否处理这些后果取决于特定的应用程序。

最终一致性并不是极端分布式系统的神秘属性。许多提供主备份可靠性的现代rdbms(关系数据库管理系统)同时以同步和异步模式实现它们的复制技术。在同步模式下，副本更新是事务的一部分。在异步模式下，更新以延迟的方式到达备份，通常通过日志传送。在后一种模式中，如果主备份在发送日志之前发生故障，从提升后的备份读取数据将产生旧的、不一致的值。另外，为了支持更好的可伸缩读性能，rdbms已经开始提供从备份中读取数据的能力，这是提供最终一致性保证的经典案例，在这种情况下，不一致性窗口取决于日志传送的周期。

服务器端一致性
在服务器端，我们需要更深入地研究更新如何流经系统，以理解是什么驱动了使用系统的开发人员可以体验不同的模式。在开始之前，让我们先建立一些定义:

N =存储数据副本的节点数

W =在更新完成之前需要确认已收到更新的副本的数量

R =通过读操作访问数据对象时所接触的副本数

如果W+R > N，那么写集和读集总是重叠的，可以保证强一致性。在实现同步复制的主备份RDBMS场景中，N=2、W=2和R=1。无论客户端从哪个副本读取数据，它都将得到一致的答案。在启用了从备份读取数据的异步复制中，N=2, W=1, R=1。在这种情况下，R+W=N，一致性无法保证。

这些配置是基本的quorum协议，它们的问题在于，当系统由于故障而无法写入W个节点时，写入操作必须失败，标志着系统不可用。当N=3 W=3且只有两个节点可用时，系统将不得不失败写操作。

在需要提供高性能和高可用性的分布式存储系统中，副本的数量通常大于两个。只关注容错的系统通常使用N=3 (W=2和R=2配置)。需要提供非常高读负载的系统经常复制超出容错要求的数据;N可以是数十个甚至数百个节点，R配置为1，这样一次读取就会返回一个结果。关注一致性的系统被设置为W=N进行更新，这可能会降低写入成功的可能性。这些系统关注容错性但不具有一致性，它们的一种常见配置是使用W=1运行以获得最小的更新持久性，然后依赖一种惰性(流行)技术来更新其他副本。

如何配置N、W和R取决于常见情况是什么，以及需要优化哪些性能路径。在R=1和N=W的情况下，我们优化读的情况，而在W=1和R=N的情况下，我们优化写的非常快。当然，在后一种情况下，在存在故障的情况下，持久性不能得到保证，如果W < (N+1)/2，那么当写集不重叠时，就有可能出现写冲突。

当W+R <= N时出现弱/最终一致性，这意味着读写集有可能不重叠。如果这是一个有意的配置，并且不是基于失败的情况，那么将R设为1以外的任何值都没有意义。这种情况通常发生在两种情况中:第一种是前面提到的为了读扩展而进行的大规模复制;第二个问题是数据访问更加复杂。在简单的键-值模型中，比较不同版本以确定写入系统的最新值很容易，但是在返回对象集的系统中，确定正确的最新值集就比较困难了。在大多数写集小于副本集的系统中，会有一种机制以一种惰性的方式将更新应用到副本集的其余节点。直到所有副本都被更新为止的时间段是前面讨论过的不一致窗口。如果W+R <= N，则系统容易从尚未接收到更新的节点读取数据。

“读你的写”、会话和单调一致性是否可以实现，通常取决于客户机对执行它们的分布式协议的服务器的“粘性”。如果每次都是相同的服务器，则相对容易保证“读己之所写”和单调的读取。这使得管理负载平衡和容错稍微困难一些，但这是一个简单的解决方案。使用会话，这是粘性的，使这一点显式，并提供了一个客户端可以推理的公开级别。

有时客户端实现read-your-write和单调读取。通过在写操作上添加版本，客户端将丢弃对版本在最后一个版本之前的值的读取。

当系统中的一些节点无法到达其他节点时，就会发生分区，但两个节点集都可以被客户端组访问。如果您使用传统的多数仲裁方法，那么具有W个副本集节点的分区可以继续进行更新，而另一个分区变得不可用。对于读集也是如此。给定这两个集重叠，根据定义，少数集变得不可用。分区并不经常发生，但确实会发生在数据中心之间以及数据中心内部。

在某些应用程序中，任何分区的不可用性都是不可接受的，重要的是能够到达该分区的客户机能够取得进展。在这种情况下，双方分配一组新的存储节点来接收数据，并在分区愈合时执行合并操作。例如，在Amazon中购物车使用这样的write-always系统;在分区的情况下，客户可以继续将商品放入购物车，即使原来的购物车存在于其他分区上。一旦分区恢复，cart应用程序将帮助存储系统合并购物车。

亚马逊的Dynamo
Amazon的Dynamo系统将所有这些属性置于应用程序体系结构的显式控制之下，这是一个键值存储系统，在组成Amazon电子商务平台的许多服务以及Amazon的Web服务内部使用该系统。Dynamo的设计目标之一是允许创建Dynamo存储系统实例(通常跨越多个数据中心)的应用程序服务所有者在一致性、持久性、可用性和性能之间以一定的成本进行权衡

总结
在大规模可靠分布式系统中，必须容忍数据不一致性，原因有二:提高高并发条件下的读写性能;以及处理大多数模型会导致部分系统不可用的分区情况，即使节点已经启动并运行。

不一致是否可以接受取决于客户机应用程序。在所有情况下，开发人员都需要意识到，存储系统提供了一致性保证，并且在开发应用程序时需要考虑到这一点。对于最终一致性模型有许多实际的改进，比如会话级一致性和单调读取，它们为开发人员提供了更好的工具。很多时候，应用程序都能够毫无问题地处理存储系统的最终一致性保证。一个特定的流行案例是一个网站，在其中我们可以有用户感知一致性的概念。在此场景中，不一致性窗口需要小于客户返回下一页加载的预期时间。这允许更新在预期下一次读取之前在系统中传播。

本文的目标是提高对工程系统复杂性的认识，这些系统需要在全球范围内运行，并且需要仔细调优，以确保它们能够交付应用程序所需的持久性、可用性和性能。系统设计者拥有的工具之一是一致性窗口的长度，在此期间，系统的客户可能暴露在大规模系统工程的现实中。

分布式的计算

分布式存储和一致性模型
当单片系统达到它们的极限时，它们开始被扩展的分布式系统所取代。这一趋势始于20年前的计算领域，当时大型机被服务器群所取代。然后进入了存储领域(数据库、文件系统)。在数据库世界中，关系与NoSQL的争论已经激烈了一段时间。

今天，我想和大家谈谈分布式数据存储平台和一致性模型。在规划存储基础设施时，这是一个非常重要的需求。

让我们从一些基础知识开始。在分布式系统中，假设单个节点会失效。系统必须对节点故障具有弹性。因此，为了冗余，数据必须跨多个节点进行复制。

在这种情况下，让我们问以下问题:“如果我在一个节点上执行写入(或更新)操作，我是否总是能看到所有节点上更新的数据?”

这似乎是一个无关痛痒的问题。每个人都会给出肯定的回答。“咄,当然!”。但不要这么快。

这在分布式系统中实际上是一个很难解决的问题，特别是在保持性能的时候。做出这种保证的系统被称为“严格一致”。然而，许多系统采取了简单的方法，只提供最终的一致性。

最终一致性vs严格一致性
让我们定义最终一致性和严格一致性。

最终一致性
下面的视频演示了最终一致性的过程。

过程总结

从客户机写到节点1
从节点1向客户端确认
最终写入通过集群传播到节点2
观察

System finally return latest write:通过添加单词“finally”来削弱一致性条件
如果节点失败可能导致数据丢失:添加“假设没有永久故障”的条件。
严格的一致性
下面的视频演示了严格一致性的过程。

过程总结

从客户机写到节点1
写入通过集群传播，从节点1传播到节点2
从节点2到节点1的内部确认
从节点1向客户端确认
观察

系统总是返回最新的写操作:对于任何传入的写操作，一旦客户端确认了写操作，从任何节点读取的更新值都是可见的。
有保证的数据弹性:对于任何传入的写操作，一旦向客户端确认了写操作，更新就会受到冗余节点故障的保护。
系统并不总是使用严格的一致性
显然，严格的一致性更好，因为可以保证用户总是看到最新的数据，并且数据在写入时就受到保护。下图比较了两种一致性模型。

严格与最终一致性

为什么不总是使用严格的一致性?
主要是因为实现严格的一致性会显著影响性能。具体来说，延迟和吞吐量将会受到影响。影响的程度取决于具体情况。

严格的一致性并不总是必需的，在某些用例中最终的一致性可能就足够了。例如，在购物车中，假设添加了一个项目，但数据中心失败了。对客户来说，再次添加该项目并不是一种灾难。在这种情况下，最终的一致性就足够了。

然而，你不希望你的银行账户刚刚存入的钱发生这种情况。因为节点失败而导致资金消失是不可接受的。财务交易要求严格的一致性。

为什么企业存储需要严格的一致性
在企业存储中，存在最终一致性是正确模型的情况，例如跨站点复制的例子。但在绝大多数情况下，严格的一致性是必需的。让我们看几个需要严格一致性的例子。

扩展文件存储
碰巧有一种主要的扩展文件存储系统只提供最终的一致性。数据只写入一个节点(NVRAM上)并被确认。一个企业客户曾经向我解释说，在负载过重的情况下，一个节点可能会被标记为脱机。实际上，它是关闭的，导致客户端在几秒钟前成功编写的文件出现“文件未找到”错误。这对它们的应用程序造成了严重破坏。

从备份中即时恢复
下一代扩展备份解决方案提供了从备份中即时恢复VM。这样的解决方案从备份系统上的备份映像副本引导虚拟机。备份系统在恢复期间充当主存储，直到可以使用storage vMotion将数据移动回原始数据存储为止。好处很明显:你可以尽快恢复业务。

然而，许多扩展备份解决方案只提供写操作的最终一致性。因此，如果恢复节点上发生故障，应用程序就会失败，系统就会丢失生产VM的实时数据。

数据保护
严格的一致性保证用户总是能看到最新的数据，并且数据一旦写入就受到保护。由于严格的一致性，即使基础设施出现故障，也能保证应用程序可用性/正常运行时间和没有数据丢失。

在设计备份环境时，应当首先考虑向外扩展文件存储和从备份中立即恢复的这些事项。

VM环境中的一致性模型
VMware vSphere和VMware Cloud Foundation等基础架构需要数据弹性和高可用性。对于这样的环境，严格一致性和最终一致性意味着什么?

对于任何使用传统或现代数据保护和恢复解决方案的组织来说，一致性模型都存在风险和问题。不幸的是，人们对这个话题的认识和理解非常缺乏。

供应商提供传统和现代的数据保护和恢复解决方案。它们提供VM或数据的快速恢复，并具有一种称为即时恢复的特性。其目标是最小化停机时间，即恢复时间目标(RTO)。

但是，根据供应商和客户的基础设施的不同，恢复工作流和实现是不同的。

数据保护
可以执行一系列恢复功能(手动或自动)来恢复VMware vSphere等环境。通常，数据保护和恢复解决方案(存储VM或数据的副本)提供某种形式的存储抽象。vSphere将为此提供额外的计算资源。

数据恢复
在恢复VM之后，必须将它迁移回主存储平台。在vSphere中，存储vMotion用于在网络上迁移数据。可以在几分钟内恢复并实例化一个VM。

然而，如果这意味着要在网络中移动数百gb，那么在几分钟内恢复是不可能的。根据在网络中传输的大小和容量不同，这个过程可能需要很长时间才能完成。低时间将取决于网络带宽、接口饱和等。

数据保护和恢复的最终一致性
本视频演示了vMotion使用最终一致性恢复vSphere环境的过程。

过程总结

准备VM并将其作为NFS卷在本地存储抽象上恢复。在最终一致性模型的基础上，从单个节点对vSphere进行了抽象。
从数据保护和恢复集群中的一个节点挂载NFS存储抽象。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在单个节点的存储抽象(NFS)上的VM。
此时正在创建的新数据不受保护。它不分布在数据保护和恢复集群中的其他节点上。
SvMotion开始将VM迁移回主存储平台。这可能需要很长时间，具体取决于环境。
如果数据保护和恢复集群中的某个节点在恢复到vSphere时发生故障，将会发生以下情况:
vSphere无法访问存储抽象(NFS)
VM不再可用或不可访问
SvMotion失败
任何新创建的数据都可能丢失
当您依赖数据保护和恢复解决方案作为保险策略时，这是不可接受的结果。其结果——取决于失败的程度——可能会让一家公司倒闭，或者至少会让某些人丢掉工作。

数据保护和恢复严格一致
本视频演示了使用vMotion使用严格的一致性恢复vSphere环境的过程。

以下步骤是企业应该期待的。这是他们应该从数据保护和恢复解决方案中要求的。

在本地准备VM并将其恢复到一个存储抽象上，该存储抽象以NFS卷的形式呈现给vSphere。在严格一致性模型的基础上给出了该抽象。
自动将存储抽象从一个来自Cohesity集群的虚拟IP呈现并挂载到vSphere (NFS)。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在存储抽象(NFS)上的VM, NFS来自Cohesity集群的虚拟IP。
创建的新数据被分发到Cohesity集群中的其他节点并得到确认。
SvMotion启动VM迁移回主存储平台——这可能需要很长时间。
如果Cohesity集群中的一个节点发生故障，提供给vSphere的存储抽象(NFS)仍然可用。由于使用了虚拟ip和严格的一致性，SvMotion将持续到完成为止，这共同降低了数据丢失的风险。

分布式的切换队列

什么是暗示的切换队列？
尽管有一个很酷的名字，暗示切换（HH）队列并没有得到很多关注。HH队列有一项非常重要的工作，但是除非您是系统管理员，否则很少直接与它交互。让我们深入研究一下暗示的切换队列到底是什么，以及为什么它对您很重要。
为了讨论HH队列，我们必须稍微讨论一下分布式计算。像XDB Enterprise这样的系统作为分布式系统存在的一个原因是消除单点故障。InfluxDB Enterprise使用复制因子（Replication Factor，RF）来确定任何一组数据应该存在多少个副本。将RF设置为1以上意味着系统有更高的机会成功地为请求提供服务，并且在数据节点中断期间不会返回错误，这意味着我们不再只有一个可能丢失或不可用的数据副本。分布式系统也提出了独特的挑战：我们如何知道数据在整个系统中是一致的，尤其是在存储多个数据副本时？
首先，我们必须理解最终一致性所作的一些承诺。扰流板警报：系统中的数据最终必须一致。当我们从分布式系统请求信息时，有时我们收到的答案可能不会一致地返回。当数据在整个系统中存储和复制时，我们收到的答案有一些“漂移”，但随着时间的推移，这种“漂移”应该被消除。在实践中，这意味着最近的时间范围可能在其结果中具有最大的变化，但是这种变化被消除，因为系统通过确保在任何地方都可以获得相同信息的机制工作。
如果我们保证系统最终是一致的，我们如何解释失败的写入？数据节点离线的原因有很多，从磁盘空间耗尽到普通的旧硬件故障。如果一个节点在离线时丢失了数据点，它就永远不可能是一致的，因此，我们对最终一致性的承诺将变成谎言。
失败的写入也会影响整个系统的复制系数。维护指定的RF是我们必须遵守的另一个承诺，如果数据节点脱机，这也是写入的另一个可能的失败点。
例子
让我们研究一下最简单的示例：具有2个数据节点和一个RF=2的数据库的XDB Enterprise。数据通过某个收集代理（例如Telegraf）到达您喜爱的负载平衡器，负载平衡器将写操作（也读取，但在本例中我们将使用写操作）分发到底层数据节点。通常，负载平衡器以循环方式分发写操作。接收数据的数据节点存储并复制数据（将其发送到另一个数据节点），瞧：RF达到2。
我们仍然需要一个失败或延迟写入的解决方案。假设系统中的一个节点在物理上过热并离线。如果没有备份，任何不成功的写入都会被完全删除，再也看不到。

进入HH队列。

HH队列是一个持久的、基于磁盘的队列。它是XDB企业的一个基本部分，它试图确保最终的一致性，这是一种机制，确保所有的数据节点最终在它们之间拥有一组一致的数据。对于xdbenterprise，HH队列是实现最终一致性和确保最终实现每个数据库的数据复制因子的一个重要部分。
现在，让我们重温一下集群中的一个数据节点离线的场景。节点脱机的原因有很多：硬件缺陷、磁盘空间限制，甚至是定期维护。如果没有暗示的切换队列，不成功的写操作在存储之前就死了，但是现在我们有了一个安全的地方让它们着陆。
任何不成功的写入都会被定向到HH队列，当节点恢复联机时，它会检查HH队列中是否有挂起的写入。然后节点可以完成写操作，直到队列耗尽。Bam最终实现了一致性。

分布式的反熵

什么是反熵？
如果您阅读了本系列第一部分中的暗示切换队列，您已经知道暗示切换队列如何在数据节点中断期间保存数据并帮助您确保最终的一致性，但是在分布式系统中有很多方法会出错。尽管我们尽了最大的努力，仍然有丢失数据的方法，我们希望尽可能减少这种情况。进入保持最终一致性的后半部分：反熵（AE）。
如果我们反对熵，我们应该知道它是什么。根据互联网和我那些有科学头脑的朋友的说法，熵是由热力学第二定律定义的。基本上，随着时间的推移，有序系统趋向于更高的熵状态；因此，熵越高，无序越大。我们反对时间序列数据中的无序，因此反对熵。
忘记任何恐吓因素这个词本身有反熵只是一个服务，我们可以运行在XDB企业中检查不一致性。我们知道，当我们收到来自系统的信息时，我们可能会要求得到一致的答案。由于引入“漂移”的方式多种多样，我们需要一个能够识别和修复底层数据差异的英雄。AE可以成为那个英雄。

例1
让我们回到我们的经典集群：包含2个数据节点和一个复制因子为2的数据库的XDB Enterprise。
系统运行良好，发送数据以进行存储和复制。对于我们的数据来说，这是一个幸福的时刻，但有时我们必须努力做到这一点。分布式系统经常变化，而处理这种变化往往首先会干扰一致性。

系统中最常见的变化之一是硬件，所以让我们探索一条新的和改进的AE可以发挥作用的途径。假设节点2有一些坏硬件。也许它有缺陷或只是旧的，但它放弃了鬼魂在半夜（因为它当然会在半夜）。

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

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

在我们的示例中，我们的首要任务是使节点2重新联机，以便它可以恢复在系统中读取和写入数据的正确位置。我们可以使用InfluxDB Enterprise中的“replace node”命令将node 2与其新硬件重新连接起来。

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

例2
HHQ有一些实际的限制，但它不能永远保持。在XDB Enterprise中，它默认为10GB，这意味着如果大小超过10GB，最早的点将被删除，以便为新数据腾出空间。或者，如果数据在HHQ中存放的时间太长（xdb Enterprise中的默认值是168hrs），它将被丢弃。HHQ是为了临时中断和修复，可以很快解决，所以它不应该无限期地填补。它解决了最常见的情况，但HHQ只能承担这么多的负担。

在“故障”时间较长的场景中，我们希望相同的两个节点之间存在更大的数据漂移空间。如果一个节点关闭并且在很长一段时间内未被检测到，HHQ可能会超过存储、时间限制、并发或速率限制，在这种情况下，它要转发的数据将消失在遗忘中。不太理想。当然，可能会发生大量潜在的边缘情况：HHQ和AE服务的目标是提供一种方法，以确保最终的一致性，而不需要人类付出最小的努力。

在其他系统中，一旦节点2消失，用户就有责任确保节点得到修复并恢复到一致的状态，可能是通过手动识别和复制数据。说实话：谁有时间？我们有工作要做，还有华夫饼要吃。

从XDB Enterprise 1.5开始，AE检查集群中的每个节点，看看它是否拥有meta store所说的所有碎片。区别在于，如果缺少任何碎片，AE会从另一个拥有数据的节点复制现有碎片。任何丢失的碎片都会被服务自动复制。从XDB Enterprise 1.6开始，可以指示AE服务跨节点检查碎片中包含的数据的一致性。如果发现任何不一致，AE可以修复这些不一致。

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

从更基本的角度来说，AE服务现在可以识别丢失或不一致的碎片并修复它们。这是自愈的最佳状态。不用担心集群的当前状态，我们可以调查失败的原因（在本例中，我们可能是在睡觉或吃华夫饼，尽管这并不总是那么简单）。

关于AE有一些重要的事情要知道。AE只能在至少有一个碎片副本可用时执行其英雄行为。在我们的示例中，RF为2，因此我们可以依赖Node 1来复制健康的shard。如果节点2有该碎片的部分副本，则比较这些碎片，然后在节点之间交换任何丢失的数据，以确保返回一致的答案。如果用户选择RF为1，那么他们会选择节省存储空间，但会错过高可用性，并且会受到更有限的查询量的限制。这也意味着AE将无法进行修复，因为一旦数据不一致，就没有真相的来源了。另一个警告是AE不会比较或修复热碎片，这意味着碎片不能有活动写入。热碎片更容易改变，在任何给定的时刻，新数据的到来都会影响AE的摘要比较。当碎片变冷或不活动时，数据不会改变，AE服务可以更准确地比较摘要。