浅析分布式系统中的 Linearizability-阿里云开发者社区

开发者社区> 阿里云Serverless Compute> 正文
登录阅读全文

浅析分布式系统中的 Linearizability

简介:

在分布式系统里,出于可靠性(reliability)或者性能的考虑,数据通常会被复制为多个副本。因此,系统需要定义一组协议,来规定用户读写多副本时的行为。这组协议称之为 consistency model
最终一致性(eventually consistency),linearizability(atomic consistency)是不同类型的一致性模型。下图是最终一致性模型的示例,用户 B/C 在读取不同的副本时看到了不同的 x 的值。请注意,用户A,B,C的操作是完全串行执行的,即操作在时间轴上没有重叠。C 读取操作发生在 B 之后,却读到了过期的值。可见,最终一致性是一个较弱的一致性模型,用户需要自己解决读取到过期数据的问题。

eventually_consistency

接下来,让我们看看一个中间状态的一致性模型,它比最终一致性强,但是比 linearizability 弱。从时间轴上可以看到,B0 发生在 A0 之前,读取到的 x 值为0。B2 发生在 A0 之后,读取到的 x 值为1。而读操作 B1,C0,C1 与写操作 A0 在时间轴上有重叠,因此他们可能读取到旧的值0,也可能读取到新的值1。注意,C1 发生在 B1 之后(二者在时间轴上没有重叠),但是 B1 看到 x 的新值,C1 反而看到的是旧值。即对用户来说,x 的值发生了回跳。

casual_consistency

Linearizability,则提供了更强的一致性保证。注意下图中的 C1 和 B1 操作,C1 发生在 B1 之后,但是与 A0 并行。在 Linearizable 系统中,如果 B1 看到的 x 值为1,则 C1 看到的值也一定为1。而在前两种一致性模型中,同样的场景,C1 看到的 x 值既可能是0,也可能是1。在 Linearizable 的系统中,任何操作在该系统生效的时刻都对应时间轴上的一个点。如果我们把这些时刻连接起来,如下图中紫线所示,则这条线会一直沿时间轴向前,不会反向回跳。所以,在 Linearizable 系统中,任何操作都可以互相比较决定谁发生在前,谁发生在后。例如 B1 发生在 A0 前,C1 发生在 A0 后。而在前面较弱的一致性模型中,我们无法比较诸如 B1 和 A0 的先后关系。对这个性质更正式的表述是:在 Linearizable 系统中,我们可以获得操作的全序(total order)。而在提供较弱一致性的系统中,我们只能获得操作的偏序(partial order)。

linearizability

注意:

由于网络延时以及系统本身执行请求的不确定性,请求发起得早不意味着在服务端被执行得早。例如 A0 比 B1 在客户端发起得早,但 A0 在存储系统生效晚于 B1。反之,在服务端被执行得早的请求也有可能很晚客户端才收到结果,例如 C0。

需要 Linearizability 语义的一个典型场景是实现分布式锁。例如当一个锁被 client A获取后,则希望后续看到该锁的状态都是被A locked,而不是其他状态。

附录

A. Linearizability 与 Serializability 的差别

关于二者的差别,可以参考这一篇文章

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云Serverless Compute
使用钉钉扫一扫加入圈子
+ 订阅

Serverless微服务应用实践分享

官方博客
函数计算官网