你好,游客 登录 注册 搜索
背景:
阅读新闻

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

[日期:2017-02-21] 来源:infoq.com  作者: 登州知府 [字体: ]

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,这些内容你可能想知道

本文永久更新链接地址http://www.linuxidc.com/Linux/2017-02/140865.htm

linux
相关资讯       Google分布式数据库服务 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款