Linearizability, Serializability and Strict Serializability

        通过知乎HW311博主的介绍，使我重新认识了对现实世界抽象建模的重要性，用数学上严格的定义和方法去解决抽象简化现实世界后得出的概念模型。在第一篇文章中，我解开了一个在我研究生复试复习过程中遇到的一个问题，关于 可串行性（Serializability） 的定义问题。在 东南大学数据库的课程中，徐立臻老师讲到可串行化的订定义就是看N个并发运行的事务同时提交给系统去运行的时候，系统对它们完全随机的调度，那么，按照系统产生的某种调度来运行的话，对数据库产生的最终结果与这N个事务的某一种串行执行序列的结果相同，那就称为可串行化。如果是可串行化的，那么就是正确的。 这里的正确性是在一定的语义范围内的。
        可串行性是关于事务并发时调度的问题，而这个问题源自于数据库最底层最关键的不可分割的原子操作（atomic operations）。至于如何解释和定义，请参考HW311的文章。

Serializability

知乎链接
        如何定义正确性是很重要的！而数据库的正确性实际上跟context有关。
        要了解事务并发正确性的根本，就要知道并发底层涉及的数据库最底层最关键的不可分割的原子操作（atomic operations）。事务是对数据库系统中读写操作的更高一层抽象，代表了“一个单位”的数据库操作。事务层面的不正确现象往往来自于最底层原子操作调度的不确定性。
        那我们只需要保证一个schedule是“等价于”某个serial schedule的就行了，这就是 serializability（可串行性/化） 的概念。那么问题又来了：对于两个schedule来说，什么叫做等价呢？这就是我们要讨论的关键问题了。
        接下来对serializability 三种解释请看原文。终态可串行（final state serializability）、视域可串行（view serializability）、冲突可串行（conflict serializability）
        如果一个schedule是conflict serializable的，它也一定是view serializable的，反之则不成立。所以conflict serializability实际上是牺牲了一部分的并发程度来使检验变得更容易。
        重新思考并发schedule造成inconsistency的原因，我们发现实际上关键仅仅在于某几个数据操作的顺序：在一个schedule中这些关键操作是这种顺序；在另一个schedule中可能是另一种顺序。这种顺序的区别导致了isolation的破坏和inconsistency。比如在我们最开始的银行转账的例子中，关键的 [公式] 和 [公式] 的执行顺序导致了 [公式] 读取了 [公式] 的partial effect. 如果我们确保在schedule [公式] 中，所有这样的关键操作的执行顺序都和某个serial schedule中这些操作的执行顺序相同，那么我们就可以保证consistency了。

Linearizability

知乎链接
        关于分布式系统当中的一致性模型，来看看杨皓然大佬的文章。
        一致性模型分为很多类型，按照一致性的强弱由低到高进行列举，最终一致性，中间状态的一致性模型，Linearizability
        在 Linearizable 系统中，我们可以获得操作的全序（total order）。而在提供较弱一致性的系统中，我们只能获得操作的偏序（partial order）。

Linearizability, Serializability and Strict Serializability

知乎链接
        事实上，Linearizability, Serializability这几个概念来自于不同领域，随着数据库和分布式的结合，自然这几个名词会经常一起出现。Strict Serializability也是数据库和分布式结合出现的概念。