Strong consistency solution
2PC (Synchronous short Transaction)
Phase 1: Submit transaction request (voting phase)
Phase 2: Perform transaction commit (COMMIT, ROLLBACK)
3PC
Phase 1: Commit or not Phase 2: Pre-commit Phase 3: Commit (COMMIT and rollback)
Final consistency solution
TCC (Synchronous short Transactions)
TCC mode splits a task into three operations: Try, Confirm, and Cancel (Services are highly intrusive).
In TCC mode, the master business service is responsible for initiating the process, while the slave business service provides the TCC mode Try, Confirm, and Cancel operations, and there is a transaction manager role responsible for controlling transaction consistency. As shown in figure:
Reliability message event
As shown in figure:
2. When service B receives a message, there are two cases:
A. If yes, the reverse message is returned.
B. No message is returned due to an exception or failure.
3. Service A receives the reverse message and sets the message to SUCCESS
4. Scheduled tasks Regularly check Sended messages and use custom rules (For example: send time, processing time and so on judgment) determine that Sended has failed and retry.
Here we must have a question, manually confirm the message failed to resend is not the same?
In fact, it is generally recommended in a distributed non-sending environment that if one service fails and the message keeps resending, it will eventually drag down the message queue and cause the whole cluster to fail (my opinion).
Saga mode (asynchronous long transaction)
Associative saga (There is no coordinator)
As shown in figure:
1. Request to the order system to complete the creation, and the order system sends messages to reduce inventory. 2. There are two situations in the inventory system: a. The inventory is successfully deducted and a message is sent to the payment system. B. If the inventory fails to be deducted, the compensation mechanism is triggered and a message is sent to the order system. 3. The payment system also has two situations: a. The payment is successful and the order is created successfully. B. Payment failure, triggering compensation mechanism, inventory reduction, and order creation failure.
Choreographed saga (Have a unified coordinator, and the coordinator needs to do HA)
As shown in figure:
The process is similar to the concordance.
Open source products
ServiceComb Pack
The ServiceComb Pack architecture is divided into three parts, one is Alpha (support HA) coordinator (support multiple instances to provide high availability support), the other is the Omega injected into the microservice instance, and the interaction protocol between Alpha and Omega. At present, The ServiceComb Pack supports Saga and TCC.
Omega includes Transaction Annotations and Transaction Interceptor that are relevant to analyzing a user’s distributed Transaction logic. Transaction Context, Transaction Callback, and Transaction Executor related to distributed Transaction execution; And the Transaction Transport module that communicates with Alpha.
Distributed Saga, TCC mode
Link: servicecomb.apache.org/cn/docs/dis… (There’s nothing better than official documentation 0.0)
Seata (2PC, XA optimization)
Seata architecture
A SEATA distributed transaction is a global transaction consisting of a number of branch transactions, which are usually just local transactions.
Transaction Coordinator (TC, HA support): Maintains the state of global and branch transactions and drives global commit or rollback.
Transaction manager TM: Defines the scope of the global transaction: starts the global transaction, commits or rolls back the global transaction.Resource Manager (RM): Manages the resources being processed by branch transactions, talks to TCS to register branch transactions and report the status of branch transactions, and drives commit or rollback of branch transactions.
A typical lifecycle for distributed transactions managed by Seata:
TM asked TC to start a new global transaction. TC generates xids that represent global transactions.
Xids propagate through the invocation chain of microservices.
RM registers the local transaction as a branch of the corresponding global transaction from XID to TC.
TM requires the TC to commit or roll back the corresponding global transaction for the XID.
TC drives all branch transactions under the global transaction corresponding to the XID to complete the branch commit or rollback.
Seata supports AT, TCC, SAGA, and XA transaction modes
AT (current common mode)
Note: AT does not properly handle the exceptions of the compensation mechanism. For example, in SEATA AT mode, if the rollback fails and the system cannot retry, you can only manually intervene through an alarm.
phase 1(pre)
phase 2 (commit) 
Cadence (workflow)
Cadence is a distributed, scalable, persistent, and highly available orchestration engine that performs asynchronous long-running business logic in a scalable and resilient manner.
Cadence: there are three main characters in the Activity: event handler | | task processor micro service | | actor | branch business executives
Workflow: the workflow arranged | | distributed transaction execution processes (supporting length transaction)
Starter: starts the workflow
cadence Activity
1. Support running any application code.
2, support long-term running tasks, using heartbeat to keep the state.
3. Support asynchronous execution.
4. Automatically retry based on the configured retry policy.
5. Routes to specified hosts or processes are supported.
6. Dispatch tasks through queues.
7. Support traffic limiting for workers.
8. Traffic limiting on queue is supported.
workflow
1. Support virtual object technology.
2. Support transactions.
(3) Arrange the activities.
4. Support to receive external events and react accordingly.
Stateful (including local variables and stacks).
6, support long-term operation.
7. Persistent clock support.
architecture
The history service: It receives instructions from the starter to start a workflow and then schedule a decision or an activity task. It also receives an execution response from an activity or workflow worker. The history service records the steps performed by the workflow in the Workflow Storage. Events that occur during execution are logged in The Events Storage, which also logs the status of workflow execution in the Visibility Storage.
Fornt End Service is a facade service that hides the complexity of internal services and provides a simple and friendly API.
Short transaction example:
It is worth mentioning that Cadence supports viewing call details during transaction execution
For additional details, see cadenceWorkflow.io
reference
Github.com/uber/cadenc… Cadenceworkwork.io/seta.io/Servicecomb.apache.orghigh Availability Extendable Microservices Architecture: Based on Dubbo, Spring Cloud, and Service Mesh