Google Spanner简介
Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能 同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。
Spanner是个可扩展，多版本，全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能 做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能：无锁读事务， 原子schema修改，读历史数据无block。
EMC中国研究院实时紧盯业界动态，Google最近发布的一篇论文《Spanner: Google’s Globally-Distributed Database》, 笔者非常感兴趣，对Spanner进行了一些调研，并在这里分享。由于Spanner并不是开源产品，笔者的知识主要来源于Google的公开资料，通过现有公开资料仅仅只能窥得Spanner的沧海一粟，Spanner背后还依赖有大量Google的专有技术。 下文主要是Spanner的背景，设计和并发控制。
Spanner背景
要搞清楚Spanner原理，先得了解Spanner在Google的定位。
从上图可以看到。Spanner位于F1和GFS之间，承上启下。所以先提一提F1和GFS。 F1
和众多互联网公司一样，在早期Google大量使用了Mysql。Mysql是单机的，可以用Master-Slave来容错，分区来扩展。但是需 要大量的手工运维工作，有很多的限制。因此Google开发了一个可容错可扩展的RDBMS——F1。和一般的分布式数据库不同，F1对应RDMS应有的 功能，毫不妥协。起初F1是基于Mysql的，不过会逐渐迁移到Spanner。 F1有如下特点：
· 7×24高可用。哪怕某一个数据中心停止运转，仍然可用。 · 可以同时提供强一致性和弱一致。 · 可扩展 · 支持SQL
· 事务提交延迟50-100ms，读延迟5-10ms，高吞吐
众所周知Google BigTable是重要的NoSql产品，提供很好的扩展性，开源世界有HBase与之对应。为什么Google还需要F1，而不是都使用 BigTable呢？因为BigTable提供的最终一致性，一些需要事务级
别的应用无法使用。同时BigTable还是NoSql，而大量的应用场景需 要有关系模型。就像现在大量的互联网企业都使用Mysql而不愿意使用HBase，因此Google才有这个可扩展数据库的F1。而Spanner就是 F1的至关重要的底层存储技术。
Colossus（GFS II）
Colossus也是一个不得不提起的技术。他是第二代GFS，对应开源世界的新HDFS。GFS是著名的分布式文件系统。
初代GFS是为批处理设计的。对于大文件很友好，吞吐量很大，但是延迟较高。所以使用他的系统不得不对GFS做各种优化，才能获得良好的性能。那为什么 Google没有考虑到这些问题，设计出更完美的GFS ?因为那个时候是2001年，Hadoop出生是在2007年。如果Hadoop是世界领先水平的话，GFS比世界领先水平还领先了6年。同样的 Spanner出生大概是2009年，现在我们看到了论文，估计Spanner在Google已经很完善，同时Google内部已经有更先进的替代技术在 酝酿了。笔者预测，最早在2015年才会出现Spanner和F1的山寨开源产品。
Colossus是第二代GFS。Colossus是Google重要的基础设施，因为他可以满足主流应用对FS的要求。Colossus的重要改进有：
· 优雅Master容错处理 (不再有2s的停止服务时间) · Chunk大小只有1MB (对小文件很友好)
· Master可以存储更多的Metadata(当Chunk从64MB变为1MB后，Metadata会扩大64倍，但是Google也解决了)
Colossus可以自动分区Metadata。使用Reed-Solomon算法来复制，可以将原先的3份减小到1.5份，提高写的性能，降低延迟。客户端来复制数据。具体细节笔者也猜不出。
Google分布式数据库简介.
