分布式事务之消息补偿解决方案

一、数据库本地事务

先看看数据库事务的定义：单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行

这个比较容易理解，操作过数据库的一般都懂，既是业务需求涉及到多个数据表操作的时候，需要用到事务

要么一起更新，要么一起不更新，不会出现只更新了部分数据表的情况，下边看看数据库事务的使用

上实例在小型项目中一般是问题不大的，因为小型项目一般是单机系统，数据库、Web服务大都在一台服务器上，甚至可能只有一个数据库文件，

这种情况下使用本地事务没有一点问题；

但是本地事务有很大的缺陷，因为开启事务一般是锁表的，事务执行期间会一直锁着，其他的操作一般都要排队等待，对性能要求比较高的系统是不能忍受的。

特别是涉及改动不同数据库的操作，这会造成跨库事务，性能更加低

如果还涉及到不在同一台服务器、甚至不同网段部署的数据库，那本地事务简直是系统运行的灾难，是首先需要丢弃的解决方案。

那如果遇到上述情况，该怎么做呢，这就涉及到分布式事务了

二、分段式事务的补偿机制

如果有海量数据需要处理、或者要求高并发请求的话，同步的事务机制已经是不现实的了，这种情况下必须采用异步事务机制，既分段式的事务

分段式事务一般做法就是把需求任务分段式地完成，通过事务补偿机制来保证业务最终执行成功，补偿机制一般可以归类为2种：

1 ）定时任务补偿：

　　通过定时任务去跟进后续任务，根据不同的状态表确定下一步的操作，从而保证业务最终执行成功，

　　这种办法可能会涉及到很多的后台服务，维护起来也会比较麻烦，这是应该是早期比较流行的做法

2） 消息补偿：

　　通过消息中间件触发下一段任务，既通过实时消息通知下一段任务开始执行，执行完毕后的消息回发通知来保证业务最终完成；

　　当然这也是异步进行的，但是能保证数据最终的完整性、一致性，也是近几年比较热门的做法

定时任务补偿就不说了，这篇文章我们来讨论一下通过消息补偿来完成分布式事务的一般做法

三、分布式事务之消息补偿

0）我们以简单的产品下单场景来说明，（不要较真哈）

1）先来看看分布式异步事务处理流程示意图，APP1与APP2需要互相订阅对方消息

2）首先看数据库，2个，一个库存库，一个已下单成功的库

3）项目架构Demo

数据底层访问使用的是Dapper、使用redis作为消息中间件

4）实体层代码

5）服务接口层代码

6）库存、消息通知

7）下单、下单成功消息

8）下单减库存测试

 9）下单成功及消息回发测试

10）好了，到了最后检验成果的时候了

先打开Demo.Sell.App.exe、然后打开Demo.Reserve.App.exe