BT

你的观点很重要! 快来参与InfoQ调研吧!

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

| 作者 登州知府 关注  他的粉丝 发布于 2017年2月21日. 估计阅读时间: 8 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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 高可用是指:

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

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

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

[5] Google 今日发布 Cloud Spanner,这些内容你可能想知道


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

有道理 by xie andy

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

竟无力反驳

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT