分布式事务，原来可以这么玩？

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

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

举个栗子：

用户下了一个订单，需要修改余额表，订单表，流水表，于是会有类似的伪代码：

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;

后置提交优化后，在什么时候，会出现不一致?