分布式事务及CAP理论

事务

在聊分布式事务前,有必要先回顾一下事务。事务可以简单的理解为:一个大的活动由不同的小活动组成,这些活动要么全部成功,要么全部失败。

说到事务,事务的四大特性ACID肯定逃不了:

  • A(Atomic):原子性,表示构成事务的所有操作,要么全部执行完成,要么全部不执行。
  • C(Consistency):一致性,表示事务执行前后,数据库的一致性约束没有被破坏。如:你账上有400,我账上有100,你给我打200块,此时你账上的钱应该是200,我账上的钱应该是300,不会存在我账上钱加了,你账上钱没扣的中间状态
  • I(Isolation):隔离性,指在多个事务并发执行的时候不会互相干扰,即一个事务的内部的数据对于其他事务来说是隔离的,不可见的。
  • D(Durability):持久性,指事务执行完成后,数据的变更将会被持久化到数据库中。

其实我觉得原子性和一致性有点像,可以简单的理解为:原子性要求操作要么全部执行要么全部不执行,而一致性要求操作要么全部执行成功,要么全部执行失败。

分布式事务是什么

分布式事务顾名思义,就是在分布式系统中实现事务。它其实是由多个本地事务组成的,对于分布式事务来说,传统的数据库事务将不再有效。

举个例子

对于本地事务来说,我们可以通过数据库自身提供的事务特性能控制:

begin transaction;
//1.本地数据库操作:张三减少金额
//2.本地数据库操作:李四增加金额
commit transation;

在这个场景中,由于这俩个操作使用的是同一个数据库连接,所以我们是可以直接通过数据库来控制事务的。但是在分布式环境下,会变成下面这样:

begin transaction;
//1.本地数据库操作:张三减少金额
//2.远程调用:李四增加金额
commit transation;

在这个场景下,可能由于网络原因,远程调用并没有返回,因此误以为远程调用失败,导致本地事务回滚,最后造成李四金额增加,而张三没有减少金额的错误场景。

分布式事务产生的场景

微服务之间的远程调用完成事务

这是最典型的场景。如订单微服务和库存微服务。下单后订单服务需要远程调用库存服务减库存。简而言之就是:跨JVM进程产生分布式事务。
分布式事务及CAP理论_第1张图片

单个系统访问多个数据库实例

当单体系统需要访问多个数据库实例时,就会产生分布式事务,如下图所示:
分布式事务及CAP理论_第2张图片
简而言之:跨数据库实例产生分布式问题

多个服务访问同一个数据库实例

订单服务和库存服务即使使用同一个数据库,由于存在跨JVM进程,也会产生分布式事务。
分布式事务及CAP理论_第3张图片

总结

仔细观察就会发生,上面三种情况,不管是跨JVM进程还是访问呢了多个数据库实例,本质上都是因为使用了不同的数据库连接。所以可以简单的理解为,一旦一组活动是由不同的数据库连接执行的,那么就会产生分布式事务问题。

分布式事务理论基础

在分布式事务中,提供服务的结点分布在不同的机器上,它们之间通过网络进行交互。而网络是极具不稳定的一个因素,我们不能由于一点网络问题就导致整个系统无法提供服务,因此网络因素承了分布式事务的考量标准之一

我们接下来将学习CAP理论,通过CAP理论指导我们控制事务的目标,从而采取合适的分布式事务解决方案。

CAP理论

CAP是什么

CAP是Consistency、Availability和partition三个词语的缩写,分别表示一致性、可用性和分区容忍性。下面分别解释这三个名词。

Consistency

一致性指数据库写操作后的读操作可以读到最新的数据,当数据分布在多个节点上的时候,要求从结点上读到的数据都是最新数据。

如何实现一致性

  1. 写入主数据库后,需要将数据同步到从数据库中
  2. 在向从数据库同步期间需要将从数据库锁定,待数据同步后再释放锁,避免在数据同步期间,向从数据库中查到旧的数据

分布式一致性的特点

  1. 由于存在数据的同步,所以写操作的响应会有一定的延迟
  2. 为了保证一致性会对资源暂时锁定,待数据同步完成后释放锁定资源
  3. 如果请求数据同步失败的结点则会返回错误信息,一定不会返回旧数据

Availability

可用性要求任何事务操作都可以得到响应结果,你可以给我旧的数据,但是不能出现响应超时或相应错误。

如何实现可用性

  1. 写入主数据库后要将数据同步到从数据库中
  2. 为了保证数据库的可用性,不能锁定从数据库的资源(与一致性相反)。
  3. 查询从数据库时,即使还没同步新的数据,也要返回旧的数据,如果连旧的数据也没有,那么要按照约定返回一个默认的信息,但是不能返回错误或响应超时。

Partition tolerance(分区容忍)

一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上,那么出现分区之后,这一数据项就可能分布到各个区里。容忍性就提高了。然而,要把数据复制到多个节点,就会带来一致性的问题,就是多个节点上面的数据可能是不一致的。要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。

原文链接

注意:分区容忍性是分布式系统最基本能力。

CAP组合

在一个标准的分布式系统中,分区容忍性是最基本的能力,在满足分区容忍性的前提下,C和A只能出现一个,因为他们从概念上就是互斥的。

所以在一个分布式系统中,只能满足AP或者CP。

AP

放弃一致性,追求分区容忍性和可用性。这是很多分布式系统设计时的选择。比如说,订单今日退款成功后,明日账户到账,这个时候只要用户可以接受在一定时间内到账即可。

通常我们都会使用最终一致性来实现AP。什么是最终一致性,举个例子。
用户:虽然我接受你晚点到账,但是你不能不到账是吧,最终一致性就是来保证最后一定到账的。

CP

放弃可用,追求一致性和分区容错性。在实时性要求较强的场景下,需要保证一致性,如跨行转账,一次转账请求需要等待双方银行系统都完成整个事务才算完成。

CA

放弃分区容忍性,即不进行分区,这种情况下其实就不是一个标准的分布式系统了。

当数据库没有从库的时,不需要进行远程的数据同步,也就不存在网络分区(不理解的话再看一下P的概率,这个情况只有一个节点)。那么CA的架构图应该是这样的:
分布式事务及CAP理论_第4张图片
单个数据库,通过事务隔离级别,天生就可以满足CA。

总结
在大多数应用层场景下,由于结点众多、部署分散,而且集群规模越来越大,所以结点故障、网络故障是常态,为了保证服务的可用性达到99.99…%,并达到良好的响应性能来提高用户体验,一般都选择AP,舍弃强一致性,保证最终一致性。

BASE理论

三类一致性

**强一致性:**这种一致性级别最符合用户的直觉,它要求系统写入的是什么,读出来的也要是什么,用户体验好,但是实现起来对系统的性能影响极大。

**弱一致性:**这种一致性级别,系统写入成功后,不保证立马可以读到写入的值,也不保证多久之后数据能够达到一致,但会尽量保证到某个时间(如秒级别后),数据能达到一致

**最终一致性:**是弱一致性的一种特例,系统保证在一定时间内达到一致,是业界在大型分布式系统数据一致性上用的比较多的一致性模型。

2、Base理论介绍

BASE是Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对AP的一个扩展,满足BASE理论的事务,我们称之为"柔性事务"。

基本可用: 这里的基本可用与CAP中的可用性不同。BASE的基本可用指的是允许损失部分可用性。

如数据库采用分片模式,100w个用户数据分在5个数据库实例上,如果破坏了一个实例,那么可用性还有80%,也就是还有80%的用户仍然可以登录,系统仍然可用。

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

软状态: 由于不要求强一致性,所以BASE允许系统中存在中间状态(也叫软状态),这个状态不影响系统可用性,如订单的"支付中"、"数据同步中"等状态,待数据最终一致后改为"成功"状态

最终一致性: 最终一致性指经过一段时间后,所有结点数据都会达到一致。如订单的"支付中",最终会变成"支付成功"或"支付失败",使订单状态与实际交易结果达成一致,但需要一定时间的延迟、等待。

分布式事务及CAP理论_第5张图片
如有错误,欢迎指出!

你可能感兴趣的:(分布式事务,分布式)