正确理解CAP定理

简介

定义

原文: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.

翻译:在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。

关键字:interconnected nodes(互连节点)、share data(共享数据)、a write/read pair(读/写)

简单描述下,从上面一段话,有几个,也就是说我们聊CAP定理的时候,是在具有数据读写、数据共享和节点互连的前提下,对上面三者选其二,也是建议我们不要花费时间与精力同时满足三者。

举例说明,web集群、memcached集群、redis哨兵不属于讨论对象

  • web集群只是资源复制分配在不同的节点上,然而节点间没有互连、也没有数据共享(sessionid、memory cache)。
  • memcached集群数据存储是通过客户端实现哈希一致性,但是集群节点间不互连的,也没有数据共享。
  • redis哨兵是为了Redis提供了高可用性,进行监控、通知、故障转移等,但没有数据读写操作。

总得来说,CAP定理讨论的并不是分布式系统所有的功能。

一致性(Consistency)

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

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

关键字:a given client(指定的客户端)。

简单描述下,这里没说明是所有节点必须在同一时间数据一致,而关注点在客户端,假如有个场景,您在ATM(客户端)往某张银行卡存500元后,立刻在ATM发起查询余额的时候会显示加了500元后的余额,随后我们也能把这500元取出来。查询余额读操作可以是写后立刻读的主库,也或者写后某个时间段过后(中途无写)读从库。

可用性(Availability)

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

翻译:非故障节点将在合理的时间内返回合理的响应(不是错误或超时)。

关键字:non-failing node(非故障节点)、reasonable response(合理的响应)

简单描述下,这里的可用性和我们平常所理解的高可用性有点偏差,高可用性指系统无中断的执行其功能的能力。

已故障的节点就不具有可用性了,因为请求结果要么error要么 timeout。合理的响应没有说明是成功还是失败,但是响应应该具有是否成功的精确描述。例如我们读取sql server集群的某从库,同步需要时间,读取出来可能不是最新的数据,但却是合理的响应。

分区容错性(Partition tolerance)

原文:The system will continue to function when network partitions occur.

翻译:当网络分区发生时,系统将继续正常运作

关键字:continue to function(继续正常运作)

描述:假如做了一个redis的一主两从的集群,某天某个从节点因为网络故障变成不可用,但是另外的一主一从仍然能正常运作,那么我们认为它具有分区容错性。

CA-牺牲分区容错性

作为分布式系统,我认为CAP的讨论是建立在P确立前提下。假如我们牺牲了P这个时候因为网络故障发生了分区导致节点不可用,这个时候请求响应了error,与可用性的定义相冲突了。因为分区总会发生,因此对于分布式系统而言分区容错性是必要的。

PC-牺牲可用性

最典型的案例是RDBMS集群与Redis集群,这两种都是利用主从复制实现读写分离的方案。假如两者都是建立一主多从的集群,在主节点写入数据,为了保证随后的读操作获取最新数据(一致性),这个读操作仍会请求主节点(读写分离的复杂点在从库同步不及时导致业务的异常,为了保证业务的正常性写后的读会请求主库),某个从节点挂了但是只要主节点和其他从节点仍然正常运作,就满足分区容错性。但是哪天主节点因为网络故障导致写操作的error或者timeout,那么这个系统就不可用了(牺牲可用性)。

这个时候可以引入其他功能和机制完成,例如Redis哨兵、故障转移功能。

PA-牺牲一致性

最典型的案例是Cassanda和Riak,这种类型的分布式数据库,可以任意节点写入,任意节点读取,当作为集群出现,无论写入哪个节点,都将会把该节点的数据同步到其他节点上。因为每个节点都可以写入同时会复制到其他节点,读取数据时只要访问一个节点就足够了(喜欢任意访问也不拦着你),但是因为其他节点数据同步原因,数据可能并不是最新的(牺牲一致性)。如果当前节点因为网络异常导致分区变得不可用(无论读\写),可以转移访问节点(可用性)。

原文地址:https://www.cnblogs.com/skychen1218/p/9194065.html

时间: 2024-08-08 20:13:05

正确理解CAP定理的相关文章

谈谈对CAP定理的理解

谈谈对CAP定理的理解 CAP定理的常规解释是任何分布式系统只能在一致性(Consitency),可用性(Availability)和分区容忍性(Partition Tolerance)中三选二.这个解释很让人费解,笔者在看了一些文章后谈谈我对它的理解,还请斧正. 从问题出发 假设我们用一台服务器A对外提供存储服务,为了避免这台服务器宕机导致服务不可用,我们又在另外一台服务器B上运行了同样的存储服务.每次用户在往服务器A写入数据的时候,A都往服务器B上写一份,然后再返回客户端.一切都运行得很好,

关于CAP定理的简单理解

CAP定理简介 在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点: 一致性(Consistency):同一个数据在集群中的所有节点,同一时刻是否都是同样的值. 可用性(Availability):集群中一部分节点故障后,集群整体是否还能处理客户端的更新请求. 分区容忍性(Partition tolerance):是否允许数据的分区,分区的意思是指是否允许集群中的节点之间无法通

佳文分享:CAP定理

1976年6月4号,周5,在远离音乐会大厅的一个楼上的房间内,在位于Manchester的Lesser Free Trade Hall ,Sex Pistols 乐队(注:Sex Pistols的经理人Malcolm McLaren 2010.4.8去世)開始了他们的第一次演出(gig, 注:规模太小称不上演唱会 ).关于当晚谁出席了那场演出有些混乱,部分是由于6周后的还有一场音乐会,但最基本的还是由于,这场演出被觉得是永久改变西方音乐文化 的一场演出.这场演出是如此的重要且富有象征意义,以至于

CAP定理(原则)以及BASE理论

CAP定理(原则)以及BASE理论 CAP定理(原则)概念 CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),三者不可得兼. 1. 数据一致性(consistency) 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) 2. 服务可用性(availability) 可用性(A):在集群中一部分节点故障后,集

再次理解CAP

此文图和结构基本剽窃自infoq的一篇文章,还有wikipedia.文字倒是基本是自己的思路 从单机RDMS到分布式数据库 从前...大家都在使用单机,单节点的数据库.例如:sql server, mysql , oracle... 我们如果想要提升整体性能,我们必须纵向提高单节点的能力.这虽然简单,但是很贵,而且很容易就会抵达上限. 后来...大家想出了各种办法:主从复制, 分表,分库,sharding 一种选择(可用还是一致?) 原本数据库都是单节点,不存在一致性的问题.当进入分布式的世界后

CAP定理

from wikipedia CAP定理 CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点: 一致性(Consistency) 可用性(Availability) 容忍网络分区(Partition tolerance) 根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项. 理解CAP理论的最简单方式是想象两个节点分处分区两侧.允许至少一个节点更新状态会导致数据不一致,即丧失了C性质.如

「系统架构」CAP 定理的含义

分布式系统(distributed system)正变得越来越重要,大型网站几乎都是分布式的. 分布式系统的最大难点,就是各个节点的状态如何同步.CAP 定理是这方面的基本定理,也是理解分布式系统的起点. 本文介绍该定理.它其实很好懂,而且是显而易见的.下面的内容主要参考了 Michael Whittaker 的https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/ 分布式系统的三个指标1998年,加州

CAP 定理的含义

分布式系统(distributed system)正变得越来越重要,大型网站几乎都是分布式的. 分布式系统的最大难点,就是各个节点的状态如何同步.CAP 定理是这方面的基本定理,也是理解分布式系统的起点. 本文介绍该定理.它其实很好懂,而且是显而易见的.下面的内容主要参考了 Michael Whittaker 的文章. 一.分布式系统的三个指标 1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标. Consistency Availability Partit

浅谈分布式CAP定理

互联网发展到现在,由于数据量大.操作并发高等问题,大部分网站项目都采用分布式的架构.而分布式系统最大的特点数据分散,在不同网络节点在某些时刻(数据未同步完,数据丢失),数据会不一致. 在2000年,Eric Brewer教授在PODC的研讨会上提出了一个猜想:一致性.可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个! 在2002年,Lynch证明其猜想,上升为定理.被这就是大家所认知的CAP定理. CAP是所有分布式数据库的设计标准.例如Zookeeper.Redis