看看 Pat 的
关于分布式系统的零散思考
pathelland.substack.com
逃离奇点
PDF逃离奇点
这已不再是您祖母的数据库了！
空间时间不连续性
合并来自多个数据源的数据可能会导致令人痛苦的延迟。
Pat Helland
越来越多的计算基于来自多个来源的定时事件。通过比较、对比、连接和细致研究这些输入，您可以得出一些有趣的结果。如果这些计算的输入来自不同的计算机（或传感器），您无法始终确定信息传播的速度。因此，您无法确定何时能获得所请求计算的答案。
如果您无法承诺何时获得答案，您会怎么做？您可以等待获得完美的答案，或者您可以基于部分知识，更及时地给出不完美的答案。
您如何满足您的 SLA（服务级别协议）？有时，这并非简单且无缝的连续性选项，而更像是一种不连续性。
事件和时间
在许多系统中，事件都带有时间戳。这些可能来自温度传感器、运动探测器、工厂车间、您的有线电视机顶盒、您的安全系统、高速公路上的自动收费站等等。一个日益重要的信息来源是数据中心中事件的监控。这些事件可能被自动化管理系统或人工用于复杂的错误探查。通常，人们会尝试查看哪些事件在时间上与另一个特定事件接近。时间邻近性模式对于控制这些复杂环境至关重要。
事件和空间
现在，所有这些都很酷，除非您想要的信息“在那里”。在分布式系统中，如果东西不“在这里”，它就“在那里”。当某物遥远且在彼处时，信息的传入和传出可能需要很长时间。这有点像峡谷中唯一的道路被洪水冲毁时的情况。我将远程节点称为“在远处”，无论它们是在数据中心的同一机架中还是在数千英里之外。
空间、距离和交通拥堵
如果它在“那里”，并且具有开放排队网络，那么它通常会及时到达这里。几乎所有现代网络都是开放排队网络。在这种网络中，尝试共享网络的流量量实际上没有限制。旧金山 101 公路是一条开放排队网络。它在正常情况下运行良好，直到出现问题。
现在，我正在飞机上写这篇文章。我很高兴现代电传操纵系统使用封闭排队网络。这种类型的网络仔细管理允许进入的消息。通过确保网络永远不会接收更多的工作，它可以确保网络消化已有的工作量的时间是有限的。假设没有硬件故障（或有限数量的硬件故障），封闭排队网络可以在指定的时间段内完成所请求的工作。我不希望控制飞机襟翼的电传操纵系统出现交通拥堵。我感谢封闭排队网络。
另一方面，在数据中心中，您看不到封闭排队网络。相反，您看到的是一条通常有很多车道的高速公路。它通常运行良好。
回顾我们的排队
事件传播的延迟不仅仅是由网络引起的。事件在发布时通常会被推送到某些排队系统中。然后，已发布的事件会被一个或多个订阅者消费。当事件像苍蝇一样在数据中心或互联网中嗡嗡作响，试图寻找其目的地时，这些订阅者通常会将事件排队到另一个队列中（无穷无尽）。
误解我们的排队
每个排队系统都带来了全新的延迟机会。这几乎就像事件被冻结在时间中，并有望在期望的时间窗口内解冻。这些排队系统的每个阶段都很可能快速传播事件。每次您添加“很可能快速传播事件”时，您也会添加“有时它会很慢”。
排队系统不仅可能很慢，而且它们很少有端到端保证。除非最终消费点与始发发送者协调，否则事件有时会崩溃并永远不会到达。
服务级别
服务级别是为客户工程设计系统的关键组成部分。这些可能涉及系统性能、系统可用性或返回结果的质量：4,5
• SLA（服务级别协议）。这是与客户的合同。如果您未达到指标，它可能会列出经济补偿。这可能是与您的老板达成谅解，如果事情进展不顺，您将错过部分奖金。
• SLO（服务级别目标）。这是您针对所讨论指标的内部目标。您始终希望您的 SLO 比您的 SLA 更好（否则您就不是在努力让您的客户满意）。
• SLI（服务级别指标）。这是您实际针对指标衡量的指标。希望您的 SLI 比您的 SLO 更好，而 SLO 又比您的 SLA 更好。
为了确保合并来自许多不同来源的事件，您应该在您的 SLA 中留出一些空间，以允许从所有这些来源获取源数据的速度较慢。来源越多，当其中一个或多个来源超出其 SLA 时，您就越有可能超出您的 SLA。
管理幂等操作中的尾部延迟
我最喜欢的论文之一是 Jeff Dean 和 Luis André Barroso 的“The Tail at Scale”。1 在本文中，作者概述了一个需要大量输入的服务如何使用基于超时的重试来显着提高获得满足所需 99.9% 响应 SLA 的所有输入的概率。在这种情况下，存在足够的副本来获得答案而不会损失质量，只需重试并消耗更多资源即可。关键在于重试滞后请求是可以的，因为它们是幂等的。执行两次或更多次不会造成损害。
知道你不可能知道
输入集越复杂，您就越有可能无法及时看到所有内容。存储转发排队越复杂，东西就越有可能到达太晚或根本没有到达。您的输入源越远，您可能遇到的挑战就越多。
正如我们所见，有时重试输入请求可能有效。特别是，在某些系统中，重试可以确保所有输入都快速可用。
在其他系统中，输入不仅仅是被获取，而是在类似于旧金山 101 公路的队列中嗡嗡作响。在这些环境中，处理可能必须简单地用它拥有的东西来截断，并尽力而为。这意味着您无法保证东西会在您需要时准备好。
因此，如果您知道您只能可能知道，那么计划是什么？
近似查询
有一些有趣的新工作描述了使用近似答案进行分析。通过表达抽样运算符，某些系统可以基于通常检查的所有输入的一小部分子集，提供非常好的答案。2,3 在引用的系统中，当一切正常且及时时，更多地关注抽样以提高性能。尽管如此，它与您构建系统以基于及时可用的内容返回答案的方式非常相似。
返回部分答案
许多系统都在努力及时给出一些答案，即使它们受到损害。许多复杂的网站会在部分答案可用时，将其滴流式传输到浏览器：产品描述的文本可能在产品图像之前到达；产品图像可能在用户评论之前到达。这种解耦产生了更快的整体结果，并且通常会让用户更满意。
当处理依赖于来自远处的数据的答案时，重要的是要考虑如何解耦结果，并在可能的情况下，在最符合业务需求时，快速返回降级的答案。继续前进需要什么？
正如 Monty Python 的黑骑士所说，“‘Tis but a scratch”（https://www.youtube.com/watch?v=ZmInkxbvlCs；感谢 Peter Vosshall 在我们多年前都还年轻时，在讨论中提出黑骑士）。
令人不安的不连续性
当您只有一个数据库供应用程序担心时，您不必考虑部分结果。您也不必考虑数据在其他数据之后到达。一切都在那里。
现在，您可以使用大型分布式系统做更多的事情，但是您必须在及时答案和完整答案之间的权衡中更加成熟。最好的系统会适应并将其问题解释为“‘Tis but a scratch！”。
参考文献
1. Dean, J., Barroso, L. A. 2013. The tail at scale. Communications of the 56(2), 74-80; https://dl.acm.org/citation.cfm?id=2408794.
2. Hall, A., Tudorica, A., Buruiana, F., Hofmann, R., Ganceanu, S., Hofmann, T. 2016. Trading off accuracy for speed in PowerDrill. International Conference on Data Engineering; https://ai.google/research/pubs/pub45682/.
3. Kandula, S., Lee, K., Chaudhuri, S., Friedman, M. 2019. Experiences with approximating queries in Microsoft's production big-data clusters. Proceedings of the VLDB Endowment 12(2), 2131-2142; https://www.microsoft.com/en-us/research/publication/experiences-with-approximating-queries-in-microsofts-production-big-data-clusters/.
4. Moguls, J. C., Isaacs, R., Welch, B. 2017. Thinking about availability in large service infrastructures. Proceedings of the 16th Workshop on Hot Topics in Operating Systems (HotOS'17), 12-17; https://dl.acm.org/citation.cfm?id=3102980.3102983.
5. Moguls, J. C., Wilkes, J. 2019. Nines are not enough: meaningful metrics for clouds. Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS'19), 136-141; https://dl.acm.org/citation.cfm?id=3321432.
相关文章
服务可用性的计算
您的可用性仅取决于您的依赖项的总和。
Ben Treynor, Mike Dahlin, Vivek Rau, Betsy Beyer
https://queue.org.cn/detail.cfm?id=3096459
迈向更高精度
PTP 及其对 NTP 从业者的意义介绍
Rick Ratzel 和 Rodney Greenstreet
https://queue.org.cn/detail.cfm?id=2354406
资源管理的一课
不要浪费内存，除非这无关紧要
Kode Vicious
https://queue.org.cn/detail.cfm?id=2523428
Pat Helland 自 1978 年以来一直从事事务系统、数据库、应用程序平台、分布式系统、容错系统和消息传递系统的实施工作。为了消遣，他偶尔会撰写技术论文。他目前在 Salesforce 工作。
版权所有 © 2019 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 17, no. 5—
在 数字图书馆 中评论这篇文章
更多相关文章
Ethan Miller, Achilles Benetopoulos, George Neville-Neil, Pankaj Mehra, Daniel Bittman - 远端内存中的指针
为了有效利用新兴的远端内存技术，需要考虑在父进程上下文之外操作富连接数据。正在开发中的操作系统技术通过公开诸如内存对象和全局不变指针之类的抽象来提供帮助，这些抽象可以被设备和新实例化的计算遍历。这些想法将允许在具有分离内存节点的未来异构分布式系统上运行的应用程序利用近内存处理来获得更高的性能，并独立扩展其内存和计算资源以降低成本。
Simson Garfinkel, Jon Stewart - 磨砺你的工具
本文介绍了我们在最初发布十年后更新高性能数字取证工具 BE (bulk_extractor) 的经验。在 2018 年至 2022 年期间，我们将该程序从 C++98 更新到 C++17。我们还进行了完整的代码重构，并采用了单元测试框架。DF 工具必须经常更新，以跟上其使用方式的变化。对 bulk_extractor 工具更新的描述可以作为可以而且应该做的事情的示例。
Pat Helland - 自主计算
自主计算是一种使用协作来连接领地及其特使的业务工作模式。这种基于纸质表格的模式已经使用了几个世纪。在这里，我们解释了领地、协作和特使。我们研究了特使如何在自主边界之外工作，并且在保持局外人身份的同时仍然很方便。我们还研究了如何跨不同领地启动工作、长时间运行并最终完成。
Archie L. Cobbs - 持久性编程
几年前，我的团队正在为一个增强型 911 (E911) 紧急呼叫中心商业 Java 开发项目工作。我们尝试使用传统的 Java over SQL 数据库模型来满足该项目的数据存储需求时，感到非常沮丧。在对项目的特定需求（和非需求）进行一番思考后，我们深吸一口气，决定从头开始创建我们自己的自定义持久层。
© 保留所有权利。