线性化与串行化比较

  线性化Linearizability和串行化(序列化)serializability都是数据库和分布式系统中重要的属性,它们两个容易搞混淆了,这篇文章就是给出一个简短的比较。

Linearizability: single-operation, single-object, real-time order
线性化:单个操作,单个对象,实时顺序

  线性化是在单个对象上面的单个操作保证,它提供基于单个对象(分布式register或数据条目)一系列单个操作(经常是读和写)的实时(如wall-clock挂钟)保证。

  在普通英语中,线性化的意思是,写好像应该是瞬间的,不严密的,一旦写完成,其后的所有其他读操作(这里的其后是由wall-clock开始时间定义的)应该返回写入的值或者最近写入的值,一旦读返回一个特定的值,所有其后读取应该返回的也是这个值或最近写入的值。

  对于读写操作的线性化是和词语“原子一致性atomic consistency”是同义词,也就是“C”,或者是Gilbert和Lynch的CAP理论中的 “consistency(一致性),”我们说线性化是可组合的或本地(local)的,是因为在系统中每个对象上的操作是线性的,那么这个系统所有操作就是线性的。

 

Serializability: multi-operation, multi-object, arbitrary total order
串行化:多个操作,多个对象,任意总顺序

  串行化是有关事务的保证,或者超过一个以上对象一个以上操作的综合(group),它保证基于多个条目的一系列事务(通常是读写操作)执行等同于事务的一些串行执行(总顺序)。

  串行化类似传统ACID中的“i”或isolation隔离,如果用户的事务每个保护应用正确性(这也是“C”,但是是ACID的C,代表一致性consistency),一个串行化执行也保护正确性,这样,串行化是一种保证数据库正确性的机制。

  不像线性化,串行化并不通过自身强加任何实时约束在事务的顺序上,串行化也不是可组合的,串行化并不意味着任何一种确定的顺序,它只是简单需要一些等价的串行执行存在。

 

Strict Serializability: Why don’t we have both?
严格串行化:为什么我们不能两个都拥有?

  串行化和线性化的结合也就是严格串行化,事务行为是等同于一些串行执行,串行的顺序符合实时,举例,说我开始和提交了事务T1,这个事务写入到条目x,然后后来你开始和提交了事务T2,这是从x中读取,数据库提供严格串行化将把T1放在T2之前以串行化顺序执行,T2会读取出T1的写入结果。数据库提供的串行化(但不是严格串行化)能将T2排序在T1之前。

  正如 Herlihy 和 Wing 所说:线性化能被看作是严格串行化的一个特殊情况,事务被限制成有对单个对象的单个操作组成。

 

Coordination costs and real-world deployments
协调损耗与实时部署

  如果没有协调,无论是线性化或串行化都无法实现,那就是说,我们在一个异步网络中不能提供一个可用性(CAP的“AP”)保证。

  在实践中,你的数据库并不可能提供串行化,你的多核处理并不可能提供线性化,至少默认情况是这样,作为上述理论的提示,实现这些特性需要大量昂贵的协调,所以,相反,实际系统中经常使用较低成本来和难于理解的模型实现,这种效率和可编程性的权衡是一个迷人和具有挑战的设计空间。

 

  其中原因之一是这些定义让人困惑,线性化是来自于分布式系统和并发编程社区,而串行化是来自于数据库社区,今天,几乎每个人都会使用分布式系统和数据库,经常导致一些overloaded过载的术语,比如一致性和原子性等。

  

原文:Linearizability versus Serializability

JDBC基础教程

分布式系统因果一致性与COPS算法

ACID中C与CAP定理中C的区别

CAP原理和BASE思想

苹果为什么收购FoundationDB?

使用Apache Samza对数据库进行彻底的"调教" 

分布式系统之CAP