LCN分布式事务学习0-分布式事务理论基础

1. 事务概述

1.1 事务的定义

将一个活动涉及到的所有操作纳入到一个不可分割的执行单元,只要其中任一操作执行失败,都将导致整个执行单元回滚。

简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。

事务具备ACID的特性,即原子性、一致性、隔离性和持久性。

1.2 事务分类

一般而言,常将事务分为如下几种类型的事务:

  • 本地事务
  • 垮库事务
  • 分布式事务

1.2.1 本地事务

即单一进程单一数据源事务。

就是在一个程序中,只操作一个数据的事务,即我们常说的本地事务。当一个系统业务简单、并发量、数据量较小时,可采用这种方式解决数据一致性问题。

1.2.2 跨库事务

即单一进程多数据源事务。

当数据量和并发进一步增大时,虽然可以通过将应用程序集群化,但因为都是操作同一个数据库,而数据库的并发量和数据量达到一定程度后,数据库的性能会急速下降,从而成为整个系统的短板。这时可能就需要进行分库分表,如果进行分库分表,那么就相当于一个进程需要操作多个数据源,为了解决数据一致性问题,就需要跨数据源的事务。

1.2.3 分布式事务

即多进程多数据源事务。

当业务越来越复杂时,传统的单一服务架构模式将会变得越来越沉重,模块与模块间的耦合度越来越高,不利于系统的开发和维护,因此出现了当前比较流行的微服务架构模式。

当系统从单一模式重构成微服务模式时,将会出现一个业务单元需要多个微服务共同完成,也就会出现多个微服务操作各自数据源的情况,从而产生分布式事务问题。

2. 分布式事务

分布式事务指事务的发起者、事务的参与者以及事务管理器分别位于不同节点上,但又要求实现数据一致性的事务。

简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。

本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

假设一个电商下单操作,需要同时创建订单、扣减库存、增加积分这几个操作,只有当这几个操作都成功了,则算下单操作成功。具体如下图所示:

LCN分布式事务学习0-分布式事务理论基础_第1张图片

在本地事务中,主要为ACID四大特性(原子性、一致性、隔离性、持久性),而在分布式系统中,主要为CAP和BASE理论。

2.1 CAP理论

  • 一致性(C):在分布式系统完成某个写操作后的任何读操作,都应该获取到该写操作写入的那个最新的值。即数据的强一致性。
  • 可用性(A):即服务一致可用,且读写是正常的响应时间。从性能角度提出的要求,可以理解为高性能。
  • 分区容忍性(P):即部分节点宕机或网络不可用时,系统还能对外提供满足一致性或可用性的服务,是分布式系统的基本要求。即系统的高可用,一般需要通过副本机制实现。

2.1.1 从数据存储角度理解CAP

LCN分布式事务学习0-分布式事务理论基础_第2张图片

CP:

  • 数据强一致(N1 N2 N3都写成功才算成功)
  • 数据有多个副本(N1 N2 N3)

结论:一旦某个节点(如N1)宕机,则系统不可用(因为强一致性要求导致系统写失败)。

AP:

  • 可用性(N1 N2 N3只要写成功一个就算成功,剩下的节点异步写入)
  • 数据有多个副本(N1 N2 N3)

结论:在异步写入到其他节点前,数据是不一致的。

CA:

  • 数据强一致(写入N个节点成功才算成功)
  • 可用性(N个节点中只要写成功一个就算成功,剩下的节点异步写入)

结论:N=1即单机版。

redis集群的CAP分析:

LCN分布式事务学习0-分布式事务理论基础_第3张图片

假设redis由1主3从构成,集群中只有一个主,数据只要写入主节点就算成功,可以理解为单机。但是,但是,但是,redis在主挂掉后,会从从节点中选举一个切换成主节点(从变主),并且主从切换的时候,服务是不可用的,因此redis是CP,而通过自动主从切换来实现A(可用性),从而保证最终的CAP。

kafka集群和redis集群实现原理一样,因此也是CP的,也是通过自动主从切换来实现A(可用性),从而保证最终的CAP。

2.1.2 从微服务角度理解CAP

假设一个下单功能,需要操作订单系统、库存系统、积分系统三个微服务系统,每个微服务系统自身满足CAP原理。

CP:

  • 数据强一致性(三个子系统成功才算成功)
  • 多副本(这里应该理解成多个子系统)

结论:假设某个子系统不可用,则整个下单操作就不可用。

AP:

  • 调用订单系统成功即下单成功(再异步调用库存和积分系统)
  • 多副本(这里应该理解成多个子系统)

结论:在异步调用库存和积分系统之前,数据不一致,即只能查询到订单,但没有扣减库存,没有增加积分。

2.2 总结

分布式系统一般需要满足AP,在通过异步复制数据(微服务需要异步系统调用)的方式来满足数据的最终一致性。

2 BASE理论

BASE理论是对CAP理论的延伸,思想是即使无法做到强一致性(CAP的一致性就是强一致性),但可以采用适当的采取弱一致性,即最终一致性。

BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。

2.2.1 基本可用

基本可用是指分布式系统在出现故障的时候,允许损失部分可用性(例如响应时间、功能上的可用性),允许损失部分可用性。需要注意的是,基本可用绝不等价于系统不可用。

响应时间上的损失:正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加到了1~2秒。

功能上的损失:购物网站在购物高峰(如双十一)时,为了保护系统的稳定性,部分消费者可能会被引导到一个降级页面。

2.2.2 软状态

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

2.2.3 最终一致性

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

3. 分布式事务解决方案

还是以上图为例,假设一个下单操作,需要新增订单成功、扣减库存成功、新增积分成功才算成功。对于两阶段提交和TCC而言,一般都有事务协调者、事务发起者(可以理解成下单服务)和事务参与者(可以理解成订单系统、库存系统、积分系统)3个角色。

3.1 两阶段提交

3.1.1 执行流程

LCN分布式事务学习0-分布式事务理论基础_第4张图片

执行一个下单操作时,告诉事务协调者,开启一个分布式事务。

第一阶段如下:

  • 各个子系统执行相关业务逻辑代码后,将执行结果告诉协调者,数据未入库

第二阶段如下:

  • 当所有的子事务都执行完时,事务发起者告诉事务协调者,所有子事务都执行完成,事务协调者根据各个子事务执行的结果,广播给各个子事务,是该执行commit还是rollback操作。

3.1.2 优点

  • 比较容易实现
  • 对原来的业务代码入侵性较小

3.1.3 缺点

  • 可能会破坏数据一致性。假设在第一阶段时,还有库存,但最终commit时,库存已经被其他线程更新成0了,这时库存就会被更新成负数。假设在更新库存数据时,数据库连接超时,从而导致扣减库存失败,但新增订单和新增积分却成功了。

3.1.4 开源框架

  • LCN

3.2 TCC方案Try-Confirm-Cancel

3.2.1 执行流程

LCN分布式事务学习0-分布式事务理论基础_第5张图片

执行一个下单操作时,告诉事务协调者,开启一个分布式事务。

try阶段如下:

  • 各个子系统,调用try接口,将数据库的数据锁定,并将执行结果告诉事务协调者,数据入库,但状态为预处理状态

当所有的子事务都执行完时,事务发起者告诉事务协调者,所有子事务都执行完成,事务协调者根据各个子事务执行的结果,广播给各个子事务,是该执行commit还是rollback操作

confirm阶段如下:

  • 各个子事务收到事务协调者的commit消息后,调用confirm接口,更新数据未最终状态。

cancel阶段:

  • 各个子事务收到事务协调者的rollback消息后,调用cancel接口,执行回滚操作。

3.2.2 优点

  • 在一定程度上保证了数据的一致性问题,至少不会出现库存为负的情况。

3.2.3 缺点

  • 开发难道较大,以前只每个服务只需要一个接口(执行业务逻辑),现在需要三个接口,预处理接口、确认接口、回滚接口。

3.2.4 开源框架

  • LCN
  • seata:阿里巴巴的开源框架

3.3 基于消息中间件的最终一致性方案

3.3.1 执行流程

LCN分布式事务学习0-分布式事务理论基础_第6张图片

  • 1. 订单服务将数据发送给MQ,此时MQ的数据状态为新增,如果失败,则异常结束。
  • 2. 订单服务执行自身逻辑,并将数据持久化,如果失败,则异常结束。
  • 3. 订单服务向MQ发送数据确认,此时MQ的数据状态为已确认。如果失败,可以异常结束回滚订单数据库,也可以不回滚订单数据。

下游服务从MQ中获取数据状态为已确认的数据,进行相应业务逻辑的处理。

如果订单服务向MQ发送确认数据失败,且不回滚订单数据,则下游服务还需要从MQ中获取状态为新增的数据,并向订单服务确认该数据是否有效,如果有效,则执行相关业务逻辑,如果无效,则什么都不做。

下游服务可以从MQ主动拉取数据,也可以让MQ主动推送数据到下游服务。

3.3.2 优点

  • 系统解耦,各个子系统之间的耦合性降到最低。

3.3.3 缺点

  • 数据一致性变弱,只能保证最终一致,对于一致性要求较高的系统不适应。

3.4 总结

两阶段提交和TCC只满足CP,需要通过其他手段来实现可用性;MQ方式只满足AP,也需要通过其他手段来实现最终一致性。

你可能感兴趣的:(LCN分布式事务,分布式事务,分布式事务解决方案,CAP,BASE)