写点什么

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

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

关注

评论

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

字节跳动Dev Better技术沙龙来啦!参与活动赢好礼,限时免费报名中!

字节跳动终端技术

字节跳动 技术沙龙 华泰证券

Flink CDC + OceanBase 全增量一体化数据集成方案

Apache Flink

大数据 flink 编程 流计算 实时计算

LoadBalance

Damon

6月月更

常见线程数量的估算方式

snlfsnef

系统设计 线程 多CPU

大数据培训Table API 和 Flink SQL的整体介绍

@零度

flink 大数据开发

什么是数据流向分析?

清林情报分析师

数据分析 流向分析 数据流向 资金流向 可视化分析

如何使用物联网低代码平台进行系统管理?

AIRIOT

物联网 低代码开发 低代码开发平台

云原生中间件 — Kafka Operator 总览篇

Daocloud 道客

云原生 开源项目 消息中间件 上云 Strimzi Kafka Operator

高考后,学会这种能力,让你收益终生!

图灵教育

数学 高考 数学建模

吉林长春等保测评公司有几家?详细地址在哪里?

行云管家

网络安全 等级保护 等保测评 等保测评机构 吉林

庄周梦蝶终非蝶,冷静看待“谷歌AI形成人格”事件

易观分析

谷歌AI

信息化App在「左」,数字化App在「右」

Speedoooo

App 数字化 信息化

可视化技术在 Nebula Graph 中的应用

NebulaGraph

可视化 图数据库 知识图谱

哈希彩竞猜娱乐游戏俱乐部系统开发详情

开发微hkkf5566

百度评论中台的设计与探索

百度Geek说

资金穿透分析

清林情报分析师

数据分析 分析软件 分析工具 资金穿透 资金分析

为了写好代码,我坚持了这8条习惯!

Jackpop

TASKCTL关于 "Fastjson反序列化远程代码执行漏洞” 的风险通告

敏捷调度TASKCTL

DevOps ETL算法 大数据平台 反序列化 TASKCTL

使用APICloud AVM多端框架开发消防检查助手App项目实践分享

YonBuilder低代码开发平台

APP开发 APICloud 多端开发 应用开发 avm.js

如何从零开始开发一款chrome扩展?

Jackpop

web前端培训Vue面试题分享

@零度

Vue 前端开发

如何最简单、通俗地理解Python的pandas库?

Jackpop

TiDB 6.1 发版:LTS 版本来了

PingCAP

分布式

从感知智能跨越到认知智能,NLP领域要做哪些创新?

澜舟孟子开源社区

人工智能 自然语言处理 nlp 大模型 认知智能

私有云和公有云的主要区别有几点?两者哪个更安全?

行云管家

云计算 公有云 私有云 企业上云 云管平台

小程序开发真的可以取代APP软件开发设计吗?

开源直播系统源码

软件开发 小程序开发

Android技术分享| 自定义LayoutManager

anyRTC开发者

音视频 移动开发 Andriod 动画效果 LayoutManager

什么是面向对象编程?终于懂了

Jackpop

漫谈软件架构

韩陆

云原生 领域驱动设计 可观测性 软件架构 事件驱动架构

BI的落寞,低代码会重演一遍吗?

ToB行业头条

理解异步

大熊G

JavaScript 前端 6月月更

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