58 沈剑 - 分布式事务,原来可以这么玩?



转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com

AIQ 机器学习大数据 知乎专栏 点击关注

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

:事务,是常见的做法。

举个栗子

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

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 会嵌套非常多层;

画外音:上面的例子还只考虑了余额 + 订单的一致性,就有 22=4 个分支,如果要考虑余额 + 订单 + 流水的一致性,则会有 22*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();

这个小小的改动(改动成本极低),不能彻底解决多库分布式事务数据一致性问题,但能大大降低数据不一致的概率,牺牲的是吞吐量。

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

画外音:还是那句话,一切脱离业务常见的架构设计,都是耍流氓。

思路比结论重要,希望大家有收获。


更多高质资源 尽在AIQ 机器学习大数据 知乎专栏 点击关注

转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com