转载

谷歌新发布的分布式数据库服务，是要打破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 可以横向扩展到跨区域、跨数据中心的几百个甚至几千个节点，同时保证全局强一致性的事务。横向扩展使得 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 将保证强一致性，不管可用性。至于如何保证强一致性，那是另外一个需要详细讨论的问题了。