Spring Cloud Distributed Transaction Management

Spring Cloud Distributed Transaction Management

In the case of micro-services in full swing, more and more projects began to try to transform into a micro-service architecture, micro-services, which brings the convenience of project development, but also improve the operational difficulty and the probability of unreliable networks.

• Spring Cloud Distributed Transaction Management
• Single-Frame architecture
• Micro-Service Architecture
  • Advantages:
  • Disadvantages:
• Introduction of Distributed Transaction
• Distributed Transaction Solutions
  • Two-phase commit based on XA protocol
  • Message Transaction + Final consistency
  • TCC Programming Mode
• Specific implementation
  • LCN
  • Bytetcc

When talking about the advantages and disadvantages of micro-services, there is a contrast will be more obvious, first of all, say a single structure

Single-Frame architecture

In the monolithic architecture, the system usually adopts the layered architecture pattern (MVC), the persistence layer, the presentation layer and the business logic layer. The architecture primarily has the following issues:

1. Mutual access within the system, coupled tightly resulting in difficult to maintain;
2. The same technology stack is required for each business area, and it is difficult to quickly apply new technologies (e.g. using SSH is difficult to transform to SSM);
3. Any modifications to the system must be redeployed/upgraded together with the entire system;
4. When the system load increases, it is difficult to scale horizontally.
5. When there is a problem in the system, it will affect the whole system.

In order to overcome these shortcomings, the micro-service architecture emerges. MicroServices, also known as microservices architecture. MicroServices are small, self-serving services that work together.

Micro-Service Architecture Benefits:

1. Heterogeneity of Technology

In different services, different technologies can be used to develop each other, as long as the service can be coordinated with each other.

2. Elasticity

When one of the services in a microservices is unavailable, it does not affect the entire system, only affects the related function is not available

3. Expansion

Easy to scale, with a small number of services, easier to extend new features

4. Simplified deployment

An update deployment for a service that does not require the entire application to be redeployed

5. Can be combined

By combining multiple services, you can provide some new features

6. Replaceable

Because each microservices is small, re-implementing a service or simply deleting the service is actionable

Disadvantages:

1. High degree of complexity

Micro-service between the form of rest, RPC and other forms of interaction, relative to the monomer mode, need to consider the callee fault, overload, message loss and other anomalies, code logic more complex.

For transactional operations between MicroServices, because different microservices adopt different databases, it is impossible to use the transaction mechanism of the database itself to ensure consistency, requiring the introduction of two-phase commit technology.

At the same time, when there are a few common functions between microservices but cannot be extracted into microservices, each microservices usually needs to be duplicated, or at least code copied, to avoid the coupling between microservices and increase the development cost.

2. Operation and Maintenance complex

In the micro-service architecture, the system is composed of several independent micro-services, and a well-designed monitoring system is needed to monitor the operation status of each micro-service. Operation and maintenance personnel need to have a detailed understanding of the system to a better operation and maintenance system.

3. Impact Performance

Compared with the monolithic architecture, the communication delay can be greatly affected by the interaction between microservices through rest, RPC and other forms.

Introduction of Distributed Transaction

As said above

For transactional operations between MicroServices, because different microservices adopt different databases, it is impossible to use the transaction mechanism of the database itself to ensure consistency, requiring the introduction of two-phase commit technology.

In a single project, transaction control is easy, and it is difficult to achieve between multiple services

Assume the service invocation is as follows:

A B C D transactions are in each service control, how to do, unified coordination, to ensure the consistency of data?

Distributed transaction solution based on two-phase commit of XA protocol

XA is a distributed transaction protocol that is presented by the. Xa is broadly divided into two parts: the transaction manager and the local resource manager. Where the local resource manager is often implemented by the database, such as Oracle, DB2 these business databases have implemented XA interfaces, and the transaction manager as a global dispatcher, responsible for the submission and rollback of the local resources. The principle of XA implementation of distributed transactions is as follows:
First stage:

Phase II:

In general, the XA protocol is relatively simple, and once the business database implements the XA protocol, the cost of using distributed transactions is low. However, XA also has a fatal disadvantage, that is, performance is not ideal, especially in the transaction of single link, often high concurrency, XA can not meet high concurrency scenarios. XA currently in the commercial database support is relatively ideal, in the MySQL database support is not ideal, MySQL implementation of the XA, no record prepare phase log, primary and standby switch back to cause the main library and the standby data inconsistencies. Many NoSQL also do not support XA, which makes XA application scenarios very narrow.

Message Transaction + Final consistency

The so-called message transaction is a two-phase commit based on the message middleware, which is essentially a special use of the message middleware, which is to put the local transaction and send the message in a distributed transaction, to ensure that either the local operation succeeds successfully and the outgoing message succeeds, or both fail. This feature is supported by Open source ROCKETMQ.

The scheme uses the final consistent, sacrificing consistency, in exchange for a significant increase in performance. There is a risk of inconsistent data

TCC Programming Mode

The so-called TCC programming model is also a variant of the two-phase commit. TCC provides a programming framework that divides the entire business logic into three blocks: Try, confirm, and cancel three operations. Take the online order for example, the try phase will be to buckle inventory, the Confirm phase is to update the order status, if the update order failed, then into the cancel phase, will be to restore inventory. In short, the TCC is through the code to achieve a two-phase commit, different business scenarios write code is not the same, the complexity is not the same, therefore, this model is not very good to be reused.

Concrete implementation of LCN

Https://github.com/codingapi/tx-lcn

LCN分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强，支持所有的关系型数据库事务，支持多数据源，支持与第三方数据库框架一块使用（例如 sharding-jdbc），在使用框架的时候只需要添加分布式事务的注解即可，对业务的侵入性低。LCN框架主要是为微服务框架提供分布式事务的支持，在微服务框架上做了进一步的事务机制优化，在一些负载场景上LCN事务机制要比本地事务机制的性能更好，4.0以后框架开方了插件机制可以让更多的第三方框架支持进来

• 1
• 2

Currently LCN is version 4.1

Main Features:

• Support for various spring-based DB frameworks
• Compatible with Springcloud, Dubbo, Motan
• Use simple, low-dependency, code completely open source
• A strong consistency transaction framework based on facets
• High availability, modules can rely on the RPC module to do clustering, Txmanager can also do clustering
• Supports coexistence of local and distributed transactions
• Support transaction compensation mechanism, increase transaction compensation decision reminder

Adopt strong consistency scheme, the transaction either all succeeds, either all fails, guarantees the transaction consistency, the code is simple, the original project simply introduces the related jar package, and adds the annotation in the method which needs to participate in the transaction, saves the code transformation cost.

Spring Cloud Example:

Add dependency

<Properties><lcn.last.version>4.1.0</Lcn.last.version></Properties><Dependency><Groupid>com.codingapi</Groupid><Artifactid>transaction-springcloud</artifactid> <version>${ Lcn.last.version}</version></< Span class= "Hljs-title" >dependency><dependency> <groupid>com.codingapi</groupid> <artifactid>tx-plugins-db</artifactid> < version>${lcn.last.version}</ Version></DEPENDENCY>      

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16

Add annotations on transactions that need to be performed

@Override@TxTransaction(isStart = true)@Transactionalpublic int save() {}

• 1
• 2
• 3
• 4
• 5

This is the @TxTransaction(isStart = true) LCN transaction control annotation, which isStart = true indicates that the method is the initiator of the transaction for example, service a needs to invoke service B, service B needs to invoke service C, service A is the initiator of service, and the rest is the party, and the party simply @TxTransaction

The transaction management service needs to be started during testing txManager , for example see: https://www.txlcn.org

Bytetcc

Https://github.com/liuyangming/ByteTCC

BYTETCC is a distributed transaction manager based on the TCC (try/confirm/cancel) mechanism. Compatible with JTA, it is well-integrated with EJB, spring, and other containers (this document will take the spring container as an example).

BYTETCC characteristics
1, support the spring container declarative transaction management;
2. Support the General Affairs, TCC Affairs, Business compensation type Affairs and other affairs mechanism;
3, support multi-data source, cross-application, cross-server and other distributed transaction scenarios;
4, support long business;
5, Support Dubbo Service framework;
6, support spring cloud;

This implementation requires that the corresponding TCC (Try/confirm/cancel) method be written at the business level, and development requires some cost while some businesses may not be able to guarantee that data can be rolled back

View Example: Https://github.com/liuyangming/ByteTCC

Reference:

1. Https://github.com/codingapi/tx-lcn
2. Https://github.com/liuyangming/ByteTCC
3. Micro-Service Design (Sam Newman)

Spring Cloud Distributed Transaction Management