什么是柔性事务?

概念

柔性事务,是业内解决分布式事务的主要方案。所谓柔性事务,相比较与数据库事务中的ACID这种刚性事务来说,柔性事务保证的是“基本可用,最终一致。”这其实就是基于BASE理论,保证数据的最终一致性。

虽然柔性事务并不像刚性事务那样完全遵循ACID,但是,也是部分遵循ACID的,简单看一下关于ACID四个属性,柔性事务的支撑程度:

原子性:严格遵循
一致性:事务完成后的一致性严格遵循;事务中的一致性可适当放宽
隔离性:并行事务间不可影响;事务中间结果可见性允许安全放宽
持久性:严格遵循

在业内,关于柔性事务,最主要的有以下三种类型:异步确保型、补偿型、最大努力通知型。


柔性事务的分类

柔性事务分为:两阶段型、补偿型、异步确保型、最大努力通知型。

  • 两阶段型 分布式事务二阶段提交,对应技术上的 XA、JTA/JTS,这是分布式环境下事务处理的典型模式。

  • 补偿型 TCC 型事务(Try-Confirm-Cancel)可以归为补偿型。在 Try 成功的情况下,如果事务要回滚,Cancel 将作为一个补偿机制,回滚 Try 操作;TCC 各操作事务本地化,且尽早提交(没有两阶段约束);当全局事务要求回滚时,通过另一个本地事务实现“补偿”行为。 TCC 是将资源层的二阶段提交协议转换到业务层,成为业务模型中的一部分。

  • 异步确保型 将一些有同步冲突的事务操作变为异步操作,避免对数据库事务的争用,如消息事务机制。

  • 最大努力通知型 通过通知服务器(消息通知)进行,允许失败,有补充机制。


想要实现柔性事务,有几个基础条件需要具备,以下介绍几个柔性事务实现的基础。

柔性事务实现的基础

1、可查询操作

可查询操作,几乎是所有的分布式解决方案都需要的。
举一个常见的分布式场景的例子,如订单处理这一功能:

可查询操作,几乎是所有的分布式解决方案都需要的。

举一个常见的分布式场景的例子,如订单处理这一功能:

 /**
     * 支付订单处理
     **/
    public void completeOrder() {
        forderDao.update();//订单服务本地更新订单状态
        accountService.update();//调用资金账户服务给资金帐户加款
        pointService.update();//调用积分服务给积分帐户增加积分
        accountingService.insert();// 调用会计服务向会计系统写入会计原始凭证
        merchantNotifyService.notify();// 调用商户通知服务向商户发送支付结果通知
    }

以上这个支付订单处理的例子中,除了 订单服务本地更新订单状态 以外的所有操作,都需要调用RPC接口来执行,这种情况单纯的本地事务就无法保证数据的一致性了。就需要引入分布式事务。

在分布式事务执行过程中,如果某一个步骤执行出错,就需要明确的知道其他几个操作的处理情况,这就需要其他的服务都能够提供查询接口,保证可以通过查询来判断操作的处理情况。

2、幂等操作

幂等性,其实是一个数学概念。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数,如:f(f(x))= f(x)

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说,同一个方法使用同样的参数,调用多次产生的业务结果与调用一次产生的业务结果相同。

这一个要求其实也比较好理解,因为要保证数据的最终一致性,很多解决防范都会有很多重试的操作,如果一个方法不保证幂等,那么将无法被重试。

幂等操作的实现方式有多种,如在系统中缓存所有的请求与处理结果、检测到重复操作后,直接返回上一次的处理结果等。

3、可补偿操作

提到事务,为了保证原子性,就可能发生commit和rollback,那么在分布式事务中,要想进行rollback,就需要提供可补偿操作。

比如上面的订单处理的例子中,在`调用积分服务给积分帐户增加积分`操作执行之后,经过分布式事务协调,最终决定回滚整个事务,那么就需要提供一个`调用积分服务给积分帐户扣减积分`的操作,

并且,补偿操作同时也需要满足幂等性。

4、TCC操作

TCC 即 Try-Confirm-Cancel.

Try: 尝试执行业务

完成所有业务检査(一致性)预留必须业务资源(准隔离性)

Confirm:确认执行业务

真正执行业务 不作任何业务检査 只使用Try阶段预留的业务资源 Confirm操作要满足冪等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源,Cancel操作要满足冪等性
这种类型和可补偿操作类似,就是提供一种提交和回滚的机制。是一种典型的两阶段类型的操作。这里说的两阶段类型操作并不是指2PC,他和2PC还是有区别的。

总结

  • 17
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
分布式事务是指在分布式系统中,涉及多个微服务或数据库的操作需要保持一致性的事务处理。柔性事务是指在分布式事务中,允许部分操作成功而部分操作失败,即使有部分操作失败,也可以保证事务的最终一致性。而刚性事务则要求所有操作都必须成功,否则整个事务将回滚到初始状态。 在分布式系统中,柔性事务的实现方式通常有两种:补偿模式和消息模式。补偿模式通过在事务提交之前执行预留操作来实现柔性,如果有操作失败,可以通过执行补偿操作来回滚到之前的状态。消息模式则是通过将事务操作转化为消息并发送到消息队列中,各个微服务按照消息的顺序依次处理,如果某个操作失败,可以通过重新消费消息来进行补偿。 相比之下,刚性事务要求所有操作都必须成功,否则整个事务将回滚到初始状态。刚性事务通常使用两阶段提交(Two-Phase Commit,2PC)协议来实现,在第一阶段,所有参与者向协调者发送准备请求,并等待协调者的决策;在第二阶段,协调者根据所有参与者的准备情况,发送提交或回滚请求给所有参与者。 选择柔性事务还是刚性事务要根据具体的业务需求和系统特点来决定。柔性事务可以提高系统的可用性和性能,但可能牺牲了一致性的强度;而刚性事务可以保证强一致性,但可能会降低系统的可用性和性能。因此,在设计分布式系统时需要综合考虑各种因素,选择适合的事务处理机制。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小徐很努力

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值