谷歌新发布的分布式数据库服务，是要打破CAP定理了吗？

作者 登州知府

2月14日，Google宣布推出Cloud Spanner云端数据库服务的Beta版。Cloud Spanner是构建在Google Cloud Platform（GCP）平台上的全球级分布式关系型数据库服务，主要为OLTP场景的核心业务应用提供服务。不同于Bigtable、Cloud SQL和Cloud Datastore，此次Google发布的Cloud Spanner打破了传统关系型数据库与NoSQL数据库之间的壁垒，让开发者可以使用到兼具二者优点的新型数据库：支持ACID事务及SQL语义，同时具备水平扩展和跨数据中心高可用。

1．什么是Cloud Spanner?

Cloud Spanner提供（跨区域／跨数据中心）分布式关系型数据库服务，即所谓NewSQL数据库服务。

· 分布式、横向扩展（NoSQL数据库）。

· 关系语义：Schema, ACID事务和SQL查询（传统关系型数据库）。

· Cloud Spanner[1]可以横向扩展到跨区域、跨数据中心的几百个甚至几千个节点，同时保证全局强一致性的事务。横向扩展使得Cloud Spanner服务既是高可用的（一个实例失效，还有其他实例），又具备高吞吐能力（多实例并行处理）。

注1: Cloud Spanner只支持SQL查询，即支持读操作。写操作是自定义的API[2]。

2．这算是打破CAP定理了吗？

且慢，这是说Cloud Spanner同时提供了强一致性和高可用性吗？CAP定理指出一个分布式系统，下列三个特性只能同时实现两个：

· 一致性（Consistency）：分布式共享的数据只能有一个值；

· 可用性（Availability）：读写操作都是100%可用；

· 分区（Partition）：能够容忍网络分区。

在广域网环境中，通常认为网络分区是不可避免的，分布式系统只能是一个CP系统或AP系统。为什么Cloud Spanner能够实现一个CA系统呢？

Eric Brewer指出[3][4]，严格地说，Cloud Spanner并非一个CA系统，但从实际效果看，“仿佛就是”一个CA系统。

首先，Cloud Spanner确实会发生网络分区，此时它会选择C而不保证A，因此，理论层面上，Cloud Spanner实际上是一个CP系统。

其次，Cloud Spanner实际上能够提供5个9以上的可用性，这对于大多数应用来说，足以视为高可用。

注2：这个可用性是根据Google及已有客户使用Spanner服务的实际情况计算的。不能保证所有的应用都能达到这个程度的可用性。

3．所谓的高可用性，究竟是指什么？

现在的问题是：一个跨区域、跨数据中心的CP式分布式系统，高可用的定义是什么？如何保证高可用性？

可用性的定义：确定停用时间区间，观察一段时间内服务的停用情况。如果在某个时间点服务停用，只有当停用时间超过时间区间，才会真正被算为服务停用。如果还没到一个时间区间就已经恢复服务，则不算服务停用。

举个例子，假设停用时间区间是10分钟，观察1000分钟的服务。共发生2次服务停用。第一次，5分钟后服务恢复；第二次，12分钟后服务恢复正常。只有第二次才会被视为发生了服务停用，所有该服务的可用性是1-1/100=0.99。

什么叫高可用？首先，服务实际上具有很高的可用性，用户的应用程序中无需包含专门处理服务停用的代码。像Google内部使用的Spanner服务，虽然达不到100%可用性，但是远超5个9的可用性。从Google和客户实际使用的情况看，可以视为一个高可用的系统。

注3: Cloud Spanner与Spanner不同，可用性估计会低一些，因此号称是5个9的可用性。但是计算可用性时，没说停用时间区间是多少。

其次，引发服务故障（包括停用）的原因很多。这里讨论Cloud Spanner可用性的前提是客户端工作正常，能够发送请求，因此能够发现服务是否停用。显然，仅考虑这种情况计算得到的服务可用性，比Spanner真正的可用性要高很多。

最后，由于Spanner采用特殊的网络技术，在实践中，几乎不会发生网络分区。因此，不考虑因为网络分区导致的服务不可用。

总而言之，说Cloud Spanner高可用是指：

· 实践中，系统处于CA状态的概率非常高，用户不需要编写处理服务停用的代码；

· 如果发生了服务停用，原因是网络分区的可能性也非常非常小。

4. Cloud Spanner高可用性究竟是如何实现的？

Google打造了私有的全球网络。以Spanner服务为例，所有的路由器和链接（除了客户端与服务的链接）都是由Google控制的。每个数据中心都至少有3条独立光纤连接到私有全球网，保证任何两个数据中心之间都有多条物理路径。在同一个数据中心内，网络设备和路径也是冗余的。因此，不会出现因为网络路径中断引发的网络分区。

如果配置不当或者软件升级，导致多条路径同时中断，就会引发网络分区。因此，采用部分升级的策略，即每次升级影响到部分路径或副本，确保无虞之后，再全面升级。

当然，除了网络分区，还有很多原因能够引发服务停用。实际上，在所有引发服务事故（包括停用）的原因中，与网络相关的仅占8%左右。既然Google用私有全球网络解决了网络分区的问题，那么剩下那些问题如何解决？答案很简单：他们有一只厉害的运维队伍。

注4：讨论了半天，实质上是告诫大家别想着达到Google的高可用性了。你有钱打造私有全球网吗？你有高效的运维队伍吗？没有，就购买Google托管的Cloud Spanner服务吧。

一个现实的问题是：即使采用上述手段，使得网络分区的可能性大大降低，接近于零。毕竟还不是零，万一发生了网络分区呢？答案是：如果发生网络分区，Cloud Spanner将保证强一致性，不管可用性。至于如何保证强一致性，那是另外一个需要详细讨论的问题了。

参考资料

[1] Introducing Cloud Spanner: a global database service for mission-critical applications

[2] Cockroach Labs CTO谈Cloud Spanner

[3] Inside Cloud Spanner and the CAP Theorem

[4] Spanner, TrueTime and the CAP Theorem