一．Spanner功能概要
在Spanner面世篇中简单的介绍过：Spanner具有高扩展性，多版本（multi-version）、世界级分布（globally-distributed）及同步复制（synchronously-replicated）等特性。
Spanner立足于高抽象层次，使用Paxos协议横跨多个数据集把数据分散到世界上不同数据中心的状态机中。世界范围内响应，出故障时客户副本之间的自动切换。当数据总量或服务器的数量发生改变时，为了平衡负载和处理故障，Spanner自动完成数据的重切片和跨机器（甚至跨数据中心）的数据迁移。
Spanner可以轻松的横跨数百个数据中心将万亿级数据库行扩展到数百万台机器中。高可靠性更是让应用程序如虎添翼，即使面对大范围的自然灾害，可靠性仍然能得到良好的保障（因为Spanner有着世界级的数据转移）。最初的用户来自F1 — 使用了美国境内的5个拷贝。多数其他应用程序都是在同一个地理区域将数据复制3到5份，使用相对独立的故障模式。也就是说多数的应用程序会选择低延迟超过高有效性，只用一两个数据中心来保障数据的可靠性。
Spanner的主旨是数据中心的管理，但是在分布系统基础设施的特色上同样是下足了功夫。尽管Bigtable很讨一些项目欢心，我们还是收到了一些Bigtable在某些应用程序（复杂的、不断变化的架构或者需要在大区域响应中保持强一致性）中使用会异常艰难的投诉。许多Google的应用程序都在使用Megastore，因为它的半关系数据模型支持同步复制，尽管它有着可怜的吞吐量。
因此，Spanner已经从Bigtable-like版本的键值存储进化到现在的多版本数据库。数据存放在系统化的半关系表格中；数据被版本化了，每个版本都会用提交时间进行标注；旧版本的数据服从结构的垃圾回收策略；应用程序可以通过数据以前的时间标记来读取。
Spanner支持多用途的事务处理，并且提供了一个基于SQL的查询语言。作为世界级分布的数据库，Spanner更有一些令人感兴趣的特色：
1. 应用程序可以通过复制装置动态的对数据进行微控制。还可以通过制定约束条件来指定数据中心和其中包含的数据（无视数据与用户间的距离，数据与数据间的距离及数据保持的份数）。系统动态的和透明的在数据中心之间转移数据来保证资源的平衡利用。
2. Spanner有两个特性是很难在分布式数据库中实现的：读写的外部一致性和基于时间标记的全局读一致性。这让Spanner可以在全球范围内保持数据的一致备份，MapReduce一致执行和原子的Schema修改，即使是连续操作。
这些特性保证了Spanner可以有序的在世界范围内响应事务处理，即使是分散式的事务。时间标记反应了事务的顺序。另外，序列化的时间确保了外部一致性：如果事务T1在另一个事务T2之前提交，那么T1提交的时间标记是小于T2的。
Spanner是首个提供如此保证的系统。促成这项跨越的关键是TrueTime API（具有原子时钟和GPS）。TrueTime API直观的揭示了时钟的不可靠性，它运行提供的边界更决定了时间标记。如果不确定性很大，Spanner会降低速度来等待不确定因素的消失。Google集群管理软件更奠定了TrueTime的实施的基础。通过新型原子时钟将不确定性无限的放小。
二．Spanner的设计及一些重要组件(本部分特别感谢EMC研究院 颜开提供翻译支持)
由于Spanner是全球化的，所以有两个其他分布式数据库没有的概念。
- Universe。一个Spanner部署实例称之为一个Universe。目前全世界有3个。一个开发，一个测试，一个线上。因为一个Universe就能覆盖全球，不需要多个。
- Zones. 每个Zone相当于一个数据中心，一个Zone内部物理上必须在一起。而一个数据中心可能有多个Zone。可以在运行时添加移除Zone。一个Zone可以理解为一个BigTable部署实例。
如图所示。一个Spanner有上面一些组件。实际的组件肯定不止这些，比如TrueTime API Server。如果仅仅知道这些知识，来构建Spanner是远远不够的。但Google都略去了。这里做一下简单介绍：
- Universemaster: 监控这个universe里zone级别的状态信息。
- Placement driver：提供跨区数据迁移时管理功能。
- Zonemaster：相当于BigTable的Master。管理Spanserver上的数据。
- Location proxy：存储数据的Location信息。客户端要先访问他才知道数据在那个Spanserver上。
- Spanserver：相当于BigTable的ThunkServer。用于存储数据。