CAP 理论与BASE理论

CAP

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、
Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本,,一致性是指数据在多个副本之间是否能够保持一致的特性。
可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性,可用性是指系统提供的服务必须一致处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内,返回结果。
分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择,分布式系统在遇到任何网络分区故障的时候,仍然需要对外提供满足一致性和可用性的服务。

CAP原则的精髓就是要么AP,要么CP,要么AC,但是不存在CAP。如果在某个分布式系统中数据无副本, 那么系统必然满足强一致性条件,
因为只有独一数据,不会出现数据不一致的情况,此时C和P两要素具备,但是如果系统发生了网络分区状况或者宕机,必然导致某些数据不可以访问,此时可用性条件就不能被满足,即在此情况下获得了CP系统,但是CAP不可同时满足
[1] 。
因此在进行分布式架构设计时,必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能,通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似
memcached 之类的 NOSQL 作为实现手段。虽然 memcached
也可以是分布式集群环境的,但是对于一份数据来说,它总是存储在某一台 memcached
服务器上。如果发生网络故障或是服务器死机,则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的,重启服务器,将导致数据全部丢失。当然也可以自己实现一套机制,用来在分布式
memcached 之间进行数据的同步和持久化,但是实现难度是非常大的。

①选择CA

放弃分区容错性,比较简单的方式就是把所有的数据都放在一个分布式节点上。那不就又成为了单机应用了吗?

②选择CP

放弃可用性,一旦出现网络故障,受到影响的服务需要再等待一定时间,因为系统处于不可用的状态。

③选择AP

放弃一致性,这里所指的一致性是强一致性,但是确保最终一致性。是很多分布式系统的选择。

小结:从cap的定理可以看出,分区容错性是一个最基本的要求,因为既然是一个分布式系统,必然要部署到两个或两个以上的节点上,否则,就不是分布式系统,因此我们只能在一致性和可用性寻求平衡。

BASE

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually
consistent (最终一致性)三个短语的缩写,是对 CAP 中 AP 的一个扩展。

基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。

注意,这绝不等价于系统不可用,以下两个就是“基本可用”的典型例子:
响应时间上的损失:正常情况下,一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果,但由于出现异常(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加到了1~2秒。
功能上的损失:正常情况下,在一个电子商务网站上进行购物,消费者几乎能够顺利地完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。
弱状态:也称为软状态,和硬状态相对,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性:强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值