Spanner已经在谷歌内部广为使用了，现在正在向公众开放。它是一个可管理的云数据库，可以作为谷歌云平台的一部分使用，而且不会涉及底层的基础设施。
Spanner看起来和传统关系型数据库一样，有ACID事务、SQL、关系型模式等。但是，它是分布式的，在地理上跨谷歌基础设施，可以满足日益增长的更大事务处理量。除此之外，它还有强一致性，在提供数据服务时只有几毫秒的延迟。
CAP理论证明一个数据库系统不可能同时满足以下三种特性：可用性、一致性和分区容忍性。关系型数据库倾向于牺牲可用性，而NoSQL数据库则用最终一致性换来了高可用性。
事实上Spanner也没有颠覆CAP理论，它只是在功能上看起来像是这样而已。谷歌基础设施副总裁Eric Brewer解释到：
Eric Brewer：这意味着根据CAP的定义，Spanner就是一个CA系统了吗？从技术上来说可以直截了当地回答“不是”，但从实际效果来说，却可以认为是“是”，用户可以认为它就是CA的而直接使用。
Brewer总结道，在Spanner系统中，出现网络分区的可能性是1比105。如果这种情况真的发生了，系统会选择一致性，从技术的角度看就是CP的。但是，由于这种可能性极低，所以也可以就认为它是可用的。
在Brewer的白皮书中，他解释这种级别的可靠性的基础在于Spanner是运行在谷歌全球自建网络中的。Spanner的网络包从来不会发到公共互联网中，而且由于冗余级别非常之高，像切断光纤之类的灾难性事件也不会导致断网。
还有一些第三方，比如Cloudera的分布式系统工程师Henry Robinson也认可这样的说法，他解释道：
Henry Robinson：可以从这个角度去考虑：CAP理论告诉我们每个系统都会有她自己的阿基里斯之踵，或者说是软胁，这就意味着在一定时间之内要放弃C或者放弃A。谷歌则把Spanner的软胁深深地埋在了某个黑洞里。
为了确保ACID特性，Spanner实现了典型的分布式事务模型——两阶段提交。Brewer解释说尽管这个模型要求所有的成员都必须在线，因此有些降低可用性，但Spanner通过使用一个Paxos组来绕过了这个问题，换句话说，当某些成员不在的时候，一个多数选举的结果也可以生效。
Spanner也使用了谷歌的全球同步的锁TrueTime。Brewer说TrueTime同时使用了GPS接收器和原子时钟来保证时间的准确性。它可以正确地为分布式事务打上时间戳，从而保证外部一致性。
面向公众的云Spanner仍然是Beta版，现在还可以在线上免费试用。
原文地址：http://www.linuxprobe.com/cloud-spanner-beta.html