谈谈分布式事务TCC

TCC(Try-Confirm-Cancel)是一种分布式事务处理模型,用于解决在分布式系统中执行跨服务或跨资源的事务时的一致性问题。与传统的两阶段提交(2PC)和三阶段提交(3PC)相比,TCC提供了一种更为灵活和适应性更强的解决方案,尤其适用于长事务处理和需要高度一致性保证的业务场景。

### 工作原理

TCC模型将事务分为三个阶段:尝试(Try)、确认(Confirm)和取消(Cancel)。

1. **Try 阶段**:在这个阶段,事务的各个参与者检查事务请求的有效性,并预留必要的资源以保证事务可以被成功执行。这个阶段不会实际修改数据,只是做好准备工作,确保Confirm阶段可以顺利完成。

2. **Confirm 阶段**:如果Try阶段所有参与者都成功预留了资源,则进入Confirm阶段。在这个阶段,实际执行事务操作,修改数据,并释放在Try阶段预留的资源。如果所有参与者都成功执行了Confirm操作,那么整个事务被认为是成功的。

3. **Cancel 阶段**:如果在Try阶段的任何时刻发现事务无法成功完成(比如某个参与者无法预留足够的资源),或者在Confirm阶段之前发生了其他错误,那么事务将进入Cancel阶段。在这个阶段,所有参与者将撤销在Try阶段所做的准备工作,释放预留的资源,确保系统回到事务开始前的状态。

### 特点

- **强一致性**:TCC通过明确的业务逻辑分阶段处理,确保了事务的强一致性。
- **灵活性**:TCC模型允许开发者根据具体业务需求设计Try、Confirm和Cancel这三个阶段的逻辑,提供了较高的灵活性。
- **适用于长事务**:由于TCC不是基于锁的机制,而是通过业务逻辑来保留和释放资源,因此更适合处理执行时间较长的事务。
- **系统复杂度增加**:实现TCC模型需要在业务层面上进行细致的设计和编码,会增加系统的复杂度。

### 应用场景

TCC模型特别适用于分布式系统中那些需要强一致性保证,且参与者之间相互独立、事务执行时间可能较长的场景。例如,电商平台的下单操作,可能需要同步更新库存、记录订单、扣减用户余额等,这些操作跨多个服务或系统,使用TCC模型可以有效确保事务的一致性和完整性。

总的来说,TCC是一种通过业务逻辑来确保分布式事务一致性的模型,虽然实现复杂,但提供了高度的灵活性和强一致性保证,适用于复杂的分布式系统场景。

Hmily是柔性分布式事务解决方案,提供了TCC 与 TAC 模式。它以零侵入以及快速集成方式能够方便的被业务进行整合。在性能上,日志存储异步(可选)以及使用异步执行的方式,不损耗业务方法方法。之前是由我个人开发,目前由我在京东数科已经重新启动,未来将会是金融场景的分布式事务解决方案。 功能: 高可靠性:支持分布式场景下,事务异常回滚,超时异常恢复,防止事务悬挂 易用性:提供零侵入性式的 Spring-Boot,Spring-Namespace 快速与业务系统集成 高性能:去中心化设计,与业务系统完全融合,天然支持集群部署 可观测性:Metrics多项指标性能监控,以及admin管理后台UI展示 多种RPC:支持 Dubbo,SpringCloud,Motan,Sofa-rpc,brpc,tars 等知名RPC框架 日志存储:支持 mysql,oracle,mongodb,redis,zookeeper 等方式 复杂场景:支持RPC嵌套调用事务 必要前提: 必须使用 JDK8+ TCC模式必须要使用一款 RPC 框架,比如:Dubbo,SpringCloud,Montan TCC模式 当使用TCC模式的时候,用户根据自身业务需求提供 try,confirm,cancel 等三个方法, 并且 confirm,cancel 方法由自身完成实现,框架只是负责来调用,来达到事务的一致性。 TAC模式 当用户使用TAC模式的时候,用户必须使用关系型数据库来进行业务操作,框架会自动生成回滚SQL,当业务异常的时候,会执行回滚SQL来达到事务的一致性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值