【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

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

关注

评论

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

java培训Stream遍历树形结构案例分享

@零度

stream JAVA开发

谈谈对 Database Plus 认识与畅想

SphereEx

Apache 数据库 SphereEx ShaardingSphere

avatar Logo

爱好编程进阶

Java 程序员 后端开发

CentOS 7

爱好编程进阶

Java 程序员 后端开发

Day06-Java代码操作阿里云oss,开发前准备,开发参考文档

爱好编程进阶

Java 程序员 后端开发

OpenHarmony 设备开发环境搭建 / 源码获取 / 编译 / 烧录

Anna

OpenHarmony

关于「应变力」这个超能力|ONES 人物

万事ONES

管理

大数据培训Hive架构思想与设计原理

@零度

hive 大数据开发

API 文档构建工具 - Swagger2简单应用

爱好编程进阶

Java 程序员 后端开发

CDH5部署三部曲之一:准备工作

爱好编程进阶

Java 程序员 后端开发

influxdb基础(七)

爱好编程进阶

Java 程序员 后端开发

API 分页探讨:offset 来分页真的有效率吗?

爱好编程进阶

Java 程序员 后端开发

CGBTN2108-DAY05总结复习

爱好编程进阶

Java 程序员 后端开发

Java 输入一个字符串格式日期,获取对应的自然月开始结束时间,对应的自然年开始结束时间

爱好编程进阶

Java 程序员 后端开发

OpenHarmony啃论文计划-elf文件格式介绍

Anna

OpenHarmony

我推荐的Flutter项目结构

坚果

4月月更

2hutool源码分析:DateUtil(时间工具类)-常用的时间类型Date,DateTime

爱好编程进阶

Java 程序员 后端开发

了解HTTP的基本历史及知识

CRMEB

docker限制容器的cpu内存使用率

爱好编程进阶

Java 程序员 后端开发

IntelliJ IDEA 中集成并使用 Git 图文教程

爱好编程进阶

Java 程序员 后端开发

编码的底层原理

程序员猪小哼

java面试 底层原理 死磕 Java 基础

架构实战营作业四

热猫

13 高可用的服务

爱好编程进阶

Java 程序员 后端开发

Day163

爱好编程进阶

Java 程序员 后端开发

web前端培训懒加载对 Web 性能的影响

@零度

前端开发 懒加载

为什么boolean存储需要32bit?

程序员猪小哼

java基础 底层原理

2020年Java面试复盘,收获Offer,金三银四程序员面试精装版pdf,分享给跳槽面试的程序员

爱好编程进阶

Java 程序员 后端开发

从Flutter开始聊聊跨平台移动开发框架

FinClip

Day180

爱好编程进阶

Java 程序员 后端开发

怎么写帮助文档?产品人看过来

小炮

帮助中心

Java 输入一个字符串格式日期,获取对应的自然月开始结束时间,对应的自然年开始结束时间(1)

爱好编程进阶

Java 程序员 后端开发

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