分布式系统中一致性问题

区块链系统,首先是一个分布式系统,一致性问题是分布式领域最为基础也是最重要的问题。

1、定义

一致性( consistency ),是指对于分布式系统中的多个服务节点,给定一系列操作,在约定协议的保障下,试图使得它们对处理结果达成“某种程度”的认同

分布式计算机集群系统中容易出现以下几个问题:

  1. 节点之间的网络通信是不可靠的,包括消息延迟、乱序和内容错误等;
  2. 节点的处理时间无法保障,结果可能出现错误,甚至节点自身可能发生宕机
  3. 同步调用可以简化设计,但会严重降低分布式系统的可扩展性,甚至使其退化为单点系统。

2、绝对理想的一致性

分布式系统要达到绝对理想的一致性应该满足:

(1)可终止性( termination ):一致的结果在有限时间内能完成;

有限时间内完成,意味着可以保障提供服务( liveness ) 。这是计算机系统可以被正常使用的前提。需要注意,在现实生活中这点并不是总能得到保障的。例如取款机有时候会出现“服务中断”;拨打电话有时候是“无法连接”的2

(2)约同性( agreement ):不同节点最终完成决策的结果是相同的;

决策的结果相同,意味着算法要么不给出结果,任何给出的结果必定是达成了共识的,即安全性( safety ) 。对于两个来自不同位置的请求来说,要判断在时间上的“先后”关系并不是那么容易。两个位置的时钟可能是不一致的;也可能无法记录下足够精确的时间。

可见,事件发生的先后顺序十分重要,这也是解决分布式系统领域很多问题的核心秘诀:把多件事情进行排序,而且这个顺序还得是大家都认可的。

(3)合法性( validity ):决策的结果必须是某个节点提出的提案;

达成的结果必须是节点执行操作的结果。仍以卖票为例,如果两个售票处分别决策某张票出售给张三和李囚,那么最终达成一致的结果要么是张三,要么是李囚,而绝对不能是其他人。

3、带约束的一致性

要实现绝对理想的严格一致性( strict consistency )代价很大。除非系统不发生任何故障,而且所有节点之间的通信无需任何时间,这个时候整个系统其实就等价于一台机器了。实际上,越强的一致性要求往往会造成越弱的处理性能,以及越差的可扩展性

强一致性包括两类:

(1)顺序一致性(sequential consistency):保证所有进程看到的全局执行顺序一致

并且每个进程看自身的执行顺序跟实际发生顺序一致。例如,某进程先执行A ,后执行B ,则实际得到的全局结果中就应该为A 在B 前面,而不能反过来。同时所有其他进程在全局上也应该看到这个顺序。顺序一致性实际上限制了各进程内指令的偏序关系,但不在进程间按照物理时间进行全局排序;

(2)线性一致性(linearizability consistency):在顺序一致性前提下加强了进程间的操作排序,形成唯一的全局顺序(系统等价于是顺序执行,所有进程看到的所有操作的序列顺序都一致,并且跟实际发生顺序一致),是很强的原子性保证。但是比较难实现,目前基本上要么依赖于全局的时钟或锁,要么通过一些复杂算法实现,性能往往不高。

由于强一致性的系统往往比较难实现,而且很多时候,实际需求并没有那么严格需要强一致性。因此,可以适当地放宽对一致性的要求,从而降低系统实现的难度。例如在一定约束下实现所谓最终一致性,即总会存在一个时刻(而不是立刻),让系统达到一致的状态。大部分Web 系统实现的都是最终一致性。相对强一致性,这一类在某些方面弱化的一致性都笼统称为弱一致性。

 

 

一致性往往指分布式系统中多个副本对外呈现的数据的状态。如前面提到的顺序一致性、线性一致性,描述了多个节点对数据状态的维护能力。

共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。

因此,一致性描述的是结果状态,共识则是一种手段达成某种共识并不意味着就保障了一致性

实践中,要保障系统满足不同程度的一致性,核心过程往往需要通过共识算法来达成

猜你喜欢

转载自blog.csdn.net/Black_BearB/article/details/83213416