分布式系统, 转载

ACID, BASE和CAP(zz)

2010年12月20日 阅读(426)

云计算平台是非常巨大的分布式系统,需要处理庞大的处理请求,因此任何小概率事件在此平台中都必然发生。

DBMS强调ACID:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性 (Durability)。其中的一致性强调当程序员定义的事务完成时,数据库处于一致的状态,如对于转帐来说,事务完成时必须是A少了多少钱B就多了多少钱。而对于很多互联网应用来说,对于一致性和隔离性的要求可以降低,而可用性(Availability)的要求则更为明显。从而产生了两种弱一致性的理论:BASE和CAP。

BASE:Basically Availble –基本可用;Soft-state –;Eventual Consistency –最终一致性

CAP: Consistency 一致性;Availability 可用性; Tolerance of network Partition 分区容忍性(可理解为部分节点故障或节点之间连接故障下系统仍可正常工作)。Brewer提出的该经验理论认为这三个目标最多只能达成两个,而另一个则需要通过其他方式来弥补。

如果网络中不存在分区,客户端和存储系统在同一环境中,通过分布式事务机制可以保证一致性和可用性。但在大型网络系统中,分区是必然存在的,因此一般的选择只能是在一致性和可用性之间权衡和折衷。如Ebay的经验尽可能保证可用性,但采用周密调整数据库操作的次序、异步恢复事件,以及数据核对(reconciliation)或者集中决算(settlement batches)等方式来帮助系统达到最终一致性。

实际互联网系统往往都是ACID和BASE两种系统的结合,例如用户身份数据、交易数据通常采取ACID准则。

Guy Pardon认为,CAP理论认为三者不能同时达到是假定CAP被满足是在at the same moment in time,如果放弃这个假定就可以得到三者都满足的方案。但是在我看来,其方案也只是在可用性和一致性之间的折衷而已。放弃了读写一致性,读到的可能只是 cache中的快照而不是最新值;通过在系统无分区时才执行写入队列来保证数据更新一致性,而结果则是异步获得,相当于是对写入可用性要求的一种降低

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/wdwbw/archive/2009/05/13/4179749.aspx

分布式领域CAP理论,
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
关系数据库的ACID模型拥有 高一致性 + 可靠性 丧失可用性:
Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成。
Consistency一致性. 在事务开始或结束时,数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓。
Durability. 一旦事务完成,就不能返回。
跨数据库事务:2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,JavaEE中的JTA事务可以支持2PC。因为2PC是反模式,尽量不要使用2PC,使用BASE来回避。
BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性:
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步,异步。
Eventually consistent最终一致,最终数据是一致的就可以了,而不是时时高一致。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片
BASE思想主要强调基本的可用性,如果你需要High 可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。
现在NoSQL运动丰富了拓展了BASE思想,可按照具体情况定制特别方案,比如忽视一致性,获得高可用性等等,NOSQL应该有下面两个流派:
1. Key-Value存储,如Amaze Dynamo等,可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 (Qi4j和NoSQL运动),可根据CAP三原则结合自己项目定制灵活的分布式方案,难度高。
这两者共同点:都是关系数据库SQL以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度。
不同点:NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX,可以适合非Java如PHP RUBY等领域,是一种可以拿来就用的产品,而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的。

You Might Also Like