Convert Figma logo to code with AI

changmingxie logotcc-transaction

tcc-transaction是TCC型事务java实现

5,768
2,791
5,768
33

Top Related Projects

10,038

A distributed transaction framework, supports workflow, saga, tcc, xa, 2-phase message, outbox patterns, supports many languages.

:fire: Seata is an easy-to-use, high-performance, open source distributed transaction solution.

2,896

ByteTCC is a distributed transaction manager based on the TCC(Try/Confirm/Cancel) mechanism. It’s compatible with the JTA specification. User guide: https://github.com/liuyangming/ByteTCC/wiki

Quick Overview

The changmingxie/tcc-transaction project is a Java implementation of the Transactional Compensation Consistency (TCC) pattern, which is a distributed transaction management framework. It provides a way to handle complex business transactions that span multiple services or systems, ensuring data consistency and reliability.

Pros

  • Distributed Transaction Management: The project offers a robust solution for managing distributed transactions, making it suitable for complex, microservices-based architectures.
  • Customizable Compensation Logic: Developers can easily define their own compensation logic for each business operation, allowing for flexible and tailored transaction handling.
  • Annotation-based Configuration: The project uses annotations to simplify the configuration and integration of the TCC framework, reducing boilerplate code.
  • Extensible Design: The project's modular design allows for easy integration with various data sources and transaction managers, making it adaptable to different use cases.

Cons

  • Learning Curve: Developers may need to invest time in understanding the TCC pattern and how to properly integrate it into their application architecture.
  • Potential Performance Impact: The overhead of the TCC framework may impact the overall performance of the application, especially for high-throughput scenarios.
  • Limited Documentation: The project's documentation could be more comprehensive, making it challenging for new users to get started quickly.
  • Lack of Active Maintenance: The project appears to have limited active maintenance, which may raise concerns about long-term support and updates.

Code Examples

Defining a TCC-based Service Method

@Transactional(type = TransactionType.TCC)
public void transferMoney(String from, String to, BigDecimal amount) {
    // Try phase: Deduct money from the "from" account
    accountRepository.deductBalance(from, amount);

    // Confirm phase: Add money to the "to" account
    accountRepository.addBalance(to, amount);
}

This example demonstrates how to define a TCC-based service method using the project's annotations. The @Transactional annotation specifies the transaction type as TCC, and the method implementation includes the try and confirm phases.

Implementing Compensation Logic

@Component
public class AccountTransferCompensation implements Compensable {
    @Override
    public void compensate(TransactionContext context) {
        // Compensation logic: Revert the money transfer
        String from = context.getActionContext().getParameter("from");
        String to = context.getActionContext().getParameter("to");
        BigDecimal amount = context.getActionContext().getParameter("amount");

        accountRepository.addBalance(from, amount);
        accountRepository.deductBalance(to, amount);
    }
}

This example shows how to implement the compensation logic for the money transfer operation. The AccountTransferCompensation class implements the Compensable interface and provides the necessary logic to revert the money transfer in case of a failure.

Configuring the TCC Transaction Manager

@Configuration
public class TccTransactionConfiguration {
    @Bean
    public TransactionManager transactionManager(List<Compensable> compensables) {
        TccTransactionManager transactionManager = new TccTransactionManager();
        transactionManager.setCompensables(compensables);
        return transactionManager;
    }
}

This example demonstrates how to configure the TCC transaction manager in the application's Spring configuration. The TccTransactionConfiguration class sets up the TccTransactionManager and injects the list of Compensable implementations.

Getting Started

To get started with the changmingxie/tcc-transaction project, follow these steps:

  1. Add the project dependency to your Java application's build configuration (e.g., Maven or Gradle):

    <dependency>
        <groupId>com.github.changmingxie</groupId>
        <artifactId>tcc-transaction</artifactId>
        <version>2.1.2</version>
    </dependency>
    
  2. Configure the TCC transaction manager in your application's Spring configuration:

    @Configuration
    public class TccTransactionConfiguration {
        @Bean
        public TransactionManager transactionManager(List<Compens
    

Competitor Comparisons

10,038

A distributed transaction framework, supports workflow, saga, tcc, xa, 2-phase message, outbox patterns, supports many languages.

Pros of dtm

  • Supports multiple programming languages (Go, Java, Python, PHP, Node.js)
  • Offers various distributed transaction patterns (2PC, Saga, TCC, XA)
  • Provides a simple API and easy integration

Cons of dtm

  • Relatively newer project with less production usage
  • Documentation may not be as comprehensive as tcc-transaction

Code Comparison

dtm (Go):

saga := dtmcli.NewSaga(DtmServer, gid).
    Add(busi.Busi+"/TransOut", busi.Busi+"/TransOutCompensate", req).
    Add(busi.Busi+"/TransIn", busi.Busi+"/TransInCompensate", req)
err := saga.Submit()

tcc-transaction (Java):

@Compensable(confirmMethod = "confirmOrderCreation", cancelMethod = "cancelOrderCreation")
public String createOrder(Order order) {
    // Business logic
}

Both projects aim to solve distributed transaction problems, but dtm offers a more versatile solution with support for multiple languages and transaction patterns. tcc-transaction focuses specifically on the TCC (Try-Confirm-Cancel) pattern and is primarily for Java applications. dtm's API appears more straightforward, while tcc-transaction relies on annotations for transaction management. The choice between the two depends on specific project requirements, language preferences, and desired transaction patterns.

:fire: Seata is an easy-to-use, high-performance, open source distributed transaction solution.

Pros of Seata

  • More comprehensive distributed transaction solution, supporting multiple transaction modes (AT, TCC, SAGA, XA)
  • Better integration with popular frameworks and cloud-native environments
  • Larger community support and active development as an Apache Incubator project

Cons of Seata

  • Higher complexity and steeper learning curve due to its extensive features
  • Potentially higher overhead for simpler use cases compared to TCC-Transaction

Code Comparison

TCC-Transaction:

@Compensable(confirmMethod = "confirmMethod", cancelMethod = "cancelMethod")
public void tryMethod() {
    // Business logic
}

Seata:

@GlobalTransactional
public void businessMethod() {
    // Business logic
}

Key Differences

  • TCC-Transaction focuses solely on TCC (Try-Confirm-Cancel) pattern, while Seata offers multiple transaction modes
  • Seata provides more built-in integrations with various frameworks and databases
  • TCC-Transaction has a simpler API and is easier to implement for TCC-specific use cases
  • Seata offers more advanced features like transaction coordination and global locking

Use Case Recommendations

  • Choose TCC-Transaction for simpler projects primarily requiring TCC pattern
  • Opt for Seata in complex distributed systems needing multiple transaction modes and extensive integrations
2,896

ByteTCC is a distributed transaction manager based on the TCC(Try/Confirm/Cancel) mechanism. It’s compatible with the JTA specification. User guide: https://github.com/liuyangming/ByteTCC/wiki

Pros of ByteTCC

  • More comprehensive documentation and examples
  • Better support for multiple databases and messaging systems
  • More active development and community engagement

Cons of ByteTCC

  • Slightly more complex configuration process
  • Less integration with popular frameworks like Spring Boot
  • Steeper learning curve for beginners

Code Comparison

ByteTCC:

@Compensable(confirmMethod = "confirmOrder", cancelMethod = "cancelOrder")
public void createOrder(Order order) {
    // Business logic
}

tcc-transaction:

@Compensable(confirmMethod = "confirmCreateOrder", cancelMethod = "cancelCreateOrder")
public void createOrder(Order order) {
    // Business logic
}

Both projects use similar annotations for defining compensable methods, but ByteTCC offers more flexibility in method naming conventions.

Summary

ByteTCC and tcc-transaction are both TCC (Try-Confirm-Cancel) transaction frameworks for distributed systems. ByteTCC offers more comprehensive features and better support for various databases and messaging systems, but it may be more complex to set up and use. tcc-transaction, on the other hand, is simpler and integrates better with Spring Boot, making it a good choice for projects already using the Spring ecosystem. The choice between the two depends on the specific requirements of your project and your team's familiarity with distributed transaction concepts.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

TCC-TRANSACTION

TCC-TRANSACTION是什么

TCC-TRANSACTION是一款开源的微服务架构下的TCC型分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。

  • Try: 尝试执行业务,完成所有业务检查(一致性),预留必须业务资源(准隔离性)
  • Confirm: 确认执行业务,不作任何业务检查,只使用Try阶段预留的业务资源,满足幂等性
  • Cancel: 取消执行业务,释放Try阶段预留的业务资源,满足幂等性

微服务架构中分布式事务问题

随着传统的单体架的构微服务化,原本单体架构中不同模块,被拆分为若干个功能简单、松耦合的服务。
系统微服务化后,内部可能需要调用多个服务并操作多个数据库实现,服务调用的分布式事务问题变的非常突出。

比如支付退款场景需要从各分账方退回平台收益户(退分账),再退还给付款方。其中**退分账**阶段, 涉及从多个分账方(商家1收益户,商家2收益户,商家3收益户,平台手续费账户)扣款,这些账户分布在不同数据库, 比如商家3收益户扣款失败,其他成功扣款需要回滚,这里需要分布式事务保证一致性。 支付退款流程

如何解决

如何解决上面**退分账**中分布式事务问题呢? 选择使用tcc-transaction框架,执行流程如下:

  • Try:
    商家1收益户->冻结分账金额
    商家2收益户->冻结分账金额
    商家3收益户->冻结分账金额
    平台手续费->冻结手续费
  • Try成功 => Confirm:
    商家1收益户->扣除分账金额
    商家2收益户->扣除分账金额
    商家3收益户->扣除分账金额
    平台手续费->扣除手续费
    平台收益户-> 增加金额(总分账金额+手续费)
  • Try失败 => Cancel:
    商家1收益户->解冻分账金额
    商家2收益户->解冻分账金额
    商家3收益户->解冻分账金额
    平台手续费->解冻手续费

工作原理

TCC原理

第一阶段:主业务服务分别调用所有从业务的 try 操作,并在活动管理器中登记所有从业务服务。当所有从业务服务的 try 操作都调用成功或者某个从业务服务的 try 操作失败,进入第二阶段。
第二阶段:活动管理器根据第一阶段的执行结果来执行 confirm 或 cancel 操作。
如果第一阶段所有 try 操作都成功,则活动管理器调用所有从业务活动的 confirm操作。否则调用所有从业务服务的 cancel 操作。
需要注意的是第二阶段 confirm 或 cancel 操作本身也是满足最终一致性的过程,在调用 confirm 或 cancel 的时候也可能因为某种原因(比如网络)导致调用失败,所以需要活动管理支持重试的能力,同时这也就要求 confirm 和 cancel 操作具有幂等性。

快速开始

官网
快速开始
最新可用版本2.x

常见问题

常见问题

讨论群

钉钉扫码入群

钉钉扫码入群