分布式事务

分布式事务

 

1.XA两阶段提交：引入协调者。三阶段提交，引入询问阶段

XA是数据库的分布式事务，强一致性，在整个过程中，数据一张锁住状态，即从prepare到commit、rollback的整个过程中，一直把持折数据库的锁，如果有其他人要修改数据库的该条数据，就必须等待锁的释放，严重影响性能

缺点：1.性能问题：XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源锁，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。

2.协调者单点故障问题：事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。

 

2.TCC方案

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。TCC异步高性能，它采用了try先检查，然后异步实现confirm，真正提交是在confirm方法中。框架：tcc-transaction、Hmily、ByteTCC（支持幂等）、EasyTransaction

优点： 1. 因为Try阶段检查并预留了资源，所以confirm阶段一般都可以执行成功。

2.资源锁定都是在业务代码中完成，不会block住DB，可以做到对db性能无影响。

缺点：  1.因为事务状态管理，将产生多次DB操作，这将损耗一定的性能，并使得整个TCC事务时间拉长。

2. Try、Confirm、Cancel中的代码就越复杂，可复用性就越底

 

实现：try阶段，先不把订单状态修改为已支付，先把订单状态修改为 UPDATING，也就是修改中的意思，然后销售的库存需要减去2,如果本来有100，先设置为 98 没问题，然后在一个单独的冻结库存的字段里，设置一个 2。也就是说，有 2 个库存是给冻结了。接下来，开始执行，如果都成功，一起conform，如果其中一个失败，都会感知到，然后都cannel，也就是把冻结的数据，设置为0就好。一般try能成功的，基本Confirm都ok的。

 

3．消息队列方案，可靠消息最终一致性

引入MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态。最终一致性，轮询mq中的信息，补偿数据。如下：

第一步，A系统在扣款10000元时，首先扣完之后，先不提交这个操作，先发送一条消息给消息中心，记录这条消息的状态为“准备发送”。

第二步，确定消息已经发送成功后，然后A项目开始commit，现在A项目已经提交扣款Commit 若成功，给消息中心发一条update指令，修改刚刚的消息状态为“可以发送”。 commit若失败，则给消息中心发一条update指令，修改刚刚的消息状态为“取消发送”。

假设用户A扣款事务被成功或失败提交后，系统挂了，此时消息状态并未被更新为“确认发送”或者“取消发送”，从而导致消息不能被发送，那么这个时候，我们需要有一个消息状态确认系统定时去用户A系统查询这个消息的状态并进行更新。

第三步，当第二步成功更改消息状态为“可以发送”后，我们通过消息中心服务将此消息通知用户B，用户B开始业务处理

若执行成功，去消息中心，更新这个消息状态为“已执行”，并通知用户A，然后用户A收到回复后，在消息中心删除该条消息数据。

若执行失败，去消息中心，更新这个消息状态为“执行失败”，并通知用户A，然后用户A收到回复后，回滚之前的扣款操作。

若用户B处理完消息msg后，发送了处理成功的消息给用户A，正常情况下用户A应该要删除消息msg，但如果用户A这时候悲剧的挂了，重启后一看消息msg还在，就会继续发送消息msg。解决方法很简单，在用户B这边增加消息应用状态表（message_apply），通俗来说就是个账本，用于记录消息的消费情况，每次来一个消息，在真正执行之前，先去消息应用状态表中查询一遍，如果找到说明是重复消息，丢弃即可，如果没找到才执行，同时插入到消息应用状态表（同一事务）

A先commit，commit完事后，通过mq给B推消息，B收到消息也开始commit，B完事后，通过mq给A推消息说success，执行完毕。若B执行失败，则通过mq给A推消息，执行失败，A收到消息后，回滚之前操作。

 

 

 

没有最好的技术，只有最合适的技术。这三种方案适用的场景都不一样。

1.对于并发不高，对资源层通常是数据库均由访问权限的分布式系统，建议采用XA方案。

2.对于并发不高，互相独立的分布式系统，建议采用TCC方案。

3.对于并发高的分布式系统，建议考虑消息队列方案。