专栏首页架构师之路分布式事务,有解吗?

分布式事务,有解吗?

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

:事务。

举个栗子

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

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();

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

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

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

本文分享自微信公众号 - 架构师之路(road5858),作者:58沈剑

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-06-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 多库多事务降低数据不一致概率

    一、案例缘起 我们经常使用事务来保证数据库层面数据的ACID特性。 举个栗子,用户下了一个订单,需要修改余额表,订单表,流水表,于是会有类似的伪代码: star...

    架构师之路
  • 连接池原来这么简单(一分钟系列)

    应网友要求,写一写连接池实现细节。 一、如何通过连接访问下游 工程架构中有很多访问下游的需求,下游包括但不限于服务/数据库/缓存,其通讯步骤是为: (1)与下游...

    架构师之路
  • InnoDB行锁,如何锁住一条不存在的记录?

    《InnoDB,5项最佳实践,知其所以然?》发布后,不少同学留言希望讲讲MySQL的InnoDB行锁机制。要细聊MySQL的行锁,难以避免的要从事务的四种隔离级...

    架构师之路
  • 猿思考系列6——事务也就那么回事儿

    看完上一个章节,相信你已经充分的掌握代理的套路,猿人工厂君也知道,内容对于新手而言,理解起来还是比较很吃力的,文中提到的其他方式,大家可以去尝试实现,猿人工厂君...

    山旮旯的胖子
  • 阴阳大论之事务

    MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx...

    Java学习录
  • 事务管理与数据库安全性(1)

    所谓事物是用户定义的一个数据库操作序列,这些操作要么全做要么不做,是一个不可分割的工作单位。

    ellipse
  • 数据库事务隔离级别(脏读、幻读、不可重复读)【BAT 面试题宝库附详尽答案解析】

    为了解决上述问题,数据库通过锁机制 解决并发访问的问题。根据锁定对象不同:分为行级锁和表级锁;根据并发事务锁定的关系上看:分为共享锁定和独占锁定,共享锁定会防止...

    一个会写诗的程序员
  • 浅谈数据库事务

    原子性是指事务包含的所有操作要么全部成功,要么全部失败。 例小王要向小李转账200元。则账要么转账成功小王账户减200元,小李账户加200元,要么执行失败,两者...

    Java学习录
  • 后端程序员必备:分布式事务基础篇

    数据库事务(简称:事务),是数据库管理系统执行过程中的一个逻辑单位,由一个有限的数据库操作序列构成,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单...

    捡田螺的小男孩
  • 搞懂分布式技术17:浅析分布式事务

    本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看

    Java技术江湖

扫码关注云+社区

领取腾讯云代金券