当前位置: 首页 > 资讯 > > 内容页

环球热议:必知必会的分布式理论

发布时间:2023-03-30 13:30:12 来源:腾讯云

ACID

Atomicity(原子性)

是指一个事务要么全部执行,要么不执行,也就是说一个事务不可能只执行了一半就停止了。比如你从取款机取钱,这个事务可以分成两个步骤:1划卡,2出钱。不可能划了卡,而钱却没出来。这两步必须同时完成,要么就不完成。

Consistency(一致性)

是指事务的运行并不改变数据库中数据的一致性。例如,完整性约束了a+b=10,一个事务改变了a,那么b也应该随之改变。


(资料图)

Isolation(隔离性)

事务的独立性也有称作隔离性,是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。

事务的隔离性是指在并发环境中,并发的事务时相互隔离的,一个事务的执行不能不被其他事务干扰。不同的事务并发操作相同的数据时,每个事务都有各自完成的数据空间,即一个事务内部的操作及使用的数据对其他并发事务时隔离的,并发执行的各个事务之间不能相互干扰。

Durability(持久性)

事务的持久性是指事务执行成功以后,该事务对数据库所作的更改便是持久的保存在数据库之中,不会无缘无故的回滚。

BASE

Basically Available(基本可用)

基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

Soft State(软状态)

软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

Eventual Consistency(最终一致性)

最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

BASE模型是传统ACID模型的反面,不同与ACID,BASE强调牺牲高一致性,从而获得可用性,数据允许在一段时间内的不一致,只要保证最终一致就可以了。

CAP

一个分布式系统最多只能同时满足

Consistency(一致性)

指在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)

Availability(可用性)

在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)

Partition tolerance(分区容错性)

即当节点之间无法正常通信时,就产生了分区,而分区产生后,依然能够保证服务可用,那么我们就说系统是分区容忍的。显然如果节点越多,且备份越多,分区容忍度就越高(因为即便是其中一个或多个节点挂了,仍然有其它节点和备份可用)。

这三项中的两项。

那么,为什么说三个特性无法全部保证呢?首先,假如我们要保证分区容忍性,必然要做多个副本节点,而这必然会带来一致性的问题,即保证多个节点的数据是相同的,但是,要让多个节点数据相同,就必须要花时间去复制数据,这还是能够正常通信的情况下,那么在数据复制的过程中为了保持一致性,就不能对外提供服务,所以这段时间就无法满足可用性的问题。

实际工程通常会采取一些折中措施,比如并不保证强一致性,只保证最终一致性,什么意思呢?比如,有三个数据节点互为备份,某份数据在节点A更改后,需要将更改复制到节点B和C,假设复制过程中,有客户访问该数据,那么此时不保证是一致的,即访问A节点的用户得到的是最新数据,而访问B和C节点的用户得到是老数据,但是最终,数据会复制完成,所以最终A、B、C三个节点的数据是一致的。(比如像文章点赞这种数据,延迟下也没有关系啦)

TCC

try-尝试执行业务

完成所有业务检查(一致性)

预留必须业务资源(准隔离性)

confirm-确认执行业务

真正执行业务

不作任何业务检查

只使用Try阶段预留的业务资源

Confirm操作必须保证幂等性

cancel-取消执行业务

释放Try阶段预留的业务资源

Cancel操作必须保证幂等性

TCC事务其实主要包含两个阶段:Try阶段、Confirm/Cancel阶段。

从TCC的逻辑模型上我们可以看到,TCC的核心思想是,try阶段检查并预留资源,确保在confirm阶段有资源可用,这样可以最大程度的确保confirm阶段能够执行成功。

推荐阅读