谷歌已经为她的全球分布式关系型数据库服务云Spanner 对外发布了Beta 版。作为谷歌云平台的一部分，它同时提供ACID 事务和高可用性，看起来像是颠覆了CAP 理论。
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 版，现在还可以在线上免费试用。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论