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

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

作者：58沈剑 2018-10-28 17:54:00


分布式 多个数据要同时操作，如何保证数据的完整性，以及一致性呢?答案是事务，这是常见的做法。

10多年的南岗网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站的优势是能够根据用户设备显示端的尺寸不同，自动调整南岗建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“南岗网站设计”,“南岗网站推广”以来，每个客户项目都认真落实执行。

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

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

举个栗子：

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

  
 
 
 
    
   
  
  
  
  1. start transaction; 
    2.    
  
  
  
  2.  CURD table t_account;  any Exception rollback; 
    3.    
  
  
  
  3.  CURD table t_order;      any Exception rollback; 
    4.    
  
  
  
  4.  CURD table t_flow;        any Exception rollback; 
    5.    
  
  
  
  5. commit; 
    6.
  • 如果对余额表，订单表，流水表的SQL操作全部成功，则全部提交
  • 如果任何一个出现问题，则全部回滚

事务，以保证数据的完整性以及一致性。

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

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

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

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

什么是补偿事务?

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

举个栗子：

修改余额，事务为：

  
 
 
 
    
   
  
  
  
  1. int Do_AccountT(uid, money){ 
    2.    
  
  
  
  2.     start transaction; 
    3.    
  
  
  
  3.          //余额改变money这么多 
    4.    
  
  
  
  4.          CURD table t_account with money for uid; 
    5.    
  
  
  
  5.          anyException rollback return NO; 
    6.    
  
  
  
  6.     commit; 
    7.    
  
  
  
  7.     return YES; 
    8.    
  
  
  
  8. } 
    9.    
  
  
  
  9.   
    10.

那么，修改余额，补偿事务可以是：

  
 
 
 
    
   
  
  
  
  1. int Compensate_AccountT(uid, money){ 
    2.    
  
  
  
  2.          //做一个money的反向操作 
    3.    
  
  
  
  3.          return Do_AccountT(uid, -1*money){ 
    4.    
  
  
  
  4. } 
    5.

同理，订单操作，事务是：Do_OrderT，新增一个订单;

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

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

  
 
 
 
    
   
  
  
  
  1. // 执行第一个事务 
    2.    
  
  
  
  2. int flag = Do_AccountT(); 
    3.    
  
  
  
  3. if(flag=YES){ 
    4.    
  
  
  
  4.     //第一个事务成功，则执行第二个事务 
    5.    
  
  
  
  5.     flag= Do_OrderT(); 
    6.    
  
  
  
  6.     if(flag=YES){ 
    7.    
  
  
  
  7.         // 第二个事务成功，则成功 
    8.    
  
  
  
  8.         return YES; 
    9.    
  
  
  
  9.     } 
    10.    
  
  
  
  10.     else{ 
    11.    
  
  
  
  11.         // 第二个事务失败，执行第一个事务的补偿事务 
    12.    
  
  
  
  12.         Compensate_AccountT(); 
    13.    
  
  
  
  13.     } 
    14.    
  
  
  
  14. } 
    15.

补偿事务有什么缺点?

  • 不同的业务要写不同的补偿事务，不具备通用性;
  • 没有考虑补偿事务的失败;
  • 如果业务流程很复杂，if/else会嵌套非常多层;

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

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

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

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

  
 
 
 
    
   
  
  
  
  1. start transaction; 
    2.    
  
  
  
  2.  CURD table t_account;  any Exception rollback; 
    3.    
  
  
  
  3.  CURD table t_order;      any Exception rollback; 
    4.    
  
  
  
  4.  CURD table t_flow;        any Exception rollback; 
    5.    
  
  
  
  5. commit; 
    6.

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

  
 
 
 
    
   
  
  
  
  1. start transaction1; 
    2.    
  
  
  
  2.          //第一个库事务执行 
    3.    
  
  
  
  3.          CURD table t_account; any Exception rollback; 
    4.    
  
  
  
  4.          … 
    5.    
  
  
  
  5. // 第一个库事务提交 
    6.    
  
  
  
  6. commit1; 
    7.    
  
  
  
  7.  
    8.    
  
  
  
  8. start transaction2; 
    9.    
  
  
  
  9.          //第二个库事务执行 
    10.    
  
  
  
  10.          CURD table t_order; any Exception rollback; 
    11.    
  
  
  
  11.          … 
    12.    
  
  
  
  12. // 第二个库事务提交 
    13.    
  
  
  
  13. commit2; 
    14.    
  
  
  
  14.  
    15.    
  
  
  
  15. start transaction3; 
    16.    
  
  
  
  16.          //第三个库事务执行 
    17.    
  
  
  
  17.          CURD table t_flow; any Exception rollback; 
    18.    
  
  
  
  18.          … 
    19.    
  
  
  
  19. // 第三个库事务提交 
    20.    
  
  
  
  20. commit3; 
    21.

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

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

  • 执行(CURD)的时间很长
  • 提交(commit)的执行很快

于是整个执行过程的时间轴如下：

  • 第一个事务执行200ms，提交1ms;
  • 第二个事务执行120ms，提交1ms;
  • 第三个事务执行80ms，提交1ms;

在什么时候，会出现不一致?

答：第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题(例如服务器重启，数据库异常等)，都可能导致数据不一致。

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

什么是后置提交优化?

答：如果改变事务执行与提交的时序，变成事务先执行，最后一起提交。

  • 第一个事务执行200ms，第二个事务执行120ms，第三个事务执行80ms;
  • 第一个事务提交1ms，第二个事务提交1ms，第三个事务提交1ms;

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

答：问题的答案与之前相同，第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题(例如服务器重启，数据库异常等)，都可能导致数据不一致。

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

有什么区别和差异?

答：

  • 串行事务方案，总执行时间是303ms，最后202ms内出现异常都可能导致不一致;
  • 后置提交优化方案，总执行时间也是303ms，但最后2ms内出现异常才会导致不一致;

虽然没有彻底解决数据的一致性问题，但不一致出现的概率大大降低了。

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

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

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

  • 串行事务方案，第一个库事务提交，数据库连接就释放了;
  • 后置提交优化方案，所有库的连接，要等到所有事务执行完才释放;

这就意味着，数据库连接占用的时间增长了，系统整体的吞吐量降低了。

总结

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

  • 补偿事务
  • 后置提交优化

把

  
 
 
 
    
   
  
  
  
  1. trx1.exec(); trx1.commit(); 
    2.    
  
  
  
  2. trx2.exec(); trx2.commit(); 
    3.    
  
  
  
  3. trx3.exec(); trx3.commit(); 
    4.

优化为：

  
 
 
 
    
   
  
  
  
  1. trx1.exec(); trx2.exec(); trx3.exec(); 
    2.    
  
  
  
  2. trx1.commit(); trx2.commit(); trx3.commit(); 
    3.

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

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

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

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

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】

网页题目：分布式事务，原来可以这么玩？
链接分享：http://www.shufengxianlan.com/qtweb/news10/220810.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

域名注册知识

分类信息网站

航空文化传媒　　 　重庆企业网站建设　　 　温江服务器托管　　 　成都企业网站维护　　 　营销型网站建设　　 　广汉锦华　　 　成都办公窗帘　　 　广汉锦华建材　　 　高端品牌网站建设　　 　成都网站制作　　 　成都网站建设　　 　新网创想　　 　小谭网创广告　　 　php空间　　 　响应式报价　　 　成都纯水机　　 　广汉做网站　　 　成都网站设计　　 　电商网店　　 　高端定制网站设计