FAIL-FAST失败了很快

3月25日，2021年第19卷，问题1超过40年，失败速度是实现容错的主导方式。在这种方法中，某些机制负责确保每个组件都已启动，运作和响应工作。只要它仍然活着和健康，你继续前进;当有些东西与组件开始时，它被从系统中删除，其余组件重新组件重新组件以继续。对于许多（但不是全部）系统，这就是当碎片失败时，确保系统保持活力。

随着行业的举动效率云计算，这越来越具有挑战性。首先，我喜欢云计算，并认为这是前进的重要一步。尽管如此，我们创建强大的解决方案的方式受到压力，因为各个组件的出现挑战称为灰色故障。在灰色故障中，服务器或网络的一部分并不快速失败，而是开始运行速度。跑步缓慢是差的，而不是快速失败。缓慢的成分，有时以不到一个百分之次运行的正常速度，可能是足够的健康来说，＆＃34;我仍然在这里！＆＃34;但足够缓慢地堵塞所有的工作。这使得失败的方案易受攻击。

回到几天，服务器的硬件在您的数据中心处于紧密控制的环境中。一些销售人员确信您需要最好，最昂贵，最昂贵的服务器。你知道如果你买了那些服务器，你会被解雇。连接这些服务器意味着您只有一个仅支持您的东西的本地网络。您可以确保在当地网络中运行的流量而不是拥挤。因此，各个服务器可以响应可预测的是高优先级消息，例如，＆＃34;如何＆＃39;你在做，好朋友？＆＃34;这些消息通过过度传播的网络飞行，如在周日早上4点到旧金山乘坐101号高速公路。

利用这些非常可能的答案来查询健康，很容易监督服务器施加健康或疾病的规则。预计此健康检查的答案时间是答案。如果响应花了太久，你会再试一次。你没有答案的时间越长，滞后服务器就越有可能真的生病。经过合理少的尝试后，您可以放弃并宣布派对大便者被排除在派对之外。是的，这个决定是概率的，但赔率真的，真的很好，你可以做得很快。

接下来，很重要的是排除叛徒节点。将其发送到停止和停止可能或可能没有差异的消息。这通常被称为Stonith（拍摄头部的其他节点）。有时另一个节点有一个坚硬的头部和stonith并在工作。另一个诀窍是确保放弃的节点不能造成任何伤害。如果您可以保证任性节点可以＆＃39; t在节点外部进行任何变化，团队的其余部分可以随身携带。让它在孤独腐烂。

以这种方式，您可以检测到节点失败，并确保它完全失败。在过去，它没有花费太多时间来做这件事。

有一个叫Bridan＆＃39;屁股的悖论，以14世纪的哲学家吉迪达命名。 7个Bidan＆＃39; S屁股突出了一个明显的矛盾，固有的确定主义概念或相信每个活动都来自以前的事件。悖论提出，一个非常饥饿的驴子恰好位于两块干草之间。假设驴会去最近的资源，它将饿死。

在电子器件中，存在称为稳定性的现象，这意味着系统可以处于不受约束的时间不稳定状态。要使有效信号作为输出电路，它必须驻留在某个电压或电流范围内。如果输出在中间灰色区域的土地，欠下的事情发生在下一个电路。它也可以做奇怪的事情。

此常规性是异步电路内的固有。由于您不知道输入信号的定时，因此各种输入同时到达的一些时间，电路可以在两个干草包之间决定。异步数字系统通常将仲裁器添加到输入信号以确保信号被排序，因此，避免衡量性。在同步设备上的时钟域内，时钟可确保提供给逻辑电路的输入的定时，避免了衡量性问题。由于同步电路接收传入异步信号，特殊同步器的工作使衡量变小但仍然可能的稳定性。

在复杂的云计算环境中进行分布式系统的升力和转移为分布式系统设计构成了一堆新问题。在虚拟机中运行服务器提供了很多有价值的计算，以获得良好的价格，但它可能根据自己的时间框架进行。嘈杂的邻居问题是指虚拟机的不同容量，因为它与相同物理服务器上的其他虚拟机竞争资源。 Multicore Servers添加到您的协调可能或可能不会停止您希望发送的消息。通过云网络基础设施的旅行可能会经历造成的拥塞通信，模拟美国邮政服务。这使得基于定时器的失败概率。它始终是概率，但现在赔率已经转移了远离微量概率，以简单地是非常难以调试的罕见概率。

之前，当分布式系统由可预测的服务器和网络组成时，您的队列会如何回答健康检查的态度。使用该期望，您可以快速删除生病节点，同时只删除一个健康的节点。这是一个概率游戏，赔率非常高，你会做出正确的决定。这与在时钟域内工作的电路很像，以避免亚稳态行为。

服务器和/或往返于他们的消息，不要以可预测的速度工作。它与移除同步电路内的时钟相同，所以它是一个异步数字系统的＆＃39。阻尼和去除亚稳定性的可能性变得更低。

考虑一支戏耍者在舞台上处理数十个球的队员。如果其中一些以非相关的方式被发送到慢动作，则可能是一个问题。 jugglers拥有自己的时间框架，他们看到球到达时到达。一段短暂的虽然这可能是有意义的。每次Juggler＆＃39，几乎不可能将基于时间的时间基于时间的互动变得非常迅速，减慢了他们的时间。

当分布式系统的旧部署被提升到云中时，它就像在嘉年华的有趣区的旅行时一样＆＃39;时间和距离变得扭曲，失败的决策变得不可预测。当服务器Don＆＃39; T 3月大约达到同一个鼓手的节拍时，分布式系统算法可以成为亚稳定性的。

更糟糕的是，大多数系统依赖于数据中心的其他系统。 HDFS（Hadoop分布式文件系统）取决于Apache ZooKeeper。 1个zookeeper和其他服务取决于DNS（域名系统）。这些系统中的每一个都具有超时和重试，这可能导致级联延迟，超时和故障。这是另一种形式的衡量性，可以强调问题而不是抑制它们。

当这种衡量性干扰了分布式系统中的主要或领导者时，您不会迅速访问＆＃34;完美的真理＆＃34;或者是许多系统所需的线性化。可用性可能会受到相当的影响。

让我们注意我们注意算法的重要性，即不授权完美的最新答案。当对用户的请求基于包含陈旧状态的副本池时，任何一个副本都足够了。用新状态更新副本的背景工作可能落后一点，而且＃39;好的。 ＆＃34的一个很好的例子;相当好＆＃34;在您在网上零售中读取产品目录或产品评论时，可以找到。同样，在Web搜索中，您可以访问查询中搜索术语的所有碎片。每个请求都不重要，每个请求返回绝对最近的结果。 ＆＃34;相当好＆＃34;很漂亮。

将工作发送到带有这些缓存副本的服务器池时，客户端可以超时并重试绑定延迟。它并不真正关心一个单独的服务器的健康状况，因为客户可以通过使用称为对冲的技术重试，从另一个服务器获得一个很好的答案。 3无响应服务器的状态暂时不太重要。让它在不确定状态下生活时是含量的。坦率地说，你没有关于服务器的完美答案和＃39;群体的成员资格。随着时间的推移，它将开始表现得更好，或者它将被扔掉群集。不需要匆忙追究完美的答案。

伐木具有类似的新出现耐受算法。 Apache Bookkeeper 2是一个开源记录子系统，其中写入要将新记录附加到日志，无需到达包含日志副本的所有日志服务器。获取所需子集足够。类似地，通过AWS（亚马逊Web服务）提供的Amazon Aurora，8,9在集中式服务器中运行一个数据库，但将其更新发送到存储服务器池中。因为并非所有存储服务器都需要及时响应，所以簿记员和奥罗拉使用的方法在服务器中大大增加了延迟。个人复制品可以在自己的时间扭曲中生活，更广泛的分布式算法愉快地进行。

我认为这是在河里流动的岩石流动的水。通过足够的工作通过急剧更具弹性，而不是坚持所有工作通过。

当传统算法依赖于集群中的完美知识时，您能做什么？许多系统都建立了期望完美的知识，以提供完美的答案。例如，HDFS 6具有责任数据页的分配的NameNode。除非HDFS知道您一次拥有零或一个主要的NameNode，否则文件系统可能已损坏。

当一个服务器快速失败时，它被替换，群集周围的数据杆，很快，你＆＃39;重新开始。

HDFS取决于失败作为其性欲的模型。我担心持续使用失败的能力，仍然遵循那个旧时的座右铭观看商业：＆＃34;它需要一个舔但是滴答作响。＆＃34;

好吧......在超现实主义世界之上运行时，一些算法确实是稳定的。然而，有些人不是。任何依赖于一组固定的响应服务器的算法都会越来越一致的可直线化数据将越来越多地看到稳定性集群趋势的趋势。

群集部分可能会感知与其他部分的时间差异有多种原因：

•服务器或VM不会在一段时间内获得计算的预期金额。

•网络不提供一对服务器的公平份额，造成延误。

•数据中心中的硬件表现不可预测，特别是随着这些组件的价格被驱动下来。 5.

•增加可能导致由于超时而导致级联不良的服务的依赖性。

我想强调我认为这是一件好事。而在我的梦中，在办公室里，有一个专门的高速公路车道，＆＃39不是真正的实用性，这将是我的通勤家庭。相反，我们尽管允许在没有任何约束的情况下允许许多传入流量的延迟的固有风险，但仍然共享高速公路车道。我们中的许多人都可以建立一个致力于我们个人使用的高速公路;因此，我们分享。云计算正在共享。

现实生活中也是如此。如果你住在一个带着散步的上海房子的小镇，你可以在每天6点23分之前预测地走在前门。当你搬到大城市，带电梯，停车车库和高速公路到横穿，它就更加努力地到达您的到来。

•我们如何弥补云环境中的这些常规性问题？添加资源有帮助吗？

•社交方面，人类倾向于在有问题之前过度过度资源。我们会永远屈服于公共场地的悲剧，并吸收所有的松弛，直到我们融化？

•哪些算法可以为我们提供清晰和明确的线性更新和快速延迟99.9％的时间？ 99.999％的时间有多？当环境受压力下，这些如何应对？

•我们如何远离对我们容忍和抑制大多数常规性的世界敏感的算法敏感的算法？

3. Dean，J.，Barroso，L. A. 2013.尾巴以级别为例。 ACM 56（2），74-80的通信; https://cacm.acm.org/magazines/2013/2/160173-the-tail-at-cale/fulltext。

4.灰色，J. 1985.为什么电脑停止，可以做些什么？串联技术报告TR 85.7; https://www.hpl.hp.com/techreports/tandem/tr-85.7.pdf.

5. Gunawi，H. S.等人。 2018年。扩展失败：大型生产系统中硬件性能故障的证据。第16届Usenix档案和储存技术会议的诉讼程序; https://www.usenix.org/system/files/conference/fast18/fast18-gunawi.pdf。

8. verbitski，A.等。 2017.亚马逊Aurora：高吞吐量云原生关系数据库的设计考虑因素。 ACM数据管理会议的诉讼程序，1041-1052; https://dl.acm.org/doi/pdf/10.1145/3035918.3056101。

9. Verbitski，A.等人。 2018.亚马逊奥罗拉：避免为I / O，提交和成员资格更改的分发达成共识。 ACM管理数据管理会议课程，789-796; http://pages.cs.wisc.edu/~yxy/cs839-s20/papers/aurora-sigmod-18.pdf。

Pat Helland自1978年以来一直在实施事务系统，数据库，应用平台，分布式系统，容错系统和消息传递系统。对于娱乐，他偶尔会写下技术文件。他在Salesforce工作。他的博客是pathelland.substack.com。

最初在队列卷发布。 19，没有。 1-在ACM数字库中查看此项目

相关：Martin Kleppmann，Alastair R. Beresford，Boerge Singen - 在线事件处理支持异构存储技术的分布式交易是不存在的或遭受差的操作和性能特征。相比之下，OLEP越来越多地用于在这种环境中提供良好的性能和强的一致性保证。在数据系统中，将日志作为内部实现详细信息非常常见。 OLEP方法不同：它使用事件日志，而不是事务，作为数据管理的主要应用程序编程模型。仍然使用传统数据库，但其写入来自日志而不是直接从应用程序。 OLEP的使用不仅仅是开发人员的实用主义，而是提供了许多优势。

Andrew Leung，Andrew Spyker，Tim Bozarth - Titus：将容器引入Netflix Cloud我们认为我们的方法使Netflix能够快速采用和受益于容器。虽然细节可能是Netflix特定的，但通过与现有基础设施集成并与正确的早期采用者合作提供低摩擦集装箱采用的方法可以成为希望采用容器的任何组织的成功策略。

Marius Eriksen - Scale现代服务器软件的功能要求开发和操作：它必须在所有时间和所有地点都提供;它必须在毫秒内回复用户请求;它必须迅速响应容量需求;它必须处理大量数据甚至更多的流量;它必须快速调整更改产品需求;在许多情况下，它必须容纳一个大型工程组织，其许多工程师在一个大型凌乱的厨房里烹饪烹饪。

Caitie McCaffrey - 验证分布式系统Leslie Lamport，以其在分布式系统中的开创性工作而闻名，着名，＆＃34;分布式系统是您甚至没有知道存在的计算机的失败可以呈现你的自己的计算机无法使用。＆＃34;鉴于此黯淡的前景和大量可能的故障，您甚至如何开始验证并验证您构建的分布式系统正在进行正确的事情？