【译】如何通过 Google Spanner 实现万亿级数据存储与5个九的高可用性

用户11547645

发布于 2025-03-07 16:12:31

350

原始链接 https://blog.bytebytego.com/p/how-google-spanner-powers-trillions[1] 作者 ByteByteGo[2]

免责声明：本文中的所有细节均来源于 Google 博客和研究论文，所有技术细节的原始版权均归 Google 工程团队所有。文末附有原始文章的链接。我们对这些细节进行了分析并提供了我们的解读。如果您发现任何不准确或遗漏之处，请留言，我们会尽力修正。

Google Cloud Spanner 是 Google 开发的一款革命性数据库系统，它巧妙地将传统关系型数据库的优势与 NoSQL 系统通常具备的可扩展性相结合。

专为跨多个区域处理海量工作负载而设计，Cloud Spanner 提供了一个全球分布、强一致性且高可用的数据管理平台。其独特之处在于，它既支持 SQL 查询和关系型数据结构，同时又实现了水平扩展能力，使其能够满足现代高负载应用的需求。

Cloud Spanner 的主要特性

多版本数据库 采用同步复制技术，即使在区域故障的情况下也能保证数据的持久性与可用性。
TrueTime 技术 整合了 GPS 和原子钟，提供全球一致的时间线。
简化数据管理 提供熟悉的 SQL 接口，同时在后台处理分布式数据处理的复杂性。
数据切分与动态分片 将数据按照连续的键范围（称为 splits）进行分区，并根据负载或数据量动态调整分片以优化性能。

总体而言，Google Spanner 为需要支持全球规模操作，同时保持传统关系型系统的稳健性和可靠性的企业提供了一种极具竞争力的数据库解决方案。

在本文中，我们将深入探讨 Google Cloud Spanner 的架构，以及它如何支持构成这一出色数据库选项的各项能力。

Cloud Spanner 架构概述

Spanner 的架构旨在支持其作为一个全球分布、强一致性及高可用性数据库的角色。

在最高层次上，Spanner 被组织为一个被称为 “Universe” 的逻辑实体，该实体跨越多个物理或逻辑位置，这些位置被称为“区域（zones）”。

每个区域都具有一定的独立性，并包含专用的 spanservers。这些服务器负责数据存储和事务处理，基于 Google 早期分布式存储系统 Bigtable 的概念，并在此基础上进行了增强以支持复杂事务和多版本数据。

关键架构组件

Cloud Spanner 通过将数据划分成更小的单元来进行管理，这些单元称为 tablets，并分布在多个 spanservers 上。

Tablets每个 tablet 存储键值对数据，并附带时间戳用于版本控制。这种结构使得 Spanner 成为一个多版本数据库，能够根据需要访问数据的旧版本。
Colossus 文件系统Tablets 存储在 Colossus 上，这是 Google 的分布式文件系统。Colossus 提供了容错性和高性能存储，使得 Spanner 能够实现存储与计算资源的独立扩展。
Splits表中的数据依据连续的键值范围进行划分，这些范围称为 splits。当某个 split 变得过大或流量过高时，系统会自动将其分割成更小的部分并重新分布到不同的 spanservers，这一过程称为动态分片（dynamic sharding）。
跨区域复制每个 split 都会在多个区域间进行复制，以实现冗余和故障容错。

为了保证数据一致性，Spanner 采用了 Paxos 共识算法来管理跨区域的复制。每个 split 都有多个副本，Paxos 算法确保这些副本保持一致性。

Leader选举在这些副本中，一个副本被选为领导者，负责处理该 split 的所有写事务，确保更新以一致的顺序进行。如果领导者出现故障，Paxos 会自动选举出新的领导者，从而在无需人工干预的情况下保持系统可用性。同时，非领导者副本可以处理读操作，从而减轻领导者的负载并提高扩展性。

Spanner 实例通常跨越某一地区内的多个区域，并将副本分布在这些区域中。这样的架构提高了系统的可用性，因为即便某个区域发生故障，其他区域仍能继续处理请求。对于全球部署，还可以将数据复制到不同大陆，以便为全球用户提供低延迟访问。

所有数据均存储在 Colossus 上，该系统为分布式、复制的文件存储而设计，通过在多台物理机器间复制数据来确保高耐久性，从而在硬件故障时能够恢复数据。文件系统与计算资源分离，使得数据库可以独立扩展并高效运行。

Paxos 共识机制

Paxos 是 Spanner 架构中的核心组件之一。其基本原理是通过分布式共识，让一组副本（称为 Paxos 组）就一个值（例如某事务的提交或负责更新的领导者）达成一致。

领导者分配机制

每个数据 split（即连续键范围）都关联有一个横跨多个区域的 Paxos 组。
在 Paxos 组中，一个副本被指定为领导者，该领导者负责处理该 split 的所有写操作，从而保证更新协调一致。
其他副本作为跟随者，不仅帮助分担读操作的负载，还为系统的扩展性做出贡献。

Paxos 领导者的主要职责包括：

处理写操作领导者接收写请求，并确保这些请求在多数副本确认后才进行提交，从而确保数据的持久性和一致性，即便部分副本出现故障。
维护顺序通过 TrueTime 为事务分配时间戳，确保写操作按照全局一致的顺序执行。
与跟随者通信领导者向跟随者广播提案，并收集确认信息来协调更新。

即使在分布式系统中不可避免会出现故障，Paxos 机制也能确保 Spanner 在面对这些问题时依旧保持可用性与一致性。若当前领导者因机器或区域故障而失效，Paxos 组将检测到这一情况并选举出新的领导者，从而避免系统停机。

事务处理机制

Cloud Spanner 使用强大而稳健的事务处理方法，确保数据一致性、可靠性和高性能。下面介绍写事务和读事务的工作原理：

写事务

写事务确保了原子性（全有或全无）和一致性（所有副本数据一致），由 Paxos 领导者协调处理，即便在出现故障时也能保证数据完整性。其基本步骤如下：

加锁在修改数据之前，负责该 split 的 Paxos 领导者会对相关行加写锁。如果另一事务已持有冲突锁，则当前事务需等待锁释放。
通过 TrueTime 分配时间戳利用 TrueTime 为事务分配全局一致的时间戳，该时间戳总是大于之前任何已提交事务的时间戳，从而保证时间顺序的一致性。
多数副本复制保证持久性领导者在加锁并分配时间戳后，会将事务细节发送给 Paxos 组中超过半数的副本。只有在多数副本确认后，事务才被认为已提交，确保即便部分副本故障，数据也能得到持久保存。
提交等待领导者会等待一个短暂的时段，确保提交时间戳对所有副本均已生效，然后再最终提交事务，使得后续所有读取操作都能反映该变更。

对于单个 split 内的写操作，例如用户希望在表中添加一个 ID 为 7、值为 “Seven” 的行：

Spanner API 会确定 ID 7 所在的 split，并将请求发送至该 split 的 Paxos 领导者。
领导者对 ID 7 加锁、分配时间戳，并将变更复制给多数副本。
在确保时间戳生效后，事务提交，所有副本应用该变更。

而对于涉及多个 split 的写操作（例如修改多个 split 中的 ID 2000、3000 和 4000），Spanner 则采用两阶段提交协议：

每个参与的 split 都成为事务的参与者，其中一个 split 的领导者担当协调者角色。
协调者确保所有参与者都已加锁并同意提交事务，然后再进行下一步操作。
在所有参与者确认后，协调者提交事务，并通知其他参与者应用变更。

读事务

读事务经过优化，可在高负载下提供高性能的强一致性读取，同时无需加锁。

强一致性读取这类读取始终返回最新的已提交数据。系统通过 TrueTime 检查数据最新的时间戳，确保返回的数据是最新状态。例如，当客户端请求读取 ID 为 1000 的行时，系统会路由该请求至某个副本，并在返回结果前与领导者确认数据的最新性。
陈旧读取允许在一定程度上返回稍微过时的数据（例如最多延迟 10 秒），以换取更低的延迟。客户端在请求时，可以直接从副本读取数据，而无需等待领导者确认，从而加速响应。

下面的图示展示了强一致性读取的场景：

而下图则展示了陈旧读取的场景：

为了避免死锁——即多个事务相互等待释放锁的情况——Spanner 采用了 wound-wait 算法。其基本规则如下：

如果一个较晚启动的（年轻的）事务请求被较早启动（较老）的事务所持有的锁，则该年轻事务等待。
如果较老事务请求较年轻事务所持有的锁，则较年轻事务会被 “wound” （即中止），以便较老事务继续执行。
这种策略确保事务始终能够推进，避免形成死锁循环。

Spanner 的设计确保了数据即使在故障情况下也能保持一致性和可用性。所有写操作的数据均存储于 Google 的 Colossus 分布式文件系统中，该系统通过将数据复制到多台物理机器上，即使部分机器或区域出现故障，也能从其他副本中恢复数据。TrueTime 则确保了在分布式环境中事务的全局一致排序，保证一旦某事务对一个客户端可见，则对所有客户端均可见。

TrueTime 技术

TrueTime 是 Cloud Spanner 的一项关键创新，使其能够作为一个全球分布、强一致性的数据库运行。TrueTime 解决了分布式系统中最具挑战性的问题之一：如何在分布于多个区域和数据中心的节点间提供全球同步和一致的时间视图。

TrueTime 基于原子钟和 GPS 时钟的组合工作，二者协同提供高度准确和可靠的时间同步：

原子钟基于原子振动频率计时，提供极高精度、漂移极小的时间测量。在 GPS 信号中断或不准确时，原子钟能保证时间的准确性。
GPS 时钟依靠卫星信号提供准确的全球同步时间。但 GPS 系统可能会遇到干扰、天线故障，甚至伪造攻击的问题。

TrueTime 不将时间表示为单一的点，而是表示为一个时间区间，明确体现了分布式系统中固有的不确定性：

TTIntervalTrueTime 提供一个时间范围 [earliest, latest]，保证实际的全球时间落在此区间内。区间宽度由时钟漂移和网络延迟等因素决定。
误差范围与同步通过大约每 30 秒与时间主机（原子钟和 GPS 时钟）同步一次，系统可将不确定性区间保持在一个较小的范围内（通常在 10 毫秒以内）。

TrueTime 具有以下重要特性，使其在分布式数据库中发挥关键作用：

全局外部一致性确保所有副本中事务以相同的全局顺序进行序列化。例如，如果某事务提交早于另一事务开始，TrueTime 能保证时间戳反映这种全局顺序。
无锁读取事务允许 Spanner 执行无锁的只读请求，这些事务可以在不加锁的情况下访问数据的一致快照，从而提升系统扩展性和性能。
原子模式更新在分布式系统中，模式更改（如修改表结构）通常十分复杂。TrueTime 将模式更新视为具有特定时间戳的事务，确保所有服务器一致地应用更改。
历史数据读取TrueTime 允许基于指定时间戳读取数据的一致快照，方便进行审计或调试。

总结

Google Spanner 在数据库工程领域是一项重大突破，它完美地将传统关系型数据库的可靠性和结构性与 NoSQL 系统的可扩展性和全球可用性相结合。通过创新的架构设计，依靠 Paxos 共识机制以及 TrueTime 技术，Spanner 能够高效地处理分布式事务、保证外部一致性，并在全球范围内保持高性能运行。

Google Spanner 正在重新定义分布式数据库系统的可能性，为可扩展性、可靠性和创新设定了新的标准。