随着2020年区块链分布式存储技术的完善和推进,近期去中心化存储网络DB及其子链DAAT的出现,或将改变区块链存储网络的未来。DB的一致性和可用性也正影响着区块链领域。

为了让DB的粉丝更容易明白DB的分布式存储系统,我们引出了一致性模型,这里我们由强到弱简单的介绍几种常见的一致性模型。

又称强一致性,可以看做只有一个单核处理器,或者可以看做只有一个数据副本,并且所有操作都是原子的。

如上图所示,对于事件e1和e2来说,如果事件e1的response是在事件e2的invoke之前,我们就说e1happenbeforee2。

对于同一个线程来说,前面的事件一定happenbefore后面的事件。但是对于不同线程上的两个事件来说,它们之间只有在在时间线上没有交叉的情况下,才会存在happenbefore关系。对于有交叉的那些事件,比如下图中的event2和event3,它们两个就不存在happenbefore关系,对于我们要寻找的合法顺序执行过程来说,它们两个的顺序可以是任意的。

顺序一致性弱于严格一致性。对变量的写操作不一定要在瞬间看到,但是,不同处理器对变量的写操作必须在所有处理器上以相同的顺序看到,这里处理器再分布式系统中可以换成不同的节点。

假设有两个线程A和B并发执行。其中A线程由3个操作构成,它们在程序中的顺序是:A1->A2->A3.B线程也有3个操作,它们在程序中的顺序是:B1->B2->B3.假设如果在顺序一致的模型中的效果就是如上两个图所示。

因果一致性是弱于顺序一致性的一致性模型,顺序一致性要求所有的操作的顺序都必须按照某个单个处理器(节点)的顺序,而因果一致性只需要满足有因果关系的操作是顺序一致性即可。

?

简单来说如果有人问你一个问题,那么你给出答案,这两个就是因果关系,但如果你给出答案再问题之前,那么这个就违反了因果关系。举个简单的例子如果节点1更新了数据A,节点2读取数据A,并更新数据B,这里的数据B有可能是根据数据A计算出来的,所有具备因果关系,但是如果节点3看到的是先更新的B,再更新的A那么就破坏了因果一致性。

其实除了强一致以外,其他的一致性都可以看作为最终一致性,只是根据一致性不同模型的不同要求又衍生出了很多具体一致性模型。当然最简单的最终一致性,是不需要关注中间变化的顺序,只需要保证在某个时间点一致即可。只是这个某个时间点需要根据不同的系统,不同业务再去衡量。再最终一致性完成之前,有可能返回任何的值,不会对这些值做任何顺序保证。

可用性指“Readsandwritesalwayssucceed”,即服务一直可用,而且是正常响应时间。对于一个可用性的分布式系统,每一个非故障的节点必须对每一个请求作出响应。所以,一般我们在衡量一个系统的可用性的时候,都是通过停机时间来计算的。

可用性分类

可用水平(%)

年可容忍停机时间

容错可用性

99.9999

<1min

极高可用性

99.999

<5min

具有故障自动恢复能力的可用性

99.99

<53min

高可用性

99.9

<8.8h

商品可用性

99

<43.8min

通常我们描述一个系统的可用性时,我们说淘宝的系统可用性可以达到5个9,意思就是说他的可用水平是99.999%,即全年停机时间不超过(1-0.99999)36524*60=5.256min,这是一个极高的要求。

好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统,上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等,任何一个节点的不稳定都可以影响可用性

2000年7月,加州大学伯克利分校的EricBrewer教授在ACMPODC会议上提出CAP猜想。2年后,麻省理工学院的SethGilbert和NancyLynch从理论上证明了CAP。之后,CAP理论正式成为分布式计算领域的公认定理。

CAP理论概述:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partitiontolerance)这三项中的两项。

?

需要特别指出的CAP中的一致性是allnodesseethesamedataatthesametime,也就是线性一致性。

DB分布式存储的一致性必须从两个维度看:

(1)从客户端角度,多进程并发访问时,非分布式数据库要求更新过的数据能被后续的访问都能看到,所有都是强一致的;

(2)从服务端角度,如何尽快将更新后的数据分布到整个系统,降低达到最终一致性的时间窗口,是提高系统的可用度和用户体验非常重要的方面。