Microservices and distributed transactions

Distributed transaction is a problem with the emergence of the service break up, why to do service split and what is a service, you can refer to here We know we do is for the distributed scenario, follow the CAP theory, so for this kind of transaction, across multiple service calling transaction has become a headache, Seata is a framework for dealing with transactions in a distributed environment.

Introduction to the history of Seata

Seata is a high-performance and easy-to-use distributed transaction framework developed by Alibaba for microservices architecture. GTX (Global Transaction Service, Taobao Transaction Constructor, Alibaba started to solve the internal framework of distributed Transaction in 2014) Alibaba launched TXC to cloud services in 2016 and renamed IT GTX) – Fescar – Seata (Simple Extensible Autonomous Transaction) Seata is already a hot project on Github. It is open source at the beginning of this year. Now, it has been released to version 0.8.0, has 11,000 stars, and is being updated rapidly. Believe that the future will be a universal distributed transaction solution.

Seata architecture

Seata currently has three transaction modes: AT, TCC and Saga. The default mode is AT, which is essentially an implementation of 2PC protocol. The differences of the three modes will be detailed in the following article. How does Seata solve distributed transactions

Suppose we now have a commodity shopping Business. For the background system, there are four services, namely Business(Business entrance), Storage (inventory service), Order (Order service) and Account (user service). Users purchase goods and place orders through Business, and the following processes will be experienced in the system:

For each service, two roles are represented:

TC
TM
Initiate, commit, rollback
RM
Initiate, submit, report

Seata processes a global transaction as follows:

  1. TM requests TC to initiate a global transaction, and TC returns an XID representing this global transaction.
  2. The XID is propagated in RPC to each service in the call chain.
  3. Each RM receives the XID and initiates a branch transaction to the TC, which returns an XID representing the branch transaction.
  4. The RM completes the local branch service, submits the service to the local branch, and reports the service to the TC.
  5. After the global transaction call chain is processed, TM initiates the submission or rollback of the global transaction to TC based on whether there are exceptions.

Roll back:

  1. Suppose an RM local transaction fails. The RM drives the local transaction rollback and reports the rollback to the TC.
  2. TM detects a branch transaction failure and initiates a global transaction rollback to TC.
  3. The TC sends a message to each RM to tell them all to roll back.
  4. The TC sends the result of the global transaction rollback to TM. The global transaction ends.

conclusion

  1. The community is active, and the number of STAR has reached W in just a few months. Currently, version 0.8 has been updated, and version 1.0 is available for online environment.
  2. Flexible, very simple to use with SEATA, especially with THE AT pattern, where distributed transactions can be implemented with almost one annotation.
  3. High performance, although one of the biggest drawbacks to using the 2PC protocol is performance, with multiple libraries locked at the same time causing a dramatic performance degradation. Seata is a big improvement on this, especially for TCC mode. Currently the AT model only does
  4. Currently, TCS do not support cluster deployment. Once TCS break down, distributed transactions cannot be processed in the entire system