多个数据要同时操作，如何保证数据的完整性，以及一致性？
答 ： 事务 ，是常见的做法。
举个栗子：
用户下了一个订单，需要修改 余额表 ， 订单 表 ， 流水 表 ，于是会有类似的伪代码：
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等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！