AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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

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

关注

评论

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

Deepseek进入业务深水区,为什么需要昇腾大EP?

脑极体

AI

“全球金牌敏捷课程” · 4月19-20日CSM认证课程 · Jim老师引导讨论AI & Agility话题

ShineScrum

敏捷 项目开发 CSM认证 CSM认证培训

CrossOver 25.0 for macOS & Linux - 领先的 Wine 解决方案

sysin

crossover

《Operating System Concepts》阅读笔记:p331-p353

codists

操作系统

4大观点直面呈现|直播回顾-DeepSeek时代的AI算力管理

雅菲奥朗

AI AI算力 DeepSeek

DeepSeek赋能SRE:新时代下SRE人员的技能革新

雅菲奥朗

SRE SRE培训 DeepSeek

HarmonyOS ArkTS声明式UI开发实战教程

李游Leo

HarmonyOS

Java 单例模式与线程安全

知识浅谈

Java 单例模式

从 Web2 到 Web3,她做对了什么使其成为行业资深大牛?

One Block Community

开发 web3

弹性扩展何以助力 Polkadot 2.0 触达无缝互操作的理想愿景?

One Block Community

技术 开发者 polkadot

Coremail全面对接DeepSeek,开启办公效率新革命

科技热闻

智慧园区,智慧工地,智慧物业等建设方案(PPT))

金陵老街

智慧园区

Apache NetBeans 25 (macOS, Linux, Windows) - Java 等多语言开源跨平台 IDE

sysin

NetBeans

京东商品视频API接口全攻略

tbapi

京东API 京东商品视频API 京东商品视频数据采集

使用 INFINI Gateway 保护 Elasticsearch 集群之修改查询不合理参数(一)

极限实验室

elasticsearch Gateway

1688商品详情API接口全攻略

tbapi

1688API 1688商品详情API 1688商品详情数据采集

售票系统(源码+文档+讲解+演示)

深圳亥时科技

WebGL开发VR软件框架

北京木奇移动技术有限公司

VR开发 软件外包公司 webgl开发

从零复现,全面开源:360 Light-R1-14B/7B带来端侧AI平权时刻

脑极体

AI

【Redis技术进阶之路】「底层源码解析」揭秘高效存储模型与数据结构底层实现(跳跃表 - 上)

码界西柚

redis 跳表 跳跃表 redis 底层原理 数据库 nosql

数据可信、隐私可控:CESS 如何打造波卡生态数据新基建?

One Block Community

区块链 开发 web3

淘宝商品数据API接口实战指南|手把手教你获取商品详情和全店数据(避坑版)

代码忍者

淘宝API接口

业务幂等性设计的六种方案

Java随想录

Java MySQL 幂等

Polkadot 迈向 Web3 云:超越以太坊原生 Rollup 方案的创新之路

One Block Community

开发者 Rollup web3

优化成本与效率:低代码平台构建企业级应用的技术探析

JeeLowCode低代码平台

低代码 低代码平台 低代码凭条 低代码, 低代码选择

网上纪念馆(源码+文档+讲解+演示)

深圳亥时科技

1688商品列表API 接口全攻略

tbapi

1688商品列表接口 1688API 1688商品列表数据采集

自动化测试的 8 个最佳实践

FunTester

WebGL开发VR软件的优化

北京木奇移动技术有限公司

VR开发 软件外包公司 webgl开发

2025大型企业财务数智化峰会·上海站成功举办!

用友智能财务

AI 财经 财务 会计

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