分布式事务解决方案(可用消息最终一致性)

最新推荐文章于 2022-03-09 21:31:31 发布

烟火星辰madi

最新推荐文章于 2022-03-09 21:31:31 发布

阅读量493

点赞数

分类专栏： JAVA

本文链接：https://blog.csdn.net/weixin_44117767/article/details/103610689

版权

JAVA 专栏收录该内容

197 篇文章 8 订阅

订阅专栏

我们编写的扣减库存与保存订单是在两个服务中存在的，如果扣减库存后订单保存失败了是不会回滚的，这样就会造成数据不一致的情况，这其实就是我们所说的分布式事务的问题，接下来我们来学习分布式事务的解决方案。

一.本地事务与分布式事务

1.1事务

数据库事务(简称：事务，Transaction)是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
事务拥有以下四个特性，习惯上被称为ACID特性：
原子性(Atomicity)：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性(Consistency)：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
隔离性(Isolation)：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
持久性(Durability)：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。

1.2 本地事务

起初，事务仅限于对单一数据库资源的访问控制,架构服务化以后，事务的概念延伸到了服务中。倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源,这类基于单个服务单一数据库资源访问的事务，被称为本地事务(Local Transaction)。
在这里插入图片描述

1.3 分布式事务

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别
位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操
作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的
数据一致性。
最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉
及到对多个数据库资源的访问。
在这里插入图片描述
当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就
需要采用分布式事务来协调所有的事务参与者。
对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，
但是毕竟整个事务还是控制在单一服务的内部。如果一个服务操作需要调用另外一个服
务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用
另外一个服务的时候，需要以某种机制流转到另外一个服务，从而使被调用的服务访问
的资源也自动加入到该事务当中来。下图反映了这样一个跨越多个服务的分布式事务：
在这里插入图片描述
如果将上面这两种场景(一个服务可以调用多个数据库资源，也可以调用其他服务)结
合在一起，对此进行延伸，整个分布式事务的参与者将会组成如下图所示的树形拓扑结
构。在一个跨服务的分布式事务中，事务的发起者和提交均系同一个，它可以是整个调
用的客户端，也可以是客户端最先调用的那个服务。
在这里插入图片描述
较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂。在不
同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资
源的协调、事务的跨服务传播等，实现机制也是复杂多变。

二. 分布式事务相关理论

2.1 CAP定理

![在这里插入图片描述](https://img-blog.csdnimg.cn/20191219110850241.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDExNzc2Nw==,size_16,color_FFFFFF,t_70)
CAP 定理是在 1998年加州大学的计算机科学家 Eric Brewer （埃里克.布鲁尔）提出，分

布式系统有三个指标
Consistency 一致性
Availability 可用性
Partition tolerance 分区容错
它们的第一个字母分别是 C、A、P。Eric Brewer 说，这三个指标不可能同时做到。这个
结论就叫做 CAP 定理。
分区容错 Partition tolerance
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区
容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美
国，这就是两个区，它们之间可能无法通信。
在这里插入图片描述
上图中， G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。
系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，
剩下的 C 和 A 无法同时做到。
可用性 Availability
Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。
用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉
用户，到底是 v0 还是 v1，否则就不满足可用性。
在这里插入图片描述
一致性 Consistency
Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。
举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。
在这里插入图片描述
为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求
G2 也改成 v1。

一致性和可用性的矛盾
一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分
区容错）。
如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数
据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。
如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。
综上所述， G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求
一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到
一致性。

4.2.2 BASE理论

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually
consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。BASE 理论是对
CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于
CAP 定理逐步演化而来的。其核心思想是：

既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务
特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

Basically Available(基本可用)
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系
统而言：

响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的
搜索引擎可以在 1 秒作用返回结果。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但
是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级
页面。
Soft state（软状态）
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种
“硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用
性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，
因此所有客户端对系统的数据访问最终都能够获取到最新的值。

分布式事务解决方案

4.3.1 基于XA协议的两阶段提交
首先我们来简要看下分布式事务处理的 XA规范：
在这里插入图片描述
可知 XA规范中分布式事务有AP，RM，TM组成：
其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结
束）并访问事务边界内的资源。
资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可
以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。
事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标
识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
二阶段协议:
第一阶段TM要求所有的RM准备提交对应的事务分支，询问RM是否有能力保证成功的提
交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就就对工作
内容进行持久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定答复并回滚
了已经的工作后，就可以丢弃这个事务分支信息了。
第二阶段TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的
RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的
话，则TM通知所有RM回滚自己的事务分支。
也就是TM与RM之间是通过两阶段提交协议进行交互的.
优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不
能100%保证强一致）
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

3.2 TCC 补偿机制

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应
的确认和补偿（撤销）操作。它分为三个阶段：
Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm
阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源
释放。
在这里插入图片描述
例如： A要向 B 转账，思路大概是：

我们有一个本地方法，里面依次调用
1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解
冻方法 (Cancel)。

优点：相比两阶段提交，可用性比较强
缺点：数据的一致性要差一些。TCC属于应用层的一种补偿方式，所以需要程序员在实
现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处
理。

3.3 消息最终一致性

消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进
行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：
在这里插入图片描述
基本思路就是：
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一
个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消
费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成
功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失
败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一
遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处
理。

5. 库存扣减分布式事务的实现

5.1 需求分析
如果订单在创建时发生了异常，此时库存已经扣减了，这样库存就比实际中的数量要
少，造成数据不一致，为了避免这种情况，我们需要采用消息最终一致性的分布式事务
解决方案。
5.2 实现思路
如下图：
（1）当订单服务发生异常时，发送消息给mq ，消息内容为要购物车数据，用于恢复库
存
（2）商品服务从mq提取消息，保存到库存回滚表中
（3）在管理后台开启定时任务，定时扫描库存回滚表执行库存回滚。
在这里插入图片描述
下面我们来看一下库存回滚表 tb_stock_back的设计

为什么要设置成联合主键的形式呢？因为消息在发送时，可能会因为失败而重复发送，
而重复发送可能造成回滚数据的重复。订单编号+sku编号组合起来如果相同一定是同一
笔数据，所以我们将其设置成联合主键，这样在插入重复数据时就会因为主键唯一冲突
而无法插入。

5.3 代码实现

5.3.1 发送库存回滚消息
（1）qingcheng_service_order工程pom.xml引入依赖

<dependency>
<groupId>org.springframework.amqp</groupId>    
<artifactId>spring‐rabbit</artifactId>    
<version>2.1.4.RELEASE</version>    
</dependency>

（2）添加配置文件applicationContext-rabbitmq-producer.xml

<!‐‐连接工厂‐‐>    
<rabbit:connection‐factory id="connectionFactory" host="127.0.0.1"
port="5672" username="guest" password="guest" />
   
<rabbit:admin connection‐factory="connectionFactory"></rabbit:admin>    
<!‐‐SKU 库存回滚队列 ‐‐>    
<rabbit:queue name="queue.skuback" />        
<rabbit:template id="rabbitTemplate" connection‐
factory="connectionFactory" />

（3）修改OrderServiceImpl的add方法

try{    
//保存订单主表        
//.......        
//保存订单明细        
//.......        
}catch (Exception ex){    
rabbitTemplate.convertAndSend("","queue.skuback",
JSON.toJSONString(orderItems));
       
throw new RuntimeException("订单生成失败"); //抛出异常，让其回滚！        
}

5.3.2 生成库存回滚记录
实现思路：从消息队列中取出购物车列表json，转换为列表后查询到库存回滚表。
（1）qingcheng_service_goods工程pom.xml引入依赖

<dependency>
<groupId>org.springframework.amqp</groupId>    
<artifactId>spring‐rabbit</artifactId>    
<version>2.1.4.RELEASE</version>    
</dependency>

（2）新增StockBack实体类

@Table(name = "tb_stock_back")
public class StockBack {
    @Id
    private String orderId;
    @Id
    private String skuId;
    private Integer num;
    private String status;
    private Date createTime;
    private Date backTime;
    // getter and setter....
}

（3）新增StockBack数据访问接口

public interface StockBackMapper extends Mapper<StockBack> {
}

（4）StockBackService新增方法定义

public void addList(List<OrderItem> orderItems);

（5）StockBackServiceImpl实现方法

@Override
    @Transactional
    public void addList(List<OrderItem> orderItems) {
        for(OrderItem orderItem:orderItems){
            StockBack stockBack=new StockBack();
            stockBack.setOrderId(orderItem.getOrderId());
            stockBack.setSkuId(orderItem.getSkuId());
            stockBack.setStatus("0");
            stockBack.setNum(orderItem.getNum());
            stockBack.setCreateTime(new Date());
            stockBackMapper.insert(stockBack);
        }
    }

（6）编写消费端，从消息中取出消息，转换json字符串并调用服务方法

public class BackMessageConsumer implements MessageListener {
@Autowired    
private StockBackService stockBackService;    
public void onMessage(Message message) {    
try {        
String jsonString = new String(message.getBody());            
List<OrderItem> orderItems = JSON.parseArray(jsonString,
OrderItem.class);
           
stockBackService.addList(orderItems);            
} catch (Exception e) {        
e.printStackTrace();            
//记录日志            
}        
}    
}

（7）qingcheng_service_goods添加配置文件applicationContext-rabbitmq-
consumer.xml

<!‐‐连接工厂‐‐>
<rabbit:connection‐factory id="connectionFactory" host="127.0.0.1"
port="5672" username="guest" password="guest" />
<rabbit:admin connection‐factory="connectionFactory"></rabbit:admin>
<!‐‐创建队列‐‐>
<rabbit:queue name="queue.skuback" />
<!‐‐消费者监听类‐‐>
<bean id="messageConsumer"
class="com.qingcheng.consumer.BackMessageConsumer"></bean>
<!‐‐设置监听容器‐‐>
<rabbit:listener‐container connection‐factory="connectionFactory" >
<rabbit:listener queue‐names="queue.skuback" ref="messageConsumer"/>    
</rabbit:listener‐container>

5.3.3 定时执行库存回滚

实现思路：编写定时任务，间隔一小时执行库存回滚。查询库存回滚记录表中状态为0的
记录，执行回滚逻辑。
（1）StockBackService新增方法定义

/**
 *  执行库存回滚
 */
public void doBack();

（2）StockBackServiceImpl实现方法

@Autowired
    private SkuMapper skuMapper;
    @Transactional
    public void doBack() {
        System.out.println("库存回滚任务开始");
        //查询库存回滚表中状态为0的记录
        StockBack stockBack0=new StockBack();
        stockBack0.setStatus("0");
        List<StockBack> stockBackList =
stockBackMapper.select(stockBack0);
        for( StockBack stockBack:stockBackList){
            //添加库存
            skuMapper.deductionStock(stockBack.getSkuId(), ‐
stockBack.getNum() );
            //减少销量
            skuMapper.addSaleNum(stockBack.getSkuId(), ‐
stockBack.getNum());
            stockBack.setStatus("1");
            stockBack.setBackTime(new Date());
            stockBackMapper.updateByPrimaryKey(stockBack);
        }
        System.out.println("库存回滚任务结束");
    }

（3）qingcheng_web_manager添加任务调度类

@Component
public class SkuTask {
    @Reference
    private StockBackService stockBackService;
    @Scheduled(cron = "0 0 0/1 * * ?")
    public void orderTimeOutLogic(){
        System.out.println("执行库存回滚");
        stockBackService.doBack();
    }
}