聚焦大模型浪潮下软件工程的创新洞见与实践 |QCon主题演讲大咖来袭 了解详情
写点什么

以 CockroachDB 为例,深入了解 CAP 定理

  • 2017-07-02
  • 本文字数:1782 字

    阅读完需:约 6 分钟

CAP 定理是分布式系统理论的基础,它的核心内容是说,在存在分区(如网络故障)的情况下,一个系统无法同时保证一致性(consistency)和可用性(availability),只能二选其一。

有些数据库选择了一致性,那么这类系统就被称为 CP 系统。而有些系统更看重可用性,也就是 AP 系统。一致性和可用性对于任何一个业务系统来说都是至关重要的,如何在这两者之间做出选择也就变成一个大难题。

这篇文章将说明如何在保证系统一致性的同时仍然能够保证高可用性,并以 CockroachDB 为例来解释 CAP 定理,以及为什么对于大多数数据库来说一致性更重要。

高可用性

在 CAP 定理里,可用性具有严格的二元性:一个系统要么可用,要么不可用。但在服务级别协议(SLA)里,可用性具有连续性。

例如,一个系统可以保证 99.99% 的可用性(4 个 9,也就是说每年允许宕机的时间不超过一个小时)。100% 的可用性是不现实的。工程上的高可用性要求对各种中断的严重程度进行评估,并在降低故障率所要花费的成本上做出平衡。

一个具有一致性保证的系统有时候因为网络分区出现不可用,但即使是具有可用性保证的系统,也会因为各种原因出现不可用。在一个良好的网络环境里,因网络分区造成的故障不会比其他类型的故障更常见。既然故障是不可避免的,进而导致不可用,那为什么不先保证一致性呢?

Brewer 博士说 Google 的网络很少会出现分区,Spanner 数据库理论上是“CP”,但实际上几乎是“CA”的。这听起来有点跑题了,不过却也说明了在可用性方面做出一些权衡,其影响面不会太大。

合理的权衡

在分布式系统里,权衡无处不在,我们总是要在一致性、可用性、性能和灵活性之间做出权衡。而 CAP 定理将选择的范围缩小到一致性和可用性之间,但无法涵盖所有可能造成不可用的问题根源。

有各种原因可能造成系统中断,比如硬件单点故障、应用程序的缺陷或运维人员的人为错误。而从整个系统层面来看,如果能够处理好网络分区问题,那么就有可能在不牺牲一致性的前提下提升可用性。CAP 的可用性不一定会带来实质性的可用性保证,但如果牺牲了一致性,将会给应用程序的代码带来复杂性,也意味着更高的工程成本。

假设有一个应用程序,它部署在 3 个数据中心里,客户端的流量经过负载均衡器连接到应用程序上。如果其中的一个数据中心因网络故障掉线,那么连接到这个数据中心的客户端将会遭遇中断,而不管底层的数据库是 CP 还是 CA 的。而如果负载均衡器将这些中断的客户端流量重定向到活跃的数据中心,不管底层的数据库如何处理网络分区问题,服务仍然可用。

只有当数据中心复本之间无法通信而客户端仍然能够与各个数据中心对话时,AP 系统仍然可用,而 CP 系统不可用。如果把整个系统作为整体部署来考虑,可以不用遵循 CAP 定理所要求的需要每个节点都要返回响应的原则,从而达到高可用性。

如果 AP 系统所能带来的可用性价值不高,那么为什么要为此牺牲一致性呢?理由只有一个,因为写入延迟。一致性系统在执行写入操作的时候需要协调各个节点来保证一致性(当然,有些系统对一致性读也有很高要求)。非一致性系统允许丢失数据,所以可以很快返回响应。对于速度比健壮性更重要的系统来说,或许这会是更好的选择。

CockroachDB 的 CAP

CockroachDB 是 CP 系统:每一份数据至少有 3 个复本,在写入数据时要求每个复本之间进行通信。在数据读取方面,其中的一个复本被授予一段时间的租期或一个数据子集的临时所有权,这个复本可以在不与其他复本通信的情况下处理读取请求。如果这个复本与其他复本失去联系,在租期内(默认是 9 秒钟)它仍然能够提供读取数据服务(但不能写入)。在租约到期之后,另外两个复本中的一个会得到新的租约。这样可以确保系统能够快速地从中断中恢复,提供最高的可用性,尽管它不符合 CAP 定理对可用性的定义。

CockroachDB 的强一致性基因让它有可能为分布式数据库提供与传统的非分布式数据库一样的一致性保证,同时保持高可用。对于大多数应用程序来说,CP 数据库会是更好的选择,尽管存在潜在的延迟,但它也为开发者提供了一些保证。

  • 大部分最近的写入对后续的读取是可见的。
  • 其他开发人员无法破坏应用整体的一致性。
  • 发生分区事件时,系统会阻塞,而不是返回不完整的数据。

感谢郭蕾对本文的审校。

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

2017-07-02 19:003791
用户头像

发布了 322 篇内容, 共 138.4 次阅读, 收获喜欢 145 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营第十一周作业

李日盛

IPFS矿机软件系统开发|IPFS矿机APP开发

系统开发

架构入门感悟之十一

笑春风

时间戳——区块链不可篡改特性的重中之重

CECBC

区块链

架构师训练营—大作业(二)

Geek_shu1988

【计算机内功修炼】二:读取文件时,程序经历了什么

码农的荒岛求生

后端 文件 操作系统 进程 线程’

从考研失败到最具成长力员工,这个2020就像过山车一样

Java鱼仔

程序员 面试 程序人生 考研

2021你好 | 一名五道口程序员的年终总结

herongwei

程序员 职场 自媒体 年终总结 新年

2020年Python文章盘点,我选出了个人TOP10

Python猫

Python 学习 编程 技术

架构师训练营—第十三周作业

Geek_shu1988

RocketMQ避坑指南:你部署的RocketMQ集群真的是高可用?

中间件兴趣圈

架构 RocketMQ 故障分析 消息队列

第一周架构方法-练习-食堂就餐卡系统设计

潘涛

架构师训练营 4 期

区块链游戏开发注意事项

CECBC

区块链 区块链游戏

区块链2020年终盘点

CECBC

区块链

架构师训练营—大作业(一)

Geek_shu1988

一次线上cpu过高问题

kcnf

Python+Selenium——自动办公美梦的破碎与重建

小匚

Python 自动化 办公

微信气质

池建强

微信

想法

BerryMew

探讨典型互联网系统使用的技术方案

Andy

数字版权资源价值日益凸显

CECBC

版权保护

第十一周作业

Jack

2021健康快乐

escray

2021

意想不到,这个神奇的bug让我加班到深夜

码农的荒岛求生

bug修复

现成花火交易所系统软件APP开发案例

系统开发

「架构师训练营 4 期」 第一周 - 001002

凯迪

交报告 | 2020年读完的50本书

Geek_u406me

【计算机内功修炼】一:看完这篇还不懂线程与线程池你来打我

码农的荒岛求生

高并发 线程池 进程 高性能 线程’

架构师大作业

_

大作业 架构师训练营第 1 期

「架构师训练营 4 期」 第一周 - 1001

凯迪

架构师训练营—第十三周学习总结

Geek_shu1988

以CockroachDB为例,深入了解CAP定理_语言 & 开发_薛命灯_InfoQ精选文章