写点什么

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

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

关注

评论

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

在线HTML美化格式化工具

入门小站

工具

电商系统微服务拆分

邹玉麒

「架构实战营」

【架构实战营】毕业设计项目

wgl

架构实战营

架构实战营:模块六业

刘璐

毕业总结:

Anlumina

#架构实战营

Linux之seq命令

入门小站

Linux

毕业总结

黄秀明

「架构实战营」

KCP协议:从TCP到UDP家族QUIC/KCP/ENET

zhoulujun

网络加速 KCP 游戏加速 quick 带宽优化

电商系统微服务拆分

随欣所遇

架构训练营5期

架构训练营模块六

刘帅

READS: Salesforce服务健康指标最佳实践

俞凡

微服务 最佳实践 可观测性 大厂实践 Salesforce

失眠的岁月,我们都交了哪些科技智商税?

脑极体

模块六作业

Mr小公熊

聊聊 Webpack 插件系统的关键实现 Tapable

蛋先生DX

JavaScript 前端 webpack

一文概述:云端常见的攻防及实践

穿过生命散发芬芳

3月月更

在线HTTP/HTTPS协议GET,POST,RESTful接口测试

入门小站

工具

一文搞懂I2C总线通信

不脱发的程序猿

嵌入式 通信协议 I2C协议

Vuex在TSX中的改造方案:TS改造Vue2项目Vuex如何处置?

zhoulujun

Vue3 vue2 tsx vuex-class vuex-module-decorators

Web 3.0是什么?区块链热潮下2022年必懂的科技概念

CECBC

公平的获得财富的机会,区块链通证经济是未来的必然趋势

CECBC

《直击本质》——读后上

圣迪

系统性思考 直击本质 金字塔原理 本质

底什么是伪静态?为什么要做伪静态?

源字节1号

网站建设 SEO伪静态

JS中的函数参数默认值是如何写的?

Changing Lin

3月月更

毕业设计

Anlumina

「架构实战营」

电商微服务架构拆分

Fingal

架构实战营

拆分电商系统为微服务

石小天

「架构实战营」

Salesforce服务可观测性设计模式

俞凡

微服务 可观测性 大厂实践 Salesforce

电商系统拆分为微服务

凌波微步

「架构实战营」

如何保持知识与技能的先进性

长沙造纸农

学习方法 方法论 认知提升 学习笔记 技能提升

深度学习优化层技术

Clarke

[Day1]-[广度搜索(BFS)] 二叉树最小高度

方勇(gopher)

LeetCode BFS 数据结构算法

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