架构师 0 期 | 简述 CAP 原理

用户头像
刁架构
关注
发布于: 2020 年 07 月 15 日
架构师 0 期 | 简述CAP原理

CAP其实是个定理

这个定理起源于加州大学伯克利分校的埃里克布鲁尔在2000年的分布式计算机原理研讨会上提出的一个猜想。

2002年,麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明,使之成为一个定理

所以这个定理又称:布鲁尔定理。



CAP定理

它指出对于一个分布式计算系统来说,不可能同时满足以下3点:

  1. 一致性(Consistency)

  2. 可用性(Availability)

  3. 分区容错性(也叫 分区耐受性 Partition tolerance)



这个定理被认为是分布式系统领域的重要原理之一,深刻影响了分布式计算与系统设计的发展。

作为架构师必须明白,这个是无法同时满足的,系统设计的时候必须根据需求进行取舍权衡。

一致性

一致性是说,每次读取的数据都应该是最近写入的数据,或者是返回一个错误。

而不是过期的数据。

就是说,数据必须是一致的,要不就是返回一个错误,如果返回,就必须是正确的数据。

可用性

可用性是说,每次请求都应该得到一个响应。

这个返回可以不用保证是最近写入的。

但是不能返回一个错误,或者失去响应。

分区容错性

分区容错性是说,即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然是可操作的。

这个时候就需要在C和A之间二选一了。



总结CAP

当由于网络等原因导致分区失效发生时,

我们要不就取消操作,这样数据就一致了,但是系统是不可用的。

要不就继续写入数据,但是数据就不一致了。



对于一个分布式系统来说,网络失效时一定会发生的。

那么根据CAP原理,3点不能同时满足。

就得在可用性和一致性上二选一。



  1. 如果选择了一致性(取消操作),系统就可能会返回一个错误,或者超时。此时系统不可用。

  2. 如果选择可用性(继续写入),系统就会返回一个数据,但是可能不是最新的数据。



所以,更准确的说法是:在分布式系统必须要满足分区耐受性的前提下,可用性和一致性无法同时满足。



ACID(酸性)

首字母缩写,酸性,和下面的碱性对应。

数据库在写入数据的时候,为保证事务是正确可靠的。

必须具备4个特性:

  1. 原子性(atomicity)

  2. 一致性(consistency)

  3. 隔离性(isolation)

  4. 持久性(durability)



BASE(碱性)

根据CAP定理,无法同时满足3点。

所以为了维护ACID事务需要付出很大的成本来维护可用性。

所以为了保证可用性总结了一套弱化的事务特性,缩写为:碱性。

  1. 基本可用(Basically Available):系统能够基本运行、一直提供服务。

  2. 软状态(Soft-state):系统不要钱一直保持强一致状态。

  3. 最终一致性(Eventual consistency):系统需要在某一时刻后到达一致性要求。



最终一致性

既然无法同时满足,则允许短时间内系统数据不一致,但是最终我的数据是一致的。

当通信失败时,导致客户1和3更新了不一样的数据,当客户2和4查询时,获取的同一件商品价格不一致。

当网络恢复后,对变更进行异步扩散。

并根据更新时间戳,进行写入数据覆盖。则最终数据达到一致性。









客户端冲突解决

当有同一个用户,因为网络问题,发生了创建了2个购物车时。

异步扩散之后,获取到用户之后,根据id会对两个购物车进行合并保存。

达到数据最终一致性。





投票解决冲突

可以同时向3个节点读写,当至少有2个节点响应成功。

取最新的版本。

Cassandra 分布式解决方案



发布于: 2020 年 07 月 15 日 阅读数: 33
用户头像

刁架构

关注

叫我刁架构 2017.10.25 加入

预备备网红首席架构师,移动端开发者,边缘设计支持者。

评论

发布
暂无评论
架构师 0 期 | 简述CAP原理