分布式事务

撸了今年阿里、头条和美团的面试，我有一个重要发现.......>>>

复杂的业务交互过程中，不建议使用强一致性的分布式事务。

 

解决分布式事务的最好办法就是不考虑分布式事务。

 

就像刚说的问题一样，把分布式的事务过程拆解成多个中间状态，中间状态的东西不允许用户直接操作，等状态都一致成功，或者检测到不一致的时候全部失败掉。就解耦了这个强一致性的过程。

 

一般情况下准实时就成了。涉及到钱，有时候也可以这么搞。

淘宝几s内完整一个订单处理，不是什么问题吧。

银行也不是全部都强一致性。也会扎差，也会冲正。

特别是涉及到多个系统的时候，我们比如买机票，支付完成以后，只支付完成状态，然后返回给用户了，我们过几分钟再刷新页面，才会看到变成已出票，订单完成状态。

这个时候，如果我们要求所有处理，都是强一致性的，那么久完蛋了。页面要死在那儿几分钟，才把这个事务处理完成，返回给用户。

 

 

解决分布式事务的最好办法就是不考虑分布式事务。

拆分，大的业务流程，转化成几个小的业务流程，然后考虑最终一致性。

 

问题2：分布式事务是你们自己开发的，还是数据库自带的？

kimmking：

1、只要一个处理逻辑能保证要么成功，要么跟什么也没做一样，都算是事务。数据库事务，MQ也有事务。

你自己甚至可以写个程序生成两个文件，要么都生成了，要么都删掉不留痕迹，这也算是事务。

2、分布式事务这一块有个XA规范，实现XA接口的事务，都可以加入到一个分布式事务中，被XA容器管理起来。

3、补偿的办法，需要具体情况具体分析，没有一个各种场合都适用的框架。