AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

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

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

关注

评论

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

零基础如何上手APICloud App、小程序多端开发

YonBuilder低代码开发平台

前端开发 APP开发 APICloud 多端开发 小程序开发

不会使用Spring的配置文件,赶紧把这个甩给他

华为云开发者联盟

Java spring API bean 配置文件

等保2.0基本要求是什么?跟等保1.0一样吗?

行云管家

网络安全 等保 等级保护 等保2.0

第三节:SpringBoot中web项目推荐目录结构

入门小站

springboot java 编程

Hive底层 explain 执行计划详解

五分钟学大数据

hive 1月月更

【OpenMLDB Meetup #1】会议纪要

第四范式开发者社区

机器学习 第四范式 OpenMLDB 特征平台

Wi-Fi 6 提升了哪些方面?

BUG侦探

wifi MU-MIMO Wi-Fi 6 协商速率

Spock框架Mock静态资源经验汇总

FunTester

Mockito powermock Mock spock FunTester

java开发之SpringBoot+flowable实现工作流

@零度

Java springboot

一文带你快速拆解云智慧前端技术架构

云智慧AIOps社区

前端 前端开发 可视化 框架 技术干货

译文|借助 Pulsar Functions 迁移到无服务应用程序

Apache Pulsar

Java 开源 架构 云原生 Apache Pulsar

中国AIOps们,你们究竟是在骗谁?

码农一米

云计算 云服务

干掉大小流切换 I 帧!阿里云 RTC QoS 及视频编码联合优化之切流编码

阿里云CloudImagine

阿里云 WebRTC 直播 RTC 视频编码

深入剖析 HDFS 3.x 新特性-纠删码

五分钟学大数据

hdfs 1月月更

AI 收藏夹 Vol.004:Waifu Lab 火了,AI 是如何创作的?

Zilliz

Flume简介和架构安装配置详解

编程江湖

面对 Log4j2 漏洞,安全人都做了什么?

华为云开发者联盟

Java 漏洞 Apache Log4j2 Log4j2 漏洞 漏洞防护

从零开发区块链应用(五)--golang网络请求

杰哥的技术杂货铺

golang 区块链 HTTP post GET

大数据开发之Flink sql 的基础用法

@零度

flink sql 大数据开发

前端开发之React调度算法的迭代过程

@零度

前端开发 React

Java Spring Beans.xml里的Bean定义是如何被解析出来的

汪子熙

Java Spring Boot Spring Java 1月月更

阿里云EMAS 12月产品动态更新

移动研发平台EMAS

阿里云 移动研发平台 emas

火山引擎边缘计算节点通过 EC Ready 边缘云首批评测

火山引擎边缘云

云原生 边缘计算 测评

SSH 端口转发与 SOCKS 代理

CRMEB

百亿级监控场景大数据分位值计算实践

百度Geek说

大数据 后端

【等保小知识】等保二级是否需要做密评?什么是密评?

行云管家

网络安全 等级保护 等保2.0 等保二级

飞瓜数据发布2021年抖音短视频直播营销报告(年度版)

极客天地

使用 electron-builder 打包 Electron 程序

编程三昧

Electron electron实战 1月月更

BigDecimal 被拼多多的"砍一刀"应用到了极致

恒生LIGHT云社区

Java 拼多多 Java中精确小数计算

提效赋能:当企业在谈论数字化时,我们在谈论什么?

优秀

管理工具

科技为驱,创新为翼——鲸鲮科技喜获“2021北京软件核心竞争力企业”评价

鲸鲮JingOS

操作系统 创新 信创 信息化 科技企业

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