分布式事务

分布式事务

1.什么是分布式事务

分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。

2.RocketMQ可靠消息最终一致性

2.1.为什么要使用可靠消息最终一致性

​ 在实际系统的开发过程中，可能服务间的调用是异步的。也就是说，一个服务发送一个消息给 MQ，即消息中间件，比如RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。

​ 然后，另外一个服务从 MQ 消费到一条消息后进行处理。这就成了基于 MQ 的异步调用了。

​ 那么针对这种基于 MQ 的异步调用，如何保证各个服务间的分布式事务呢？也就是说，我希望的是基于MQ 实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败。这个时候，就要用上可靠消息最终一致性方案，来实现分布式事务。

2.2.什么是可靠消息最终一致性

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

2.3.可靠消息最终一致性要解决的问题：

2.3.1.上游服务把信息成功发送

本地事务与消息发送的原子性问题：事务发起方在本地事务执行成功后消息必须发出去，否则就回滚事务。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。

2.3.2.下游服务把消息成功消费

事务参与方接收消息的可靠性：事务参与方必须能够从消息队列接收到消息。

2.3.3.对消息做幂

消息重复消费的问题：由于网络2的存在，若某一个消费节点响应超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

2.4.解决方案

2.4.1.问题一：上游服务把消息成功发送

针对问题一可采用消息表这个方案，该方案最初是eBay提出的，此方案的核心是：在系统A处理任务完成后，在本地记录待发送信息。一个定时任务不断检查，是否发送成功，如果发送成功，将记录状态修改。

CREATE TABLE `local_message` (
  `tx_no` varchar(255) NOT NULL,
  `order_no` varchar(255) DEFAULT NULL,
  `state` int(11) DEFAULT NULL,
  PRIMARY KEY (`tx_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

使用定时器

如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S1OpNXnM-1608807672006)(assets/1590936699401.png)]

2.4.2.问题二：下游服务把消息成功消费

**消息重试：**消息持久化后，如果消息在投递过程中丢失，或消息的确认应答在返回途中丢失，那么消息中间件就会重新投递，直到下游消费者返回消费成功响应为止。

**任务失败：**当任务处理失败后，则返回给消息中间件失败，消息会重复发送

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gjcJ7D6a-1608807672007)(assets/1590936904531.png)]

2.4.3.问题三：对消息做幂等

任务B处理消息前，先查询该消息是否被消费，如果没消费，处理任务B成功，记录消息。如果消息已经被消费，直接返回应答成功

在数据库中新增de_duplication，去重表，用于交易幂等控制。

DROP TABLE IF EXISTS `de_duplication`;
CREATE TABLE `de_duplication` (
  `tx_no` varchar(255) NOT NULL,
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`tx_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;