写点什么

以 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:004066
用户头像

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

关注

评论

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

2021最新腾讯面经分享:Java面试刷题PDF(17个专题 5000字解析)

比伯

Java 编程 程序员 架构 面试

方法论分享之:刻意练习,微小改进

boshi

方法论 经验分享 七日更

使用 Puppet 进行配置管理

码语者

DevOps 配置管理

单点登录(SSO)

一个大红包

SSO 28天写作 单点登录 3月日更

女神节|深情告白季,程序员和他的浪漫

InfoQ写作社区官方

热门活动

什么是开放艺术?探讨融合区块链技术的新艺术范式

CECBC

进程和nginx

一个大红包

28天写作 3月日更

容器 & 服务:K8s 与 Docker 应用集群 (二)

程序员架构进阶

Docker 持续集成 kubernete 服务化 3月日更

表达的时代

ES_her0

28天写作 3月日更

Linkerd or Istio?哪个Service Mesh框架更适合你?

xcbeyond

Service Mesh istio 技术选型 Linkerd 3月日更

用户画像实践

Jackchang234987

VMware Workstation

梅花鹿鹿

虚拟机

在一个操蛋(执行力极差)的团队工作是一种怎样的体验?

冰河

团队管理 程序人生 执行力 问题总结 团队成长

终于讲清楚了:深入理解Java 应用程序中 final 关键字的各种使用场景

老王说编程

Java final

融云CEO韩迎:飞信十年珍贵历练,做To B别有取巧的心思

融云 RongCloud

IM RTC 飞信

政府区块链招投标市场活跃 “区块链+警务”等多元化领域成​方向

CECBC

OSPF路由协议基本知识点大全

从JVM底层原理分析数值交换那些事

Java 架构 JVM

程序员成长第二十篇:刚晋升管理者,有哪些方面要注意?

石云升

程序员 28天写作 职场经验 管理经验 3月日更

作业 - 第五周

eva

JAVA学习心得

张鹤羽

28天写作 3月日更

Wireshark数据包分析学习笔记Day2

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

LeetCode题解:309. 最佳买卖股票时机含冷冻期,动态规划,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

当开工季遇上采购季,云通信主播教你怎么省心又省钱

阿里云Edge Plus

云通信

mysql常用命令

Sakura

2021最新分享面试跳槽宝典:互联网大厂Java高级工程师核心面试498题(附解析)

比伯

Java 编程 程序员 架构 面试

搜狐三面:说说你是怎么解决MySQL死锁问题的!

Java架构师迁哥

翻译:《实用的Python编程》03_06_Design_discussion

codists

Python

写作对我来说是什么?

lenka

产品经理 写作 3月日更

【回溯算法】组合总和升级版 ...

宫水三叶的刷题日记

面试 LeetCode 数据结构和算法

震撼来袭!2021版全新版Java面试笔记现世,简直把所有Java知识面试题写出来了

Java 架构 面试

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