写点什么

简述 CAP 定理

用户头像
escray
关注
发布于: 2020 年 11 月 01 日
简述 CAP 定理

CAP 定理(CAP theorem)又被称作布鲁尔定理(Brewer's theorem),是加州大学伯克利分校的计算机科学家埃里克·布鲁尔(Eric Brewer)在 2000 年的 ACM PODC 上提出的一个猜想。2002 年,麻省理工学院的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了布鲁尔猜想的证明,使之成为分布式计算领域公认的一个定理。


CAP theorem (Brewer's theorem, 2000 ACM PODC)


Consistency: Every read receives the most recent write or an error

Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write

Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.


CAP 原理


  • 一致性

  • 可用性

  • 分区耐受性


老师给出的是维基百科上的定义,极客时间《从零开始学架构》中,提到了 Rober Greiner 的阐述 http://robertgreiner.com/2014/08/cap-theorem-revisited/


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.


其中强调了 interconnected 和 share data,分布式系统并不一定会互联和共享数据,比如 Memcached 集群,share nothing,不符合 CAP 理论探讨的范围;而 MySQL 集群是互联和数据复制的,属于 CAP 探讨的对象。


其次,强调了 write/read pair,也就是说 CAP 关注读写操作,而不是其他功能,比如 ZooKeeper 的选举机制,就不是 CAP 的探讨范围。


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


对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。从客户端角度描述,read,从读写角度来描述一致性


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


非故障节点在合理的时间内返回合理的相应(不是错误和超时的相应)。只有非故障节点才能满足可用性要求,并且明确不能超时、不能出错,结果不一定“正确”,但是合理。


Partition Tolerance: The system will continue to function when network partitions occur.


当出现网络分区后,系统能够继续“履行职责”。function 强调履行职责,即可用性;另外只要出现 network partitions 分区现象,不管什么原因,可能是丢包,也可能是连接中断,还可能是拥塞……


对一个分布式系统而言,网络失效一定会发生,也就是说,分区耐受性是必须要保证的,那么在可用性和一致性上就必须二选一。


在分布式系统必须要满足分区耐受性的前提下,可用性和一致性无法同时满足。


分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构。


CAP 定理的使用场景是同构副本性(主从、多主)类型的架构,其中一致性是指顺序一致性、读写一致性。


HBase、MongoDB、ZooKeeper 属于 CP 架构,Cassandra、CounchDB 属于 AP 系统


zk 多数节点正常就可以正常运行,分区中的少数节点会进入 leader 选举状态,这个状态不能处理读写操作,因此不符合 A,如果不考虑实时一致性,zk 基本满足 CP 的要求


CAP 关注的粒度是数据,而不是系统。在实际设计过程中,每个系统不可能只处理一种数据,而是包含多种类型的数据,有的数据必须选 CP,有的数据必须选 AP。比如用户管理系统中,用户账号数据(用户 ID、密码) CP,而用户信息数据(昵称、兴趣、爱好、性别、自我介绍) AP


CAP 是忽略网络延迟的。CAP 理论中的 C 在实践中是不可能完美实现的,在数据复制的过程中,节点 A 和节点 B 的数据并不一致。


如果节点间的网络连接一切正常,也就是 P 不存在的情况下,没有必要放弃 C 或者 A,可以同时满足 CA


放弃不等于什么都不做,CAP 理论的牺牲 sacrificed 只是说在分区过程中。在系统整个运行周期中,大部分时间都是正常的,99.99% 的可用性,一年不可用的时间只有 50 分钟,5 个 9 的可用性系统,一年下来不可用的时间只有 5 分钟。分区期间放弃 C 或者 A,并不意味着永远放弃 C 和 A,可以在分区期间进行一些操作(比如记录日志),当分区故障解决之后,系统重新达到 CA 状态。



发布于: 2020 年 11 月 01 日阅读数: 51
用户头像

escray

关注

Let's Go 2017.11.19 加入

在学 Elasticsearch 的项目经理

评论

发布
暂无评论
简述 CAP 定理