|
在讨论一致性之前,先看一下CAP理论。它作为一种理论依据,使得在不同应用中,对一致性也有了不同的要求。CAP理论:简单地说,就是对于一个分布式系统,一致性(Consistency)、可用性(Availablity)和分区容忍性(Partition tolerance)三个特点最多只能三选二。
|
|
|
一致性意味着系统在执行了某些操作后仍处在一个一致的状态,这点在分布式的系统中尤其明显。比如某用户在一处对共享的数据进行了修改,那么所有有权使用这些数据的用户都可以看到这一改变。简言之,就是所有的结点在同一时刻有相同的数据。
|
|
|
可用性指对数据的所有操作都应有成功的返回。高可用性则是在系统升级(软件或硬件)或在网络系统中的某些结点发生故障的时候,仍可以正常返回。简言之,就是任何请求不管成功或失败都有响应。
|
|
|
分区容忍性这一概念的前提是在网络发生故障的时候。在网络连接上,一些结点出现故障,使得原本连通的网络变成了一块一块的分区,若允许系统继续工作,那么就是分区可容忍的。
|
|
|
在数据库系统中,事务的ACID属性保证了数据库的一致性。比如银行系统中,转账就是一个事务,从原账户扣除金额,以及向目标账户添加金额,这两个数据库操作的总和构成一个完整的逻辑过程,具有原子的不可拆分特性,从而保证了整个系统中的总金额没有变化。
|
|
|
然而,这些ACID特性对于大型的分布式系统来说,是和高性能不兼容的。比如,你在网上书店买书,任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成(否则书本库存数可能不一致),买书完成的那一瞬间,世界上所有的人都可以看到书的库存减少了一本(这也意味着两个人不能同时买书)。这在小的网上书城也许可以运行得很好,可是对Amazon这种网上书城却并不是很好。
|
|
|
而对于Amazon这种系统,它也许会用Cache系统,剩余的库存数也许是几秒甚至几个小时前的快照,而不是实时的库存数,这就舍弃了一致性。并且,Amazon可能也舍弃了独立性,当只剩下最后一本书时,也许它会允许两个人同时下单,宁愿最后给那个下单成功却没货的人道歉,而不是整个系统性能的下降。
|
|
|
由于CAP理论的存在,为了提高性能,出现了ACID的一种变种BASE(这四个字母分别是Basically Available,Soft—state,Eventual consistency的开头字母,是一个弱一致性的理论,只要求最终一致性):
|
|
|
.Basically Available:基本可用。
|
|
|
.Soft state:软状态,可以理解为“无连接”的,而与之相对应的Hard state就是“面向连接”的。
|
|
|
.Eventual consistency:最终一致性,最终整个系统(时间和系统的要求有关)看到的数据是一致的。
|
|
|
在BASE中,强调可用性的同时,引入了最终一致性这个概念,不像ACID,其并不需要每个事务都是一致的,只需要整个系统经过一定时间后最终达到一致。比如Amazon的卖书系统,也许在卖的过程中,每个用户看到的库存数是不一样的,但最终卖完后,库存数都为0。再比如SNS网络中,C更新状态,A也许可以1分钟就看到,而B甚至5分钟后才看到,但最终大家都可以看到这个更新。
|
|
|
具体地说,如果选择了CP(一致性和分区容忍性),那么就要考虑ACID理论(传统关系型数据库的基石,事务的四个特点)。如果选择了AP(可用性和分区容忍性),那么就要考虑BASE系统。如果选择了CA(一致性和可用性),如Google的bigtable,那么在网络发生分区的时候,将不能进行完整的操作。
|
|
|
|
|
|