以微软 Azure Cosmos DB 为例，解析如何研发云生全球性分布式数据库

Cosmos DB 为要求特别高的企业提供了一个全球性、高可用、低延迟的集数据库 / 存储 / 查询 / 分析于一体的服务。它使用了一种新的嵌套分布式复制协议、健壮的可伸缩性技术和精心设计的资源治理抽象。它管理着 100PB 的索引数据，每天为全球成千上万的客户提供数以万亿计的请求服务，并使客户能够构建具有高度响应能力的关键任务应用程序。作者是纽约州立大学布法罗分校计算机科学与工程系的正教授，研究兴趣是分布式系统，涉及云计算，分布式算法，分布式共识等。

正文

从我开始在微软 Azure Cosmos DB 团队 休假 到现在已经有 9 个月了。

我知道那时我报名参加的是什么，我知道那是无法抗拒的。

很难不被吸引。Cosmos DB 为要求特别高的企业提供了一个全球性、高可用、低延迟的集数据库 / 存储 / 查询 / 分析于一体的服务。Cosmos DB 在 Microsoft 的系统 / 服务中无处不在，也是 Azure 开发人员在外部使用的增长最快的服务之一。它管理着 100PB 的索引数据，每天为全球成千上万的客户提供数以万亿计的请求服务，并使客户能够构建具有高度响应能力的关键任务应用程序。

但我低估了需要学习的东西，以及要花多长时间才能有一个良好的整体认识。我所说的“有一个良好的整体认识”，是指我自己学习 / 吸收这个领域的知识，并且，当观察这个领域时，也能够认识到其中每一处极其痛苦又耗时费力的细节。

任何时候，Cosmos DB 都有许多很大的团队在从事不同部分 / 方面的工作。我仍然对在这么多不同的方面同时进行活动感到惊讶。测试、安全、核心开发、资源治理、多租户、查询和索引、扩展存储、扩展计算、Azure 集成、无服务器函数、遥测、客户支持、DevOps 等。最初，我只关心核心开发方面及其并发控制协议。但随着时间的推移，慢慢地，我开始学习、理解并体会到其他方面的挑战。

在 9 个月后还这么说可能听起来很奇怪，但我仍然是个新手。也许是我学得慢，但当你加入一个非常大的项目时，你从一些小事情开始做起是很正常的，同时，通过观察，你会逐渐形成一个整体的认识。这可能需要几个月的时间，微软的大型团队已经意识到了这一点，他们会给你学习进步的空间。

这很像学开车。从停车场开始，在不那么拥挤的郊区，然后随着你越来越熟练，你进入高速公路网络，对这个领域有一个更全面的认识。探索是件好事，但你只有在发展了自己的技能之后才能去做。即使有人向你展示地图并告诉你这些存在，你也没有完全意识到并体会它们。它们对你来说只是概念，你对它们有一个非常肤浅的认识， 直到你开始自己探索它们 。

因此，如果你是一名工程师，正在处理一件小事情，比如数据中心自动故障转移组件，这是某个领域的一部分，那么事情似乎进展得很慢。正确使用这个组件可能需要几个月的时间。不过没关系。你正在郊区建一条新街，这会成为一个大图景的组成部分。 大图景一直在以稳定的速度发展 ，颜色变得更加鲜艳，即使你个人也觉得自己在慢慢进步。

“1000 个细节形成一个印象。”——Cary Grant

“这意味着很少（如果有的话）有细节单个来说是不可或缺的，但这些细节总体上是绝对必要的。” ——McPhee

当我在 8 月开始这项工作时，我就觉得需要解一下词：“云原生”。

“云原生”这个词是一个意味深长的重要术语，团队不会轻易使用它。我在这里将尝试展开一些，并将在以后的文章中重新讨论。

同样，我低估了我需要多长时间才能更好地理解这一点。在了解了许多方面的进展后，我能够更好地理解这是多么重要、多么具有挑战性。

因此，在本文的剩余部分中，我将试着概要地介绍我对云原生分布式数据库服务的了解。每一段都可以写一篇单独的博客文章，我希望将来可以对每一段进行扩展。

云生分布式数据库是个什么样子？

为了实现经济有效、可靠有保证、通用及可定制 / 灵活的操作，全球性分布式云数据库在不同维度上都面临着许多挑战和相互冲突的目标。但重要的是，要在尽可能多的维度上取得尽可能高的成绩。

虽然有几个数据库在其中一两个方面达到了目标，但要在所有这些方面都达到目标是非常具有挑战性的。例如，当数据库需要在伸缩曲线上的任意一点都提供有保证的性能时，伸缩的挑战就变得更加难以克服。当数据库在任何时候都需要满足严格的性能 SLA 时，提供几乎无限的存储就变得更具挑战性。最后，在提供租户隔离和管理资源以防止任何租户影响其他租户的性能的同时实现这些目标，就变得格外具有挑战性，但这是提供成本高效的云数据库所必需的。

我们事先就想到要为所有这些维度添加支持并实现实质性的改善。Cosmos DB 在所有这些维度上都取得了很高的成绩，因为它是从头开始设计的，是为了应对所有这些挑战。Cosmos DB 通过以下特性提供了一个完美的云原生分布式数据库服务：

• 通过透明的多主复制实现全球性分布（保证一致性和延迟）；
• 通过水平分区在全球范围内实现吞吐量和存储的弹性可伸缩性（使用有保证的 SLA）；
• 通过贯穿从数据库引擎到复制协议的高水平资源管理系统栈实现细粒度多租户。

为了实现这些，Cosmos DB 使用了一种新的嵌套分布式复制协议、健壮的可伸缩性技术和精心设计的资源治理抽象，下面我将逐项介绍。

可扩展性、全球性分布、资源治理

为了实现高可伸缩性和可用性，Cosmos DB 使用一种新的协议来跨节点和数据中心复制数据，使其延迟开销最小，吞吐量最大。对于可伸缩性，数据会根据存储和吞吐量触发器自动分片，并将分片分配到不同的分区。每个分区由每个区域中的多个节点副本集提供服务，其中一个节点充当主副本，处理副本集中的所有写操作和复制。数据读取是客户端针对特定数量的辅助副本进行的。（软状态扩展存储和计算实现为存储量大和计算量大的工作负载提供了独立扩展。）

由于副本集维护数据的多个副本，因此，即使在强一致性模式下，它也可以在不牺牲可用性的情况下屏蔽某个区域中的一些副本故障。（两个副本同时发生故障的情况可能比较少见，更常见的情况是观测到一个副本故障，而另一个副本由于滚动升级而不可用，屏蔽两个副本故障可以帮助云数据库平稳、不间断地运行。）每个区域包含一个独立的配置管理器，用于维护系统配置并为分区执行群首选举。根据成员关系的更改，复制协议还重新配置了读写 quorums 的大小。

除了复制集里的本地复制之外，还有地理复制，它实现了 跨任意数量的 Azure 区域的分布——超过 50 个区域 。地理复制是通过跨不同区域副本集的嵌套一致性分布式协议实现的。Cosmos DB 提供了多主机 Active-Active 复制，允许从任何区域进行读写。对于大多数一致性模型，当写操作在某个区域发生时，它在该区域立即可用，与此同时，它会被发送到仲裁程序（ARB）进行 排序 和冲突解决。ARB 是一个虚拟进程，可以存在于任何区域中。它使用分发协议将数据复制到每个区域的主副本，后者会在各自的区域内复制数据。Cosmos DB 分发和复制协议在设计层面使用 TLA+ 模型检查器进行了验证，并使用 Jepsen 测试（一个 MS Windows 端口）对实现进行了进一步的一致性问题测试。

Cosmos DB 从一开始就是使用资源治理机制进行设计的，这是为了提供隔离的预配置吞吐量体验（由 SLA 支持），同时实现高密度打包（其中 100 个租户共享同一台机器，1000 个租户共享同一集群）。为此，Cosmos DB 为吞吐量定义了一种抽象的基于速率的本位币，称为请求单元（Request Unit）或 RU，它提供了一个规范化的模型来计算一个请求所消耗的资源，并以一种与硬件无关的、一致的方式向客户收取跨各种数据库操作的吞吐量费用。每个 RU 包含一小部分 CPU、内存和存储 IOPS。Cosmos DB 中的租户通过指定给定容器的最大吞吐量 RU 来控制所需的容器性能。从资源治理的角度来看，Cosmos DB 是一个大规模的分布式队列系统，由级联的组件组成，每个组件都经过精心校准，在分配的系统资源预算内提供可预测的吞吐量，并遵循 Little 定律和通用可伸缩性定律。资源治理的实现利用了后端分区级容量管理和跨机器负载平衡。

Cosmos DB 的贡献

以上述云原生数据存储为基础，Cosmos DB 提供了一个几乎“全能”的数据库。Cosmos DB 提供了低延迟、高吞吐量的数据本地访问，提供了数据中心内部和跨数据中心的可配置的一致性保证，并提供了多种数据模型及利用了强大索引和查询支持的 API。由于 Cosmos DB 支持一系列的一致性保证，并且可以与不同的后端协同，因此，它解决了公司在多个团队使用不同数据库来满足不同用例时所面临的集成问题。

绝大多数其他数据存储要么提供最终一致性，要么提供强一致性，要么两者都提供。相比之下，Cosmos DB 提供了一系列的一致性保证，可以满足所有企业应用程序、Web 应用程序和移动应用程序的一致性和可用性需求。 Cosmos DB 使应用程序能够决定什么是最适合它们的，并做出不同的一致性可用性权衡 。最终一致存储允许在一段时间内存在处于差异状态，以换取更高的可用性和更低的延迟，这可能适合于一致性要求较为宽松的应用程序，比如推荐系统或搜索引擎。另一方面，购物车应用程序可能需要一个“读取你自己的写入（read your own write）”属性来进行正确的操作。在 Cosmos DB 中，这是由会话一致性保证的。将其扩展到许多客户端需要提供语义“读取最新的写入”，并且需要很强的一致性。这确保了同一应用程序的多个客户端之间的协调，并使应用程序开发人员的工作变得简单。无论是在单个区域内，还是在所有相关区域内，都保持了强一致性。有限时效（bounded staleness）一致性模型保证任何读请求都返回最近的 k 个版本或 t 时间内的一个值。它提供了全局整体顺序，除了在时效窗口内，因此它是一个略弱于强一致性的保证。

Cosmos DB 成为全能数据库的另一种方式是提供多种 API 并服务于不同的数据模型。Web 和移动应用程序的数据模型需要一系列的选择 / 替代方案：有些应用程序使用更简单的模型，如键值或列簇，而另一些应用程序需要更专门的数据模型，如文档和图存储。Cosmos DB 通过将内部文档存储映射到不同的表示形式来支持 API 和数据模型，其依据是所选择的模型。客户端可以在文档、 SQL 、Azure 表、Cassandra 和 Gremlin 图形 API 之间做出选择，从而与它们的数据存储进行交互。这不仅为我们的客户提供了极大的灵活性，而且还让他们可以轻松地将应用程序迁移到 Cosmos DB。

最后，Cosmos DB 提供了业界最严格的 SLA。与其他许多只提供可用性 SLA 的数据库不同，Cosmos DB 还提供一致性 SLA、延迟 SLA 和吞吐量 SLA。典型地，对于一个 1KB 的对象，Cosmos DB 保证第 99 百分位的读写操作花费不到 10ms 的时间。 吞吐量 SLA 保证客户端接收到的吞吐量与通过 RU 提供给帐户的资源相等。

查看英文原文： https://muratbuffalo.blogspot.com/2019/04/azure-cosmos-db-microsofts-cloud-born.html