index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文深入解析了 Google Spanner 数据库的架构，探讨了其如何应对高可用性挑战。文章首先回顾了 Google 早期使用 MySQL 存储广告数据的局限性，以及在扩展性和事务处理方面遇到的难题。随后，文章详细介绍了 Spanner 如何通过分布式 SQL 数据库的设计，结合原子性、一致性、隔离性和持久性（ACID）特性，来实现 99.999% 的可用性。重点阐述了 Spanner 在 TrueTime 时间同步、两阶段提交协议、两阶段锁和快照隔离等关键技术上的应用。最后，文章强调了 Spanner 对 Google 广告业务的重要性。
🚀 早期 Google 使用 MySQL 存储广告数据，但随着用户增长，MySQL 的扩展性成为瓶颈，重新分区耗时严重，且事务处理难以满足 ACID 合规性。
💡 Spanner 是 Google 开发的分布式 SQL 数据库，旨在解决 NoSQL 扩展能力与 MySQL 的 ACID 特性之间的矛盾，实现了原子性、一致性、隔离性和持久性。
⏱️ Spanner 使用 TrueTime 同步全球服务器时间，结合 GPS 时钟与原子钟，每 30 秒校准一次服务器时间，确保时间戳全局一致，从而实现强一致性。
🔒 Spanner 采用两阶段锁（2PL）管理写操作，实现写操作隔离，并使用快照隔离（基于多版本并发控制 MVCC）实现无锁读取，避免锁竞争。
💾 Spanner 通过 Paxos 协议将数据同步写入多数副本，再异步复制至其他副本，保证了数据的持久性，同时将计算层与存储层分离，使用 Google Colossus 分布式文件系统，保障高性能与持久性。
原创 Neo Kim 2025-03-24 07:15 广东
如何实现 99.999% 的可用性？
注：本文解析 Google Spanner 架构。如需深入探索，请参考文末引用资料。本文基于研究整理，可能与实际实现存在差异。
曾经，两名学生试图以百万美元出售他们的大学项目，却以失败告终。于是他们决定继续开发，并将其命名为 Google。其主要收入来源是广告位（Ads），且增长势头迅猛。早期，他们为简化架构选择 MySQL 存储广告数据。随着用户激增，通过分区扩展 MySQL 规模。
存储需求随增长飙升，而重新分区需跨服务器迁移数据，耗时严重。但分区后事务处理变得复杂——事务本质是一系列读写操作的原子组合。
他们需要 NoSQL 的扩展能力与 MySQL 的 ACID 特性，于是创造了 Spanner——一个分布式 SQL 数据库。
原子性指事务要么全部完成，要么完全失败。例如，事务需同时更新不同分区的数据。但确保所有分区提交成功十分困难，因此采用 两阶段提交协议（2PC）：Spanner 提供 全局强一致性。例如，欧洲的数据更新后，亚洲的读取也会立即生效。为实现这一点，每个分区通过 Paxos一致性算法 选举领导者。分区领导者负责写操作，副本处理读操作，且领导者可能分布在不同区域。实现强一致性的一个简单方法是使用时间戳对写入进行排序（它允许跨服务器一致地查看数据），但让全世界所有服务器都保持相同的时间还是非常难的。因此，Spanner 使用 TrueTime 同步全球服务器时间。TrueTime 结合 GPS时钟 与 原子钟，每30秒校准一次服务器时间，确保时间戳全局一致。Spanner 采用 两阶段锁（2PL） 管理写操作：同时使用 快照隔离（基于多版本并发控制 MVCC），读取时返回特定时间点的数据版本，避免锁竞争。工作原理如下：此外，旧版本也会在特定时间后自动删除以节省存储空间。Spanner 通过 Paxos 协议将数据同步写入多数副本，再异步复制至其他副本。计算层处理读写请求，存储层使用 Google Colossus 分布式文件系统，保障高性能与持久性。最终，Spanner 实现 99.999% 可用性。Google 2023 年广告收入达 2370 亿美元，成为全球最具价值企业之一。
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
阅读原文
跳转微信打开
