- 总述 -
咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇,讲对前面的内容查缺补漏和总结,最后对市面的一些开源框架做一些介绍。
- 查缺补漏 -
柔性事务分补偿型事务和通知型事务。但对补偿型事务没有进行详细介绍,那什么是补偿型事务呢,在Atomikos 公司Guy Pardon的论文《Business_Activities》中有这样的描述: 大致含义是,"补偿是一个独立的支持ACID特性的本地事务,用于在逻辑上取消了先前ACID交互的影响。对于一个长事务来说,基于补偿的方法可将事务资源锁定时间保持在最低程度,从而避免了事务资源长期占用等缺点。”。
咱们前面文章说了不推荐TCC,并且认为Seata的AT模式从理论上来说更像是Saga的变种,而非TCC的变种。目前有很多资料自行将TCC分了几个分支:
原始论文《Life beyond Distributed Transactions》和 Atomikos 官网上并没有类似的划分,这些划分其实是一些公司在内部实践中,自行提出的概念。但是并未找到比较大的公司进行背书。所以其实咱们从论文上去看:
咱们说过Saga设计必须遵循允许空补偿、保持幂等性、防止资源悬挂三个策略,因为Saga事务不保证隔离性,在极端情况下可能由于脏写无法完成回滚操作。比如举一个极端的例子, 分布式事务内先给用户A充值, 然后给用户B扣减余额, 如果在给A用户充值成功, 在事务提交以前, A用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了。这就是缺乏隔离性造成的典型的问题, 实践中一般的应对方法是:
Saga 实现分两种,一种是Saga 状态机实现,一种是Saga AOP Proxy实现,但是前文缺少对比,补充如下:
Saga 状态机实现,在关于参与者服务编排实现又有集中式和协同式两种分支,他们的对比详情如下:
4. TCC VS Saga
补偿型事务事务主要分TCC 和 Saga。咱们前文中说到Saga 没有Try行为,直接commit,所以会留下原始事务操作痕迹。TCC Cancel是完美补偿的Rollback,补偿操作会彻底清理之前的原始事务操作,用户是感知不到事务取消之前的状态信息的。最近回看文章时,发现比较多人对此有疑问,所以进行补充诠释下:
单数据库事务可以满足事务ACID 四个特性,提供强一致性保证,但在分布式事务要完全遵循 ACID 特性会比较困难。在互联网时代中,我们通常追求分布式系统的高可用和高吞吐,所以分布式事务一般选择最终一致性。 咱们把提供强一致性的事务称之为刚性事务,把提供最终一致性的事务称之为柔性事务。刚性事务可以完全满足 ACID 四个特性,柔性事务对事务的 ACID 特性的支持情况如下:
在分布式系统中,CAP理论通常是指导思维,而BASE理论是CAP理论中的AP延申,是对 CAP 中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。而柔性事务其实就是BASE理论的实践产物。因为分布式事务难免会对系统造成一定的性能损耗,所以在互联网高可用和高吞吐的要求下。我们通常处理分布式事务的原则是:业务规避 > BASE柔性事务 > CP刚性事务。柔性事务通常推荐 同步Saga、异步事务消息;刚性事务推荐 2PC实现。
- 开源框架推荐 -
从结论上我们可以看出业务规避其实已经没有了分布式事务的必要性,因此如果实在无法业务规避或者规避成本更加昂贵下,我们必须有分布式事务来处理数据一致性问题。这时我们需要选择一个合适的分布式框架来处理事务。我对业界常见分布式事务做了一定比较,其实有大厂背景背书、经过大量生产实践、开源组件的只有华为的ServiceComb Saga、阿里的Seata、Apache Camel Saga。但是华为ServiceComb Saga和 Apache Camel Saga只提供了Saga实现,而阿里Seata提供了AT、Saga、XA(刚出不久,不建议马上使用)。从广度上来说,其实Seata是占比较大的优势,我刚好对Seata又有比较深的研究,所以强烈推荐Seata。
本文来源于:奈学开发者社区,如有侵权请联系我删除!
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。