当业务扩展到一定程度的时候，单个数据库的性能产生瓶颈的时候，我们可能会对数据库进行物理分区，也就是所谓的数据库分库分表，简单来说就是单一数据库变成了多个数据库，此时当一个操作同时需要操作两个数据库的时候，就需要分布式事务进行管理。
拆分分布式事务，交由第三方处理
这种思路来源于eBay，理解起来比较简单
此处我们举一个电商的经典例子：扣库存和更新订单数据库两个操作，其中库存数据库和订单数据库为两个独立的数据库。但是，当订单更新状态的时候进行抛出异常，那么此时的库存应该回滚数据。先上图
image.png
1、修改库存操作；
2、修改库存成功，写消息事务表；
3、如果写消息事务表，直接会滚数据，如果成功，则事务状态未待执行；
4、生产者将消息放入队列中；
5、消费者读取队列中的消息；
6、根据对应的消息，执行对应的更改订单状态的操作；
7、更改数据库；
8、将更改成功与否的状态座位放入队列中；
9、读取队列；
10、如果成功、更改本地事务表为成功状态，如果失败则A事务会滚；
当然，这种方式中，存在消息放入队列中失败的可能，即步骤4失败，所以我们需要有一个定时任务不断的扫描本地事务表中的待执行的数据，把还没处理完成的消息或者失败的消息再发送一遍。
缺点：多一个表，因为添加了一个表，业务逻辑以外会有很多其他的逻辑处理
