事务 - Saga模式

Saga

github

1987年普林斯顿大学的Hector Garcia-Molina和Kenneth Salem发表了一篇Paper Sagas,讲述的是如何处理long lived transaction(长活事务)。听起来是不是觉得和分布式事务很像?没错,下面来看看这个来自1987年的解决方案是如何启发当今的分布式事务问题的。

协议介绍

Saga的组成:

  • 每个Saga由一系列sub-transaction Ti 组成
  • 每个Ti 都有对应的补偿动作Ci,补偿动作用于撤销Ti造成的结果

可以看到,和TCC相比,Saga没有“预留”动作,它的Ti就是直接提交到库。

Saga的执行顺序有两种:

  • T1, T2, T3, ..., Tn
  • T1, T2, ..., Tj, Cj,..., C2, C1,其中0 < j < n

Saga定义了两种恢复策略:

  • backward recovery,向后恢复,即上面提到的第二种执行顺序,其中j是发生错误的sub-transaction,这种做法的效果是撤销掉之前所有成功的sub-transation,使得整个Saga的执行结果撤销。
  • forward recovery,向前恢复,适用于必须要成功的场景,执行顺序是类似于这样的:T1, T2, ..., Tj(失败), Tj(重试),..., Tn,其中j是发生错误的sub-transaction。该情况下不需要Ci。

对于ACID的保证

Saga对于ACID的保证和TCC一样:

  • A,正常情况下保证。
  • C,在某个时间点,会出现A库和B库的数据违反一致性要求的情况,但是最终是一致的。
  • I,在某个时间点,A事务能够读到B事务部分提交的结果。
  • D,和本地事务一样,只要commit则数据被持久。

和TCC对比

Saga相比TCC的缺点是缺少预留动作,导致补偿动作的实现比较麻烦:Ti就是commit,比如一个业务是发送邮件,在TCC模式下,先保存草稿(Try)再发送(Confirm),撤销的话直接删除草稿(Cancel)就行了。而Saga则就直接发送邮件了(Ti),如果要撤销则得再发送一份邮件说明撤销(Ci),实现起来有一些麻烦。

如果把上面的发邮件的例子换成:A服务在完成Ti后立即发送Event到ESB(企业服务总线,可以认为是一个消息中间件),下游服务监听到这个Event做自己的一些工作然后再发送Event到ESB,如果A服务执行补偿动作Ci,那么整个补偿动作的层级就很深。

不过没有预留动作也可以认为是优点:

  • 有些业务很简单,套用TCC需要修改原来的业务逻辑,而Saga只需要添加一个补偿动作就行了。
  • TCC最少通信次数为2n,而Saga为n(n=sub-transaction的数量)。
  • 有些第三方服务没有Try接口,TCC模式实现起来就比较tricky了,而Saga则很简单。
  • 没有预留动作就意味着不必担心资源释放的问题,异常处理起来也更简单(请对比Saga的恢复策略和TCC的异常处理)。

实现Saga的注意事项

对于服务来说,实现Saga有以下这些要求:

  1. Ti和Ci是幂等的。
  2. Ci必须是能够成功的,如果无法成功则需要人工介入。
  3. Ti - Ci和Ci - Ti的执行结果必须是一样的:sub-transaction被撤销了。

第一点要求Ti和Ci是幂等的,举个例子,假设在执行Ti的时候超时了,此时我们是不知道执行结果的,如果采用forward recovery策略就会再次发送Ti,那么就有可能出现Ti被执行了两次,所以要求Ti幂等。如果采用backward recovery策略就会发送Ci,而如果Ci也超时了,就会尝试再次发送Ci,那么就有可能出现Ci被执行两次,所以要求Ci幂等。

第二点要求Ci必须能够成功,这个很好理解,因为,如果Ci不能执行成功就意味着整个Saga无法完全撤销,这个是不允许的。但总会出现一些特殊情况比如Ci的代码有bug、服务长时间崩溃等,这个时候就需要人工介入了。

第三点乍看起来比较奇怪,举例说明,还是考虑Ti执行超时的场景,我们采用了backward recovery,发送一个Ci,那么就会有三种情况:

  1. Ti的请求丢失了,服务之前没有、之后也不会执行Ti
  2. Ti在Ci之前执行
  3. Ci在Ti之前执行

对于第1种情况,容易处理。对于第2、3种情况,则要求Ti和Ci是可交换的(commutative),并且其最终结果都是sub-transaction被撤销。

参考资料

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏james大数据架构

我是如何处理大并发量订单处理的 KafKa部署总结

  今天要介绍的是消息中间件KafKa,应该说是一个很牛的中间件吧,背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ,为什么不用RabbitMQ,因为...

3919
来自专栏开发技术

nginx实现请求的负载均衡 + keepalived实现nginx的高可用

  使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,...

1601
来自专栏Spark学习技巧

HBase最佳实践-读性能优化策略

就职于网易杭州研究院后台技术中心数据库技术组,从事HBase开发、运维,对HBase相关技术有浓厚的兴趣。

4595
来自专栏腾讯大数据的专栏

zookeeper 运营经验分享

Zookeeper作为TDBank系统的一个重要模块,我们运营它已经两年多。在使用过程中,我们也遇到了一些问题及走过很多弯路,本文主要对zookeeper运营经...

2779
来自专栏北京马哥教育

etcd:从应用场景到实现原理的全方位解读

马哥linux运维 | 最专业的linux培训机构 ---- 随着CoreOS和Kubernetes等项目在开源社区日益火热,它们项目中都用到的etcd组件作...

55212
来自专栏FreeBuf

如何恢复Linux中的误删文件

写在前面的话 在开始教程之前我有必要提醒大家,使用窗口管理器(GUI)删除文件和使用命令行工具(CLI)删除文件这两种方法之间是有区别的。 当我们使用窗口管理器...

4308
来自专栏菜鸟致敬

[菜鸟致敬⑤] 极简搭建 hexo博客

可能有人看到这里觉得文章写得太省略,比如 github还需要添加 ssh密匙一类的旁枝末节的东西,但是我想说的是,文章适用人群是菜鸟程序员而不是懵逼小白,我们需...

1003
来自专栏技术点滴

git使用小结

git使用小结 很多人可能和我一样,起初对git是一无所知的。我也是因为一次偶然的机会接触到git,并被它强大的功能所蛰伏。git其实就是一种版本控制工具,就像...

2078
来自专栏喔家ArchiSelf

老曹眼中的缓存技术

缓存是系统快速响应中的一种关键技术,是一组被保存起来以备将来使用的东西,介于应用开发和系统开发之间,是产品经理们经常顾及不到的地方,算是技术架构中的非功能性约束...

1522
来自专栏Python中文社区

构建一个pip安装的车辆路径显示的Python包

專 欄 ❈treelake,Python中文社区专栏作者。 简书: http://www.jianshu.com/u/66f24f2c0f36 ❈ 最近有一些...

24410

扫码关注云+社区

领取腾讯云代金券