Distributed Transaction Detailed 1 --- what is distributed transaction
Detailed Distributed Transaction Solution 2 ---
Detailed 3 --- Seata Distributed Transaction Distributed Transaction Framework
Describes a distributed transaction solutions, here it is necessary to introduce CAP theory.
1 CAP theory
How to perform a distributed transaction control?
CAP
theory is the basis for distributed transaction processing, understand the
CAP
theory helps us deal with research programs distributed transactions.
CAP
theory is: a distributed system design can only consistency
(Consistency)
, availability
(Availability)
, partition tolerance
(Partition Tolerance) that meet two kinds can not take into account the three.
FIG appreciated by the
CAP
Theory:
Consistency (Consistency)
: Service
A
,
B
,
C
three nodes are stored in the user data, three nodes need to maintain data consistency same time.
Availability (Availability)
: Service
A
,
B
,
C
three nodes, one node goes down does not affect the entire cluster to provide services, if only the service
A
node, when the service A
whole system will not provide service downtime, increase service
B
,
C
to ensure system availability.
Partition tolerance (Partition Tolerance)
: partition tolerance is to allow the system over the network to work together to solve the partition tolerance incomplete and inaccessible because of network issues cause data partition.
The inevitable emergence of distributed systems scenes multiple systems working in cooperation through the network, there will inevitably be interrupted between network nodes, network delay delay phenomenon, which once appeared to cause data to be spread over different nodes this is a network partition.
Distributed system can take into account the C , A , P ?
Under the premise to ensure consistency partition tolerance and availability not take into account, if you want to improve the usability of the system is necessary to increase the number of nodes, if you want to ensure data consistency necessary to achieve the consistent data for each node, the node the availability of better and more, but the data consistency worse.
Therefore, during the design of distributed systems, while meeting the
"
consistency
"
,
"
availability
"
and
"
partition tolerance
"
three is almost impossible.
CAP
What are combinations?
1 , CA
: give up the partition tolerance, coherence and availability relational database in accordance with
CA
design.
2 , AP
: give up consistency, strengthening the availability and partition tolerance, the pursuit of eventual consistency, many
NoSQL
database according to
AP
design.
Description: Here abandon Consistency means giving up strong consistency and strong consistency is successfully written immediately to check out the latest data. The pursuit of eventual consistency means that allows temporary data inconsistency, the same data as long as you can in the end-user acceptance time.
3 , CP
: give up the usability, coherence and partition tolerance, the system requires a number of strong consistency by
CP
design, such as inter-bank transfer, a transfer request to wait for the completion of both the banking system the entire transaction is completed.
Note: Due to network problems
CP
system may appear to be waiting for the timeout, timeout issue if there is no deal with the finishing system will be blocked.
to sum up:
In a distributed system design
AP
more often, namely to ensure the availability and partition tolerance, sacrifice strong consistency of the data (read after write immediately to the latest data), to ensure data consistency final. For example: order a refund, the refund success today, tomorrow credited into account, refund transactions completed as long as the user is within a predetermined acceptable time.
2 Solutions
2.1 two-phase commit protocol (2PC)
The emergence of two-phase commit protocol (to solve the problem of data consistency of distributed systems
2 Phase Commitment Protocol
), two-phase commit by the coordinator and participants composed of two stages and a total of three operations, part of a relational database such as the Oracle
,
MySQL
support two-phase commit protocol, this section explains relational database two-phase commit protocol.
reference:
2PC
：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
2PC
protocol flow chart:
1, the first stage: the preparation phase ( PREPARE )
Coordinator to inform participants ready to submit orders, the participants began to vote.
Coordinator to complete the preparatory work to respond to the coordinator
Yes
.
2, the second stage: submit (commit) / rollback (ROLLBACK) Stage
Coordinator commit instruction according to the results of the voting participants initiated the final.
If there is no participant is ready to initiate a rollback command.
A single example of reduction of stock:
1
, the application connecting the two data sources.
2
, an application launched by the transaction coordinator to two libraries
PREPARE
, two messages were received database to perform local transactions (logging), but does not commit, if it succeeds it will reply yes
, otherwise reply
NO
.
3
, transaction coordinator received a reply, as long as one party to reply
no
, respectively initiating transaction is rolled back to the participants, the participants began to roll back the transaction.
4
, transaction coordinator received a reply, reply all,
yes
, this time to initiate the participants to commit the transaction. If a participant fails to commit the transaction by one party transaction coordinator to initiate roll back the transaction.
2PC advantages:
- Achieve strong consistency, part of a relational database support ( the Oracle , MySQL , etc.).
Disadvantages:
- The entire transaction is executed by the coordinator need to coordinate among a plurality of nodes, an increase of the execution time of the transaction, poor performance.
There are solutions:
springboot +
Atomikos
or
Bitronix
3PC
mainly to resolve the coordinator and participant communication blocking problem arising, it is more than
2PC
messaging even more, performance is not high. Detailed reference
3PC
:
https://en.wikipedia.org/wiki/Three-phase_commit_protocol
2.2 Transaction compensation (TCC)
TCC
transaction compensation is based
2PC
business layer transaction control program implementation, it is
the Try
,
Confifirm
and
Cancel
first letter of the three words, have the following meanings:
1 , the Try inspection and operational resources reserved
Check before submitting completed transactions, and set aside a good resource.
2 , Confifirm determines to perform operational
To
try
stage reserved resources formally implemented.
3 , the Cancel to cancel execution of business operations
To
try
stage reserved resources to release.
The basic process is as follows:
Below minus inventory with a single business example to illustrate:
1、Try
Single-business collaboration is done by order service and inventory service,
try
to complete the review and set aside resources to stage order service and inventory services.
Check the conditions of service orders submitted orders currently meets (for example: currently existing order backlog is not allowed to submit new orders).
Inventory service checks whether there is currently adequate inventory, and lock resources.
2 , Confifirm
Order service and inventory service successful completion
Try
after the official start of the implementation of resource operations.
Write a message order service orders to the order.
Inventory service minus inventory.
3、Cancel
If you order service and inventory services are all one party fails appear to cancel the operation.
Orders need to remove the new service order information.
Inventory service will subtract inventory and then restored.
advantage:
- Eventually ensure data consistency, transaction control to achieve the business layer, good flexibility.
Disadvantages:
- High development costs, operations per transaction for each participant needs to implement try / confifirm / cancel three interfaces.
Note:
TCC
's
try / confifirm / cancel
interfaces must achieve idempotent, as in
the try
,
confifirm
,
the Cancel
to keep retrying after a failure.
What is Idempotence?
Idempotent operation referring to the same no matter how many times the request, the results are the same.
Idempotent operation implementation are:
1
, before the determination operation performed in a business method if no longer performed.
2
, the cache requests and results of the processing of all requests have been processed to return the result directly.
3
, plus a status field (untreated, treated) in a database table, and then determines when the unprocessed data processing operations.
2.3 Message queue implementation consistent with the final
The program is split into a plurality of locally distributed transaction to complete the transaction, and completed by the asynchronous message queue coordination, as shown below:
Reduce inventory below the single example to illustrate:
- Order service and inventory services complete the inspection and reserve resources.
- Order complete service in a local transaction records and add the Orders table add " reduce inventory task message " .
- The recording task transmitted by the timing of the table to the message MQ notification service performs subtraction stock inventory operations.
- Inventory service execution to reduce inventory, and records the execution status messages (in order to avoid repeat the message, check whether this message is executed before executing minus inventory).
- Inventory services to the MQ send a message to complete the inventory reduction.
- Delete the original order service added after receiving the news of the completion of inventory reduction " to reduce inventory task message " .
To achieve the final transaction is consistent requirement: reserve resources for success requires a formal theory is successful, if failed will be retried, requiring business execution method to achieve power and so on.
advantage:
- By the MQ in an asynchronous way to coordinate the completion of the transaction, higher performance.
- Without implementing try / confifirm / cancel interface development costs than TCC low.
Disadvantages:
- This way local transaction-based relational database to achieve, there will frequently read and write database records, database waste of resources, in addition to high concurrent operation is not the best option.
