最终一致性/BASE VS ACID

最终一致性/BASE VS ACID

六月 22nd, 2010 · No Comments · 存储&NoSQL

作者: 阎斌 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息
网址: http://UltimateArchitecture.net

学过数据库的人都会知道，ACID是关系型数据库的最基本原则。但是在遵守ACID原则规定的强一致性的同时，会对性能造成很大的影响。

对于大多数的互联网应用来讲，强一致性并不是非常重要的。和一致性比起来，可用性更加重要性一些。最终一致性简单的讲就是在某一个短暂的时间内数据可以不一致，但是在无限长的时间内，所有节点上的replica最终会达到完全一致。

BASE 策略是Eric A. Brewer 在 1988 年提出的。和ACID完全不同，BASE的基本思想就是牺牲强一致性，以便获得可用性或可靠性。BASE的全称是Basically Available、Soft state、和Eventually consistent

• 基本可用Basically Available

和完全可用的区别是：在分布式系统部分损坏的时候，允许部分内容不可用，但是其他部分仍旧可用。因此称这种系统为“基本可用”。比如，一个数据存储系统由五个节点构成。其中一个发生了损坏，这个时候，只有20%的数据不能访问，其他80%数据仍旧可用。那么就可以称这种系统为基本可用的。

• 软状态Soft state

关于Soft state的解释有很多，唯一可以肯定的是Soft State和Hard State是相对的两个概念。在Fenng的一篇Blog（BASE — 高可用架构的基石之一）中，作者将Soft State翻译为“无连接的”，有点难以理解。

个人认为，Soft state可以和Hard State和Stateless对比着去理解。Stateless是指无状态。在分布式系统中，如果每一个Server都是无状态的，那么这个系统的可靠性是非常高的。因为即使坏了任何一个server，都不会影响到整体的运行情况。如果一个Server是Hard State的。那么，这个系统保留了所有客户端发过来的状态，系统整体的某些状态会因为某一台保存了状态的服务器挂掉而丢失。系统是非常不可靠的。

在很多资料中都写到，Soft State只会保留客户端的状态一段时间，在这段时间过后，如果客户端没有再次发送刷新状态的请求时，这个状态就会消失。

这个概念最先来自于计算机网络领域。最近被应用于服务器的设计。

• 最终一致性 Eventually consistent

最终一致性相对于其他两个概念而言还是比较好解释的。除了最终一致性，强一致性之外，还有一个弱一致性。简单的说，一致性的不同类型主要是区分在高并发的数据访问操作下，后续操作是否能够获取最新的数据。不同的策略决定了不同的一致性类型。

当一次更新操作之后，后续的读操作如果全部保证是更新后的数据，那么就是强一致性。如果不能保证后续访问读到的都是更新后的，那么就是弱一致性。最终一致性是弱一致性的一种特例。最终一致性规定，后续的访问操作可以暂时不返回更新后的数据，但是经过一段时间之后，必须返回更新后的数据。也就是最终保持一致。

最终一致性还有很多变体，比如Casual Consistency、Session Consistency、Read-your-writes Consistency等。这里不做重点讨论。请自行Google一下。

对CAP和最终一致性有兴趣的读者可以继续阅读：

Werner Vogels的“Eventually Consistent – Revisited”

（http://www.allthingsdistributed.com/2008/12/eventually_consistent.html）

CAP原理与最终一致性

（http://www.ningoo.net/html/2010/cap_theorem_and_eventually_consistent.html）

对Soft State有兴趣的可以阅读：

[PAPER]Cluster-Based Scalable Network Services

http://webee.technion.ac.il/labs/comnet/netcourse/CIE/RFC/2205/9.htm