分布式事务，原来能够这么玩？

多个数据要同时操做，如何保证数据的完整性，以及一致性？

答 ： 事务 ，是常见的作法。

举个栗子：

用户下了一个订单，须要修改 余额表 ， 订单 表 ， 流水 表 ，因而会有相似的伪代码：

start transaction;

CURD table t_account; any Exception rollback;

CURD table t_order;   any Exception rollback;

CURD table t_flow;    any Exception rollback;

commit;

 ● 若是对余额表，订单表，流水表的SQL操做所有成功，则所有提交  ● 若是任何一个出现问题，则所有回滚 事务，以保证数据的完整性以及一致性。

事务的方案会有什么潜在问题？

答 ：互联网的业务特色，数据量较大，并发量较大，常常使用 拆库 的方式提高系统的性能。若是进行了拆库， 余额、订单、流水可能分布在不一样的数据库 上，甚至不一样的数据库实例上，此时就不能用数据库原生事务来保证数据的一致性了。

高并发易落地的分布式事务，是行业没有很好解决的难题，那怎么办呢？

答 ： 补偿事务 是一种常见的实践。

什么是补偿事务？

答：补偿事务，是一种在业务端实施 业务逆向操做事务 。

举个栗子：

修改余额 ， 事务 为：

int  Do_AccountT (uid, money){

start transaction;

//余额改变money这么多

CURD table t_account with money for uid;

anyException rollback return NO;

commit;

return YES;

}

那么， 修改余额 ， 补偿事务 能够是：

int  Compensate_AccountT (uid, money){

//作一个money的反向操做

return Do_AccountT(uid, -1*money){

}

同理， 订单操做 ， 事务 是：Do_OrderT，新增一个订单；

订单操做 ， 补偿事务 是：Compensate_OrderT，删除一个订单。

要保证余额与订单的一致性，伪代码：

// 执行第一个事务

int flag = Do_AccountT();

if(flag=YES){

//第一个事务成功，则执行第二个事务

flag= Do_OrderT();

if(flag=YES){

// 第二个事务成功，则成功

return YES;

}

else{

// 第二个事务失败，执行第一个事务的补偿事务

Compensate_AccountT();

}

}

补偿事务有什么缺点？

● 不一样的业务要写不一样的补偿事务， 不具有通用性 ；

● 没有考虑补偿事务的失败 ；

● 若是业务流程很复杂， if/else会嵌套很是多层 ；

画外音：上面的例子还只考虑了余额+订单的一致性，就有2*2=4个分支，若是要考虑余额+订单+流水的一致性，则会有2*2*2=8个if/else分支，复杂性呈指数级增加。

还有其它简易一致性实践么？

答 ：多个数据库实例上的多个事务，要保证一致性，能够进行“ 后置提交优化 ”。

单库 是用这样一个大事务保证一致性：

start transaction;

CURD table t_account; any Exception rollback;

CURD table t_order;   any Exception rollback;

CURD table t_flow;    any Exception rollback;

commit;

拆分红了多个库后，大事务会变成三个小事务：

start transaction1;

//第一个库事务执行

CURD table t_account; any Exception rollback;

…

// 第一个库事务提交

commit1;

start transaction2;

//第二个库事务执行

CURD table t_order; any Exception rollback;

…

// 第二个库事务提交

commit2;

start transaction3;

//第三个库事务执行

CURD table t_flow; any Exception rollback;

…

// 第三个库事务提交

commit3;

画外音：再次提醒，这三个事务发生在三个库，甚至3个不一样实例的数据库上。

一个事务，分红 执行 与 提交 两个阶段：

 ● 执行(CURD)的时间很长  ● 提交(commit)的执行很快 因而整个执行过程的时间轴以下：

 

 

 

第一个事务执行200ms，提交1ms；

第二个事务执行120ms，提交1ms；

第三个事务执行80ms，提交1ms；

在何时，会出现不一致？

答 ：第一个事务成功提交以后，最后一个事务成功提交以前，若是出现问题（例如服务器重启，数据库异常等），均可能致使数据不一致。

 

 

 

画外音：如上图，最后202ms内出现异常，会出现不一致。

什么是后置提交优化？

答 ：若是改变事务执行与提交的时序，变成 事务先执行，最后一块儿提交 。

 

 

 

第一个事务执行200ms，第二个事务执行120ms，第三个事务执行80ms；

第一个事务提交1ms，第二个事务 提交 1ms，第三个事务 提交 1ms；

后置提交优化后，在何时，会出现不一致？

答 ：问题的答案与以前相同，第一个事务成功提交以后，最后一个事务成功提交以前，若是出现问题（例如服务器重启，数据库异常等），均可能致使数据不一致。

 

 

 

 

 

画外音： 如上 图，最后2ms内出现异常，会出现不一致。

有什么区别和差别？

答 ：

● 串行事务方案 ，总执行时间是303ms，最后202ms内出现异常均可能致使不一致；

● 后置提交优化方案 ，总执行时间也是303ms，但最后2ms内出现异常才会致使不一致；

虽然没有完全解决数据的一致性问题，但 不一致出现的几率大大下降了 。

画外音：上面这个例子，几率下降了100倍。

后置提交优化 ，有什么不足？

答 ：对事务吞吐量会有影响：

● 串行事务方案 ， 第一个库事务提交，数据库链接就释放了 ；

● 后置提交优化方案 ， 全部库的链接，要等到全部事务执行完才释放 ；

这就意味着，数据库链接占用的时间增加了，系统总体的吞吐量下降了。

总结

分布式事务，两种常见的实践：

 ● 补偿事务  ● 后置提交优化 把

trx1.exec(); trx1.commit();

trx2.exec(); trx2.commit();

trx3.exec(); trx3.commit();

优化为：

trx1.exec(); trx2.exec(); trx3.exec();

trx1.commit(); trx2.commit(); trx3.commit();

这个小小的改动（改动成本极低），不能完全解决多库分布式事务数据一致性问题，但能大大下降数据不一致的几率，牺牲的是吞吐量。

对于一致性与吞吐量的折衷，还须要业务架构师谨慎权衡折衷。

欢迎工做一到五年的Java工程师朋友们加入Java架构开发： 855835163 群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！