前言

大数据时代 ，随着移动互联网和物联网技术的发展 ， 全球数据量呈现爆发式增长，已经远远超出集中式单机数据库的处理能力。CCF 数据库专委 2021 年发布的《“十四五”数据库发展趋势与挑战》显示， 各行各业海量数据的管理需求给数据库产业的发展带来了诸多挑战 ：

• • 海量数据存储
  传统集中式数据库容量大多在百 GB 至 TB 级别，伴随着各行各业数据爆发式增长，数据库所需存储的数据容量也在急剧增长且数量呈现指数级增长，从 TB 级别增加到 PB 级别，未来很快就会增加至 EB 级别；

•  

• • 海量并发访问
  数据库的业务访问量也发生了量到质的变化，传统的业务模式业务访问仅局限于企业内部 ， 通常数百至数千并发即可满足。而在互联网及物联网模式下，数据库的访问服务于海量的联网终端用户，需要万级至百万级的并发支持能力；

•  

• • 基础设施的分布式
  为了提升数据库的高可用，各行业在加速信息化基础设施的建设，从传统的两地三中心向分布式多地多中心变化，要求数据库从传统的可用区（AZ）内部署向跨 AZ、跨地域（region）的分布式部署架构演进。

基于上述背景，传统集中式数据库架构已无法有效满足新型互联网业务模式下的业务需求，而解决这些问题本质是要解决数据库扩展性问题，分布式数据库架构应运而生。根据时间线，现有解决方案大致可分为 3 个阶段 ：

• • Step 1：将现有成熟关系型数据库（如 Oracle、SQL Server、MySQL 和 PostgreSQL 等）在分布式集群或者云平台上进行小规模扩展和部署；

•  

• • Step 2：放弃关系模型和已有的 ACID 事务特性，转向选择具备灵活的 schema-free 数据模型、高可用性和最终一致性特性的 NoSQL 数据库；

•  

• • Step 3：融合关系型数据库和 NoSQL 二者优势的新型 NewSQL 数据库。

在这篇技术博客中，我们将深入探讨 Google 于 2012 年在系统领域顶级国际会议 USENIX Conference on Operating Systems Design and Implementation（简称 OSDI）上发表的论文《Spanner：Google's Globally Distributed Database》中所提出的经典分布式数据库 Spanner 架构及其核心技术。通过这些内容 ， 你将了解到 Spanner 如何在当时突破了技术瓶颈 ，为后续的分布式数据库技术发展奠定了基础。

Spanner 架构

Spanner 是谷歌提出的一种可扩展、支持多版本、全球分布和同步复制的数据库系统。作为全球第一个在大规模数据中心中实现强一致性和同步复制的数据库系统，Spanner 彻底颠覆了传统数据库的设计理念。该论文主要描述了 Spanner 的架构、关键特性、相关设计的基本考量。接下来，我们将对 Spanner 基础架构、TrueTime 机制、事务并发控制等关键特性进行详细介绍。

上图为 Spanner 整体架构，其中：

• • Universe：一个 Spanner 部署被称为一个 universe。一个 Universe 下面包含多个 Zones，Zone 是 Spanner 管理、物理隔离和数据复制的基本单位。Universe 通过 universe master 组件来显示其所管理的所有 zone 的运行状态，通过 placement driver 来处理跨 Zone 的数据移动以保持数据均衡。

•  

• • Zone：一个数据中心可以对应一个或多个 Zone，Zone 也可以随着数据中心的搭建和拆除而动态添加和删除。每个 Zone 包含一个 zone master、一个 location proxy 和多个 span server。其中，zone master 负责将数据分配到 Spanner server，location proxy 作为代理中间件负责帮助客户端定位数据所在的 span server，而诸多的 span server 则用于存储数据。

Spanner Server 软件栈

通过上述架构组件作用描述可以看出，span server 是 Spanner 的核心组件，其软件栈实现如图所示。

每个 span server 负责管理 100 到 1000 个 tablet。其中 ， tablet 是存储数据的基本单元，类似于 BigTable 中 tablet 的组织方式 ， 实现了以下键值映射：(key：string, timestamp：int64) -> string。然而不同于 BigTable，Spanner 为每个数据额外分配了一个时间戳 ， 使其成为一个多版本数据库而不是简单的键值存储。tablet 的状态存储在一组类似 B-tree 的文件和一个预写日志中，这些文件和日志都存储在 Google 的分布式文件系统 Colossus 上。

为了支持数据复制且保证数据多副本的一致性， span server 在每个 tablet 上运行有一个 paxos 状态机。每个状态机将其元数据和日志都存储在对应的 tablet 上。为了提升 Spanner 系统性能和可用性，其对 paxos 共识机制进行了多项优化 ：

• • 通过对 paxos 进行优化，Spanner 支持为期 10s 的长租约 leader 机制 ， 从而减少了频繁选举的开销。

•  

• • 为了确保数据的一致性和可恢复性 ， Spanner 将每个 paxos 写操作记录两次，一次记录在 tablet 的日志，一次记录在 paxos 本身的日志中。

•  

• • 实现流水线式 paxos，进一步提高了系统在高并发情况下的吞吐量。

在 Leader 副本上，每个 Spanner server 都会维护一个锁表和一个事务管理器，其中 ：

• • 锁表用于实现并发控制，包含了所有数据记录对应的两阶段锁状态。

•  

• • 事务管理器用于支持分布式事务。如果一个事务只涉及一个 paxos 组， 这种情况下事务就会绕过管理器，直接基于锁表和 paxos 共识协议就可以保证事务一致性。如果一个事务涉及多个 paxos 组，这些组中的 leader 会协调执行两阶段提交。具体的，这些组中的一个组会被选定为协调者，该组中的 leader 作为协调领导者角色，该组中的 slave 副本则作为协调追随者角色。基于两阶段提交协议，在准备阶段，协调者向所有参与者发送准备请求；在提交阶段，协调者向所有参与者发送提交请求。值得一提的是，每个事务管理器状态也都存储在底层的 paxos 组中以保证状态一致性。

目录 directories

在前文中曾提到，Spanner 支持跨 Zone 的数据移动以保持数据均衡。为实现对该功能的支持， Spanner 在底层 key-value 数据映射基础上，封装实现了一层桶抽象，并将其命名为 directory。作为数据放置的最小单元，它包含共享公共前缀的一个连续 Key 记录集合。

同一个 directory 的数据拥有相同的副本配置项， 因此当数据在 paxos 组中移动时，directory 也是最小的移动单元 ， 其过程示意如图所示。

这种基于 directory 的数据移动具有如下好处：

• • directory 通过控制数据在不同数据中心的分布，可以优化数据访问的延迟。通过将 directory 分配到靠近用户的位置，可以显著降低读取延迟，提高用户访问速度；

•  

• • 可以将总是同时访问的 directory 放入同一个 paxos 组内，减轻负载。

实际上，我们可以将 directory 理解为 partition 的一种逻辑上的表达。

数据模型

Spanner 支持应用程序在 universe 中创建一个或多个数据库，每个数据库可以包含无限量的模式化表。一个 Spanner 的建表语句实例如图所示，可以看出 Spanner 与关系型数据库类似 ， 每张表包含行、列和版本值。每张表要求必须有一个或多个主键（primary key）列 ， 定义了主键列到非主键列的映射 ， 这使得 Spanner 看起来也非常像是一个 key-value 存储。

但是与关系数据库不同 ：
1）Spanner 表中的行都有对应的名称 ， 该名称是由该行对应的主键构建形成的。这种数据模型使得应用程序能够通过 key 的选择来控制获知数据的位置。

2）Spanner 表间不存在外键关系 ， 而是设计了一种层级关系 hierarchy。以图 4 示例为例 ， Users 表被称为 directory 表或父表 ， 用 DIRECTORY 关键字表示 ， 子表 Albums 与 directory 表交织（interleave），交织的表数据被保存在一起。

TrueTime 机制

通过前面的介绍，我们可以看出，Spanner 的设计离不开时间戳，但如何能够提供精确且一致的时间戳，是 Spanner 的关键问题之一。分布式环境下各个机器时钟的误差导致我们无法通过简单地调用系统时间函数来生成唯一的时间戳，从而无法保证事务的外部一致性，而中心化的全局授时服务方案又面临系统的高可用问题。

为了解决上述问题，Spanner 选择采用了一种纯粹的分布式方案，称之为 TrueTime 机制。该机制保证了 Spanner 在序列化隔离级别的基础上，能够提供更严格的一致性，即外部一致性：即如果事务 T1 在事务 T2 之前提交，那么事务 T1 的时间戳一定小于事务 T2 的时间戳。

为了实现上述外部一致性，TrueTime 实现的关键特性之一是显式地暴露时钟的不确定性。它不仅提供当前时间，还提供一个时间范围，即最早可能的时间和最晚可能的时间。TrueTime 一共包含以下三种方法：

在 TrueTime 中，时间被定义为 TTinterval，代表一个时间区间。TT.now() 方法用于获取当前时间，返回一个时间范围 [earliest, latest]，该区间包含了当前的真实时间。TT.after(t) 和 TT.before(t) 是 TT.now 的包装函数，判断时间 t 是否已经绝对过去或者绝对没有到来：

• • TT.after(t) == true 表示 now().latest < t

• • TT.before(t) == true 表示 t < now().earliest

在实际应用中，调用 TT.now 得到时间范围后，可以使用这个范围的任意时间作为当前时间。显然，无论如何选择这个时间，都有可能与当前时间不一致。即使所有事务都采用 latest 作为时间戳，也不能保证时间戳的先后顺序与调用 TT.now 时的时间顺序符合。因此，为了达成外部一致性，这里存在一个必须要处理的误差。Spanner 采用一种叫做 commit wait 的方式来处理这种误差。

当事务启动后，Spanner 会为该事务选择一个时间戳，要求它一定大于事务实际开始的时间，小于事务实际结束的时间，即

为了满足该条件，设计以下两个原则：

• • 事务时间戳一定要大于 TT.now().latest

• • 直到 TT.after(s) == true，才提交事务

基于上述原则，commit wait 的判定流程如下。假设一个事务在 t_start 开始启动，事务启动后，调用 now() 方法，因此 t_start 一定小于 now() 的实际调用时间，并且 now() 的实际调用时间一定小于 now().latest。Spanner 选择一个时间戳 s，该时间戳大于 now().latest，因此：

在选择 s 后，调用 TT.after(s)，返回 true 后提交事务。TT.after(s) == true 因为 s < now().latest（备注：TT.after(s) 是 now() 的包装函数），而 now() 的实际调用时间一定大于 now.eariest，小于 t_end，从而得到：

进一步又得出：

通过上述流程，我们选择一个未来的时间戳，该时间一定大于事务的开始时间，并通过等待足够长的时间，使这个未来的时间戳成为过去时间，从而小于事务的提交时间。

在实际实现中，Spanner 综合利用了硬件原子钟和 GPS，保证了不同机器之间的时间差不超过 ε，进而从某种程度上把各个节点的时钟拉到了同一个时钟参考系，让不同节点发生的时间可以进行先后的比较。进一步结合上述原理落地实现了其 TrueTime 机制。

事务处理

Spanner 支持事务处理，按照读写操作可以将其分为读 / 写事务，只读事务和快照读事务三类。在一个事务中可以包含对多行数据的多个操作。读 / 写事务包含读操作和写操作。前面我们提到，Spanner 实现了多版本控制。在只读事务中只包含读操作，自动选择最新时间的版本读取。快照读事务允许用户指定一个时间读取数据。

Spanner 支持序列化隔离级别，因此不会丢失数据的正确性。在此基础上，为了获得更好的性能，结合多版本机制，只读事务和快照读事务可以不影响读 / 写事务的性能，使得 Spanner 成为了时间维度多版本的数据库，大大提升了性能表现。

接下来，我们将介绍 Spanner 读写事务和只读事务的具体实现。

读写事务

Spanner 的读写事务基于 paxos 和两阶段提交（2PC）协议。Spanner 会在参与事务的 paxos 组中选举出一个组作为协调者，进行协调、选取时间戳并进行 2PC 的操作。其中，选举出的组叫做协调者组，组中的 leader 叫做协调者 leader，其他节点叫做协调者从节点。其他的组叫做参与者组，组中的 leader 叫做参与者 leader，其他节点叫做参与者从节点。
具体事务流程如下：

• • 读：获取对应的 paxos 组的锁，读取最新版本的数据

•  

• • 写：将数据暂存入客户端内存，不先写入数据库，以保证未提交数据对其他客户端不可见

•  

• • 两阶段提交，过程如下：

a）客户端将内存中的数据和 commit 请求发送到对应的 paxos 组的 leader
b）参与者 leader 获取上述写入数据对应的写锁，分配一个 prepare 时间戳  ，对 prepare 消息进行 paxos 写，并发送 prepare 消息到协调者 leader
c）协调者 leader 获取写入数据的写锁，接收到所有 prepare 消息后，分配 commit 时间戳  ，要求大于接收到的最大 prepare 时间戳和 TT.now().latest
d）协调者 leader 进行 commit wait，等到 TT.after( ) 为 true，进行提交操作
e）协调者对 commit 消息进行 paxos 写，并发送 commit 消息给参与者 leader，提交数据，释放锁f）参与者 leader 接收到 commit 消息，进行 paxos 写，调整时间戳，提交数据，释放锁。

只读事务

只读事务无需协调时间戳和 2PC 操作。具体流程如下：

• 客户端向任意 paxos 组的 leader 发起请求，使该 leader 分配一个 start 时间戳  ，要求大于 TT.now().latest。

• 读：客户端携带上述时间戳，向相应的 Paxos 组中的 leader 发送读请求。等待该时间戳之前的事务结束后，开始读取数据。

• 事务提交，paxos group 的 leader 进行 commit wait，即等到 TT.after( ) 为 true 后，进行提交。

总结

Google Spanner 通过引入 TrueTime API 和 paxos 协议，实现了全球范围内的数据一致性和高可用性。其独特的数据模型和分布式事务处理机制，使其成为当时处理大规模、复杂数据的理想选择，并为后续分布式数据库技术的发展奠定了基础。

参考文献

[1] Corbett J C, Dean J, Epstein M, et al. Spanner: Google’s globally distributed database[J]. ACM Transactions on Computer Systems (TOCS), 2013, 31(3): 1-22.
[2] 《分布式系统与一致性》 -- 陈东明
[3] https://blog.csdn.net/qq_40229166/article/details/129676187
[4]  https://levy5307.github.io/blog/spanner/#concurrency-control
[5]  https://zhuanlan.zhihu.com/p/515895443