CAP和BASE理论

CAP理论

CAP理论是分布式领域中非常重要的一个指导理论,是分布式系统的理论基石

Consistency(一致性)

“all nodes see the same data at the same time”,即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致,这就是分布式的一致性.一致性的问题在并发系统中不可避免

• 对于客户端来说:一致性指的是并发访问时更新过的数据如何获取的问题.
• 对于服务端来说:一致性指的是更新如何复制分布到整个系统,以保证数据最终一致

Availability(可用性)

“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间.好的可用性主要是指系统能够很好的为用户服务,不会出现用户操作失败或者访问超时等用户体验不好的情况

Partition Tolerance(分区容错性)

即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务.分区容错性要求能够使应用虽然是一个分布式系统,而看上去却好像是一个可以运转正常的整体.比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统需求,对于用户而言并没有什么体验上的影响

取舍策略

CAP三个特性只能满足其中两个,那么取舍的策略就共有三种:

• CA: 如果不要P(不允许分区),则C(强一致性)和A(可用性)是可以保证的.但放弃P的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点,这是违背分布式系统设计的初衷的.一个分布式系统是必须要保证分区容错性的,而在这个前提下要么保证CP,要么保证AP,无法同时保证CAP.
• CP: 如果不要求A(可用),相当于每个请求都需要在服务器之间保证强一致.而P(分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务).一旦发生网络故障或者消息丢失等情况.就要牺牲用户的体验,等到所有数据全部一致了之后再让用户访问系统
• AP: 要高可用并允许分区,则需要放弃一致性,一旦分区发生,节点之间可能会失去联系,为了高可用.每个节点只能用本地数据库提供服务,而这样会导致全局数据的不一致性

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写.BASE理论是对CAP中一致性和可用性权衡的结果.其来源对于大规模互联网系统分布式实践的总结.是基于CAP逐步演化来的.BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性

基本可用

基本可用是指分布式系统中出现不可预知故障的时候,允许损失部分可用性;这绝不等价于系统不可用

• 响应时间上的损失:正常情况下一个在线搜索引擎需要在0.5s内返回给用户相应的查询结果,但由于出现不可预知的故障,查询结果响应时间增加了1~2s
• 系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利的完成每一笔订单,但是在618/双十一等大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面

软状态

软状态指允许系统中数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程中存在延时

最终一致性

最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能达到一个一致的状态.因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性,总的来说,BASE理论面向的是大型高可用高扩展的分布式系统,和传统事务ACID特性是相反的,它完全不同于ACID的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态.但同时,在实际的分布式场景中,不同的业务单元和组件对数据的一致性要求是不同的,因此在具体的分布式系统架构设计过程中,ACID特性和BASE理论往往又会结合到一起

数据库中的一致性是强一致性,BASE理论中的一致性是弱一致性

强一致性VS最终一致性

强一致性

举个例子:张三给李四转账100元,事务要做的就是从张三账户减掉100给李四账户加上100.转账过程中可能存在的状态:

1. 张三未扣减;李四未收到(初始状态)
2. 张三已扣减;李四未收到(中间状态/软状态)
3. 张三已扣减;李四已收到(最终状态)

在强一致性中,1和3都是我们期待的状态;但2这个状态却不是我们期待出现的状态.
与原子性不同的是:原子性关注状态,要么全部成功,要么全部失败.不存在部分成功的状态.而一致性关注数据的可见性,中间状态的数据对外部不可见,只有最初状态和最终状态的数据对外可见

最终一致性

举个例子:支付宝转账到100银行卡,事务要做的是从你支付宝账户扣减100给银行卡增加100.转账过程中同样也是三种状态:

1. 支付宝已扣减;银行卡未收到(初始状态)
2. 支付宝已扣减;银行卡未收到(中间状态/软状态)
3. 支付宝已扣减;银行卡已收到(最终状态)

在最终一致性中,我们是允许中间状态对外可见的.我们每次进行转账的时候都是先扣除支付宝余额,但银行卡不会马上到账的.这种状态对外是可见的.只需要给一个提示就好,预计两小时内到账之类.这个时候数据是不一致的,钱扣除了但是没有马上到帐,但是给出了一个转账中的状态.过段时间银行卡收到转账后,还是能达到最终一致性.并且提高了可用性

一句话总结:在分布式系统中.想要同时满足CAP就是痴人说梦.BASE才是最终归宿