我可能没有以前那么确定

在云环境中，拥抱随机性是必要的。

Pat Helland

年轻时，我认为宇宙像一个大钟一样，由因果关系支配。从这个角度来看，计算是有道理的。现在我意识到，生活和计算都可能是一场碰运气，这给了我一种新的平静。

我一直都很坚定

在高中时，我学习了经典的牛顿物理学。我每天都很庆幸自己在青少年时期获得驾驶执照之前学习了物理学。当我环顾世界，阅读历史，观察事物时，一切似乎都有原因。从哲学上讲，我是一个决定论的信徒。

当我 20 世纪 70 年代初开始编程时，我软件中的错误导致我对决定论的信念暂时动摇，因为我对着电脑破口大骂。当我发现根本的错误是由我的失误造成的时，这种动摇就消散了。复杂系统中的一切都有原因，并且有可能构建其正确或错误行为的因果关系。

系统中事物的名称和标识始终来自某种总体分类法。多年来，这都在集中的单服务器中。随着时间的推移，我开始研究少量协作服务器。这导致了企业内部的目录服务，并最终导致了基于 DNS（域名系统）的互联网范围内的名称。一切都存在于大时钟的各自位置。我可以根据全局预定的层次结构来推断每个名称的来源。

当我开始研究分布式系统时，有界本地网络受到了严格控制。专用硬件确保消息似乎是同步传递的。虽然它们并非总是按时交付，但我们假装它们是按时交付的，并基于超时和重启构建解决方案。伪同步消息传递在这种有限的上下文中表现良好。

世界可以映射到可预测的行为、原因、结果和组合关系中。我真的是一个数据库人员，尽管我对分布式系统很感兴趣。我对宇宙感到平静。

存在主义的中年危机

我于 1994 年开始在微软工作，以帮助公司从桌面 PC 转向运营企业。我在 20 世纪 80 年代在 Tandem Computers 的经验使我对为企业客户提供完全正确的事务性答案产生了浓厚的兴趣。这需要超高的可用性，即使在出现故障时也是如此。微软积极进取，我也一样。

到 1996 年我 40 岁时，我已步入中年，我的身材也变得臃肿。我对世界的看法是牛顿式的，即一切都以封闭宇宙内的行动和反应为模型。这种抽象的“完全正确的事务性答案”建立在基于客户公司内部的某种中心化权威的身份概念之上。名称和标识是分层的，并且是客户本地的。与外部人士及其世界的对话是一个“应用程序问题”，而不是我们系统的一部分。

相比之下，微软生活在一个软件由许多独立来源创建并在生态系统中汇聚的世界中。起初，这需要疯狂地共享软盘。到 20 世纪 90 年代，这意味着在新兴的互联网上喷射比特。

正是在那时，我被介绍了 UUID（通用唯一标识符）。在微软，这些被称为 GUID（全局唯一标识符）。UUID 是独立分配的，没有分层命名空间，并且假定是唯一的。我第一次接触 UUID 涉及识别在独立公司编码的软件接口，但在世界任何地方安装时仍保持唯一性。

这些怎么可能既唯一又独立分配？我立即发自内心地拒绝了这种胡说八道，然后头昏脑胀地回家了。

版本 4 UUID 是 128 位标识符，其中 122 位分配用于保存唯一值；2 的 122^次方确实是一个很大的数字^TM！虽然我不认为自己是数学专家，但我在微软的同事让我相信，UUID 冲突的概率是生日问题的一个例子，其中有 2^122 个可能的生日。122 个随机位发生冲突的概率受池中唯一标识符数量的驱动。根据通用唯一标识符维基百科中的数学计算，如果您使用 1.6 PB 来存储 103 万亿个 16 字节的 UUID 在一个地方，您将有十亿分之一的机会发生重复。

只有当您假设 UUID 是随机的时，它才是一个很大的数字^TM。为了理解本文的随机性，我阅读了一份名为“英特尔随机数生成器”的白皮书。其中大部分内容都很有道理，尽管我大学数学不及格，因为编程更有趣。它解释了熵的概念或随机位的随机性。引用这篇白皮书

在生成 k 位二进制结果的随机数生成器的情况下，P_i 是输出等于 i 的概率，其中 0 ≤ i < 2^k

因此，对于完美的随机数生成器，P_i = 2^-k 并且输出的熵等于 k 位。这意味着所有可能的结果都同样（不）可能，并且平均而言，输出中存在的信息无法以短于 k 位的序列表示。

该论文探讨了基于非确定性源（例如多个热敏振荡器）构建的 TRNG（真随机数生成器）以及 PRNG（伪随机数生成器）的使用。英特尔在硬件中将这些公开为 RDRAND 和 RDSEED 指令。通常的做法是从两个或多个随机位或字节源中获取，并将它们 XOR 在一起以增加结果的熵。例如，考虑从两个不同的源获取两个 128 位输入。通过 XOR 这两个输入（总共 256 位），您可以生成一个 128 位输出，具有更好的熵。必须注意避免破坏这些已建立的技术。

虽然这里描述的是英特尔的解决方案，但我相信所有其他主要芯片供应商都提供了类似的结果。我对随机性的浅薄调查让我相信，就我而言，UUID 是唯一的。

正如我之前所说，我认为自己是积极进取的。我可以容忍这种微小的风险。在情感上，概率成为我生活的一部分。我的中年存在危机让我走向更像禅宗一样地接受事物有时不完美。因果报应、教条和决定论只是生活的一部分。

在这里，看起来牛顿是对的

到 21 世纪初，我已经花了大约 25 年的时间与构建数据库的人们在一起。他们是我的伙伴！尽管如此，我还是忍不住觉得他们是通过牛顿棱镜看世界的。我突然想到，数据库之外存在数据，并且它具有与数据库数据不同的属性。主要原因之一是时间（外部数据感知到的时间）与数据库内部的事务性现在断开了连接。这促成了我 2005 年 CIDR（创新数据系统研究会议）论文，“外部数据与内部数据”。

正如我在“SQL 的奇异成功”中所写的那样，我真的放弃了将 SQL 作为宇宙的唯一模型。就像牛顿物理学一样，它在小范围内非常实用。SQL 依赖于事务来暂停时间以确保正确性。它只在当下起作用。现在，如果它存在，则是一个局部参考系。

就我个人而言，我可以毫无困难地生活在支持事务正确性所需的参考系中，并且理解存在一个更大的分布式系统世界。就像光粒子一样，数据库存在于它们自己的世界中，无视跨越其边界的交互。就像波浪一样，数据库的世界有时会与外部世界相互作用，产生令人惊讶的结果。

教派的乐趣

词典将教派定义为一群在宗教信仰上与他们所属的较大群体略有不同的人。这听起来很像计算机科学家和工程师。让我们讨论一下这三个教派群体

• 网络人士。 大多数这些人的人格结合了嬉皮士和摩托车手的最佳方面。当你和他们交谈时，他们既想像暴风雨一样冲进城镇，又想存在主义地谈论生活的随机性。我从未见过哪个网络工程师认为任何事情是确定的。一切都以一定的概率和累积分布函数在其延迟上发生。然而，他们非常快乐，随时准备投入下一场争吵，并不断表现出对生活的热情。

• 分布式系统人士。 这些人在哲学家和律师之间摇摆不定。没有人能如此流利地谈论全序，而不讨论总体范围。可用性总是通过假设最多丢失 F 台服务器来限定，而从不深入探讨当操作员登录系统时会发生什么。他们内心深处相信在非确定性环境中存在确定性结果。有时这些讨论会变得非常 F' 混乱！

• 数据库系统人士。 这个社区是我的原生家庭。他们是我的家人！这些专业人士展现了银行家、建筑师和建造者的最佳品质。一切都必须是业务关键型、可证明正确且为可靠性而过度设计的组合。数据库人员假设一个预先存在的确定性世界，并在该确定性基础上构建最酷的复杂系统。当他们的假设成立时，这非常有效。与他们携手并肩，我将兴高采烈地设计一个预计可以使用 100 年的厕所，尽管卫生条件很差。

没有什么比在这些群体之间滑动并扰乱他们的大脑更有趣的了。

禅与系统设计艺术

在罗伯特·皮尔西格著名的哲学著作禅与摩托车维修艺术中，朋友们骑摩托车从明尼苏达州到加利福尼亚州进行了为期 17 天的旅程。在旅程中，出现了一些关于如何维护摩托车的不同哲学。这与生活的“浪漫”方式形成对比，其中约翰选择避免维护他昂贵的新自行车，而叙述者则采用“经典”方式，即应用有条不紊的细心和勤奋来维护每个部件。

结果表明，约翰只想享受整体，活在当下。叙述者试图理解每一个细节，并对所有事物施加理性分析。

同样，对计算机系统的一种观点侧重于每个组件行为的因果关系，并试图以精密的瑞士手表般的精度来控制和管理总体系统。另一种观点认识到，在高速公路上通勤回家通常很快，但并非总是如此。

爬进快速移动的铝管

我第一次乘坐飞机是在高中四年级。虽然我对飞机如何在空中停留有大致的了解，但信任这根铝管真的似乎违反直觉。不过，我完全消除了恐惧，因为我已经阅读了关于乘坐商用飞机时出现问题的极低几率的文章。显然，在高速公路上比在空中更危险。

今天，一切都越来越互联。与此同时，我们正在将我们的东西扔到大规模共享的云部署中。这两种趋势都破坏了可预测和确定性行为所需的封闭系统。计算已成为一个非确定性的狂野西部。这让我放松下来，对概率变得禅意十足。我再也不能仅仅根据因果依赖关系来完全解释我们的系统了。

在这个云雾缭绕的狂野西部中，我与那些抱怨 UUID 冲突并希望在唯一标识符中找到完美信心的人们并肩工作。这种情况发生在他们轻率地忽略系统对密码学以确保安全性的深度依赖及其对随机密钥分配概率的基础依赖时。他们继续期望服务器能够干净快速地发生故障，即使正如我曾经写过的那样，“快速失败正在快速失败！” 我知道他们也乘坐飞机。

现在我可以充满信心地乘坐飞机，对航空电子设备感到好奇，讨论云中响应的概率性 SLA（服务级别协议），并完全舒适地定义完全正确的数据库恢复算法。也许这是因为我喜欢嬉皮士、摩托车手、哲学家、银行家、建筑师和建造者。我特别喜欢当他们同时在一个房间里时挑起辩论。

Pat Helland 自 1978 年以来一直从事事务系统、数据库、应用程序平台、分布式系统、容错系统和消息传递系统的实施工作。为了消遣，他偶尔会撰写技术论文。他在 Salesforce 工作。他的博客位于 pathelland.substack.com，他的 Twitter 账号是 @pathelland。

最初发表于 Queue 第 20 卷，第 3 期—
在数字图书馆中评论本文

更多相关文章

Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
跨异构存储技术对分布式事务的支持要么不存在，要么在操作和性能特性方面表现不佳。相比之下，OLEP 越来越多地用于在这些设置中提供良好的性能和强大的一致性保证。在数据系统中，日志通常用作内部实现细节。OLEP 方法有所不同：它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。传统数据库仍然使用，但它们的写入来自日志而不是直接来自应用程序。OLEP 的使用不仅仅是开发人员的实用主义，而是它提供了许多优势。

Andrew Leung, Andrew Spyker, Tim Bozarth - Titus：将容器引入 Netflix 云
我们相信，我们的方法使 Netflix 能够快速采用容器并从中受益。虽然细节可能特定于 Netflix，但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法，对于任何希望采用容器的组织来说，都可能是一种成功的策略。

Marius Eriksen - 大规模函数式
现代服务器软件在开发和运营方面要求很高：它必须始终在所有位置可用；它必须在几毫秒内响应用户请求；它必须快速响应容量需求；它必须处理大量数据甚至更多流量；它必须快速适应不断变化的产品需求；并且在许多情况下，它必须容纳一个庞大的工程组织，其众多工程师就像一个又大又乱的厨房里的谚语厨师。

Caitie McCaffrey - 分布式系统的验证
Leslie Lamport 因其在分布式系统方面的开创性工作而闻名，他曾说过：“分布式系统是指即使您不知道存在的计算机发生故障也可能导致您自己的计算机无法使用的系统。” 鉴于这种黯淡的前景和大量可能的故障，您甚至如何开始验证和确认您构建的分布式系统正在做正确的事情？