到底如何理解CAP

栏目: 后端 · 发布时间: 4年前

内容简介:英文定义:In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.

点击蓝色“ 乔志勇笔记 ”关注我哟

加个“ 星标 ”,第一时间获取推送的文章哦

一:概念解析

英文定义:In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.

关键点解释:

1、互联和共享数据的情形

2、cap关注的是对数据的读写操作,而不是分布式系统的所有功能

二、约束解析

1、一致性 Consistency

A read is guaranteed to return the most recent write for a given client.

对某个指定的客户端来说,读操作保证能够返回最新的写操作结果

2、可用性 Availability

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).

非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)

3、分区容错性 partition tolerance

The system will continue to function when network partitions occur.

当出现网络分区后,系统能够继续履行职责

三、 要点解析

1、cap的适用场景是副本性的数据,订单数据和库存数据状态不一致不属于cap讨论的范畴

2、P要求分布式和数据同步,C要求数据完全一致,A要求返回及时

3、cap中的一致性是线性一致性,指分布式节点中的数据读写一致性,

4、base理论是对CAP中AP方案的一个补充

5、cp系统发生分区时不是完全的不可用,是主分区仍然可用

四、实战应用

1、cap关注的粒度是数据,而不是整个系统

用户账号数据选择cp,而用户信息数据选择ap

2、cap是忽略网络延迟的

单个用户的余额、单个商品的库存,理论上要求选择 CP 而实际上 CP 都做不到,只能选择 CA。也就是说,只能单点写入,其他节点做备份,无法做到分布式情况下多点写入。

3、正常运行情况下,不存在cp和ap的选择,可以同时满足ca

4、放弃并不等于什么都不做,需要为分区恢复后做准备

cp分区恢复后把数据同步到故障节点,达到同时满足CA状态

ap分区恢复后进行数据合并,达到同时满足CA状态

五、经典理解

设计分布式系统的两大初衷:横向扩展(scalability)和高可用性(availability)。“横向扩展”是为了解决单点瓶颈问题,进而保证高并发量下的「可用性」;“高可用性”是为了解决单点故障(SPOF)问题,进而保证部分节点故障时的「可用性」。由此可以看出,分布式系统的核心诉求就是「可用性」。这个「可用性」正是 CAP 中的 A:用户访问系统时,可以在合理的时间内得到合理的响应。

为了保证「可用性」,一个分布式系统通常由多个节点组成。这些节点各自维护一份数据,但是不管用户访问到哪个节点,原则上都应该读取到相同的数据。为了达到这个效果,一个节点收到写入请求更新自己的数据后,必须将数据同步到其他节点,以保证各个节点的数据「一致性」。这个「一致性」正是 CAP 中的 C:用户访问系统时,可以读取到最近写入的数据。

需要注意的是:CAP 并没有考虑数据同步的耗时,所以现实中的分布式系统,理论上无法保证任何时刻的绝对「一致性」;不同业务系统对上述耗时的敏感度不同。

分布式系统中,节点之间的数据同步是基于网络的。由于网络本身固有的不可靠属性,极端情况下会出现网络不可用的情况,进而将网络两端的节点孤立开来,这就是所谓的“网络分区”现象。“网络分区”理论上是无法避免的,虽然实际发生的概率较低、时长较短。没有发生“网络分区”时,系统可以做到同时保证「一致性」和「可用性」。

发生“网络分区”时,系统中多个节点的数据一定是不一致的,但是可以选择对用户表现出「一致性」,代价是牺牲「可用性」:将未能同步得到新数据的部分节点置为“不可用状态”,访问到这些节点的用户显然感知到系统是不可用的。发生“网络分区”时,系统也可以选择「可用性」,此时系统中各个节点都是可用的,只是返回给用户的数据是不一致的。这里的选择,就是 CAP 中的 P。

分布式系统理论上一定会存在 P,所以理论上只能做到 CP 或 AP。如果套用 CAP 中离散的 C/A/P 的概念,理论上没有 P 的只可能是单点(子)系统,所以理论上可以做到 CA。但是单点(子)系统并不是分布式系统,所以其实并不在 CAP 理论的描述范围内。

参考:李运华的从0开始学架构

近期文章:

如何开始架构设计

高性能架构模式

微服务架构————基本组件

微服务实战问题

微服务架构进阶

秒杀系统设计

分布式数据一致性理解

5种分布式锁实现的对比?

Java并发编程学习体系

java8 Stream 史上最全总结

Java 网络编程"初探"

redis 知识点总结

java 核心技术学习总结 (一)

spring中"投机取巧"地限制 用户同时登陆

如果你喜欢本文

请长按二维码,关注 乔志勇笔记

到底如何理解CAP


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

有的放矢

有的放矢

Nathan Furr、Paul Ahlstrom / 七印部落 / 华中科技大学出版社 / 2014-4-20 / 38.00元

创业需要大笔资金吗?自信的人适合创业吗?好点子究竟来自哪里?《有的放矢:NISI创业指南》的两位作者拥有多年创业与投资经验,收集了大量的一手案例和资料,提出有的放矢创业流程,帮助创业者规避创业风险,提高创业成功率。一起来看看 《有的放矢》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具