preface

While previous articles in this series have covered communication between distributed services, distributed transactions are the next topic we will learn about together, go.

Database transaction is almost unavoidable in the existing large and small systems, more or less there will always be some business associated with a piece; For the application scenarios and operations of single-machine transactions, I believe my friends have been skilled enough; With the popularity of distributed and micro-service development mode, distributed transaction landing has also become a necessary skill for programmers, the next few articles together to learn and practice.

The body of the

1. Transaction review

1. 1 Introduction to Business

A common understanding is that a group of data operations (add, delete, change, check) to see a logical unit, either all or none of the execution, to ensure data consistency.

1.2 Transaction Characteristics (ACID)

  • Atomicity

    When all operations within a transaction either succeed together or fail together (or roll back); Such as transaction classic transfer case: A to B transfer, A deducted the money, but B did not receive; This error is not acceptable and will eventually be rolled back, which is the importance of atomicity.

  • Consistency

    Refers to the state of the transaction before and after the execution of the same, such as transaction classic transfer case: A to B mutual transfer, no matter how to transfer, the final sum of the two money is still the same;

  • “Durability”

    Once a transaction is committed, the data is permanently stored and cannot be rolled back.

  • Isolation

    The operation of multiple concurrent transactions does not interfere with each other. However, concurrent transactions may cause dirty read, non-repeatable read, and phantom read problems. The transaction isolation level is used to deal with data read problems based on service conditions.

1.3 Transaction Isolation Level

  • Read uncommitted

    When a transaction reads data from another uncommitted transaction. Dirty data may be read.

    Transfer case: A is transferring the money to B, originally 1000 was transferred, but A entered more zeros to turn it into 10000, but the transaction has not been committed yet. But at this time, B queried that 10000 was transferred, but after A cancelled the rollback of the transaction, B could not query the transferred data again. This is called dirty reading

  • Read committed

    When a transaction can only read data committed by another transaction, thus solving the dirty read problem. However, the data may be unrepeatable.

    Transfer case: A wants to transfer 1000 yuan to B. A first checks the balance and finds 1000 yuan, and then begins to transfer money to B. But at this time, through the automatic payment function of A’s home electricity fee, 200 yuan is automatically deducted from A’s account to pay the electricity fee and submit it. When A transferred to submit and reconfirmed the balance, the money was less than 200. In this case, the results of multiple queries in the same transaction are inconsistent, which is called non-repeatable reads.

  • Repeatable read (Repeatable read)

    Once a transaction is started, other transactions are not allowed to modify the transaction, thus solving the non-repeatable read problem. But may lead to data magic read;

    Transfer case: A often transfers money to B. At the end of the year, the account needs to be checked, and then A transaction is opened for query and statistics. At the beginning, the query is only 10 transfer records, but when the statistics are ready, A needs to transfer money to B for emergency, so A new record is added and submitted. The audit transaction is being counted, and it was found that the transfer amount and the 10 transfer records did not match. This situation is called phantom reading

  • Serializable

    Refers to the transaction can only be serial execution, like a queue, queuing, this solves the magic read problem, but this level of concurrency performance is not high, non-special needs, this level is generally not used.

2. Distributed transaction scenario

A project corresponds to a database, this single machine business is usually dealt with more; Here is a summary of the scenarios where distributed transactions occur.

2.1 Multiple databases for a project

This situation is generally a small amount of concurrent, but the amount of data is large, such as some acquisition equipment data to do real-time analysis of the system, such as sensor data, motor state, after a period of time, the amount of data will be a lot, resulting in low efficiency of a single database, so it is usually used for sub-service storage.

As shown in the figure above, if there is a need to manipulate both DB1 data and DB2 data, ensuring that both operations either succeed or fail requires a transaction, which, unlike a single system (one project, one database) transaction, requires a distributed transaction.

2.2 One database for multiple projects

Some systems need to separate business development and deployment to facilitate code management and later maintenance. In the case of database resources, a common database can be shared. In this case, if there are transaction operations, distributed transactions are also required for processing.

2.3 Multiple databases for multiple projects

This is actually a microservice model, which divides projects into businesses, and each business corresponds to a database. In this scenario, the transactions between projects must be distributed

3. The CAP

3.1 introduction

In a distributed application scenario, services are unavailable due to uncontrollable factors such as network failure, device breakdown, and natural disasters. In this case, choices must be made. The whole system should not collapse due to the failure of a single service. Generally, CAP theory becomes a trade-off between distributed indicators. According to the business requirements of the system, two of the indicators can be satisfied. The diagram below:

CAP is an abbreviation for Consistency, Availability, and PartitionTolerance. The meanings are as follows:

  • C(Consistency- Consistency) : indicates that after a write operation, any node can obtain the latest data status when reading data. To ensure data consistency, resources are locked for a short time during data synchronization to avoid data inconsistency caused by old data. However, this may cause services to be unavailable in a short time.
  • A(availability-availability) : When any operation is initiated, the response result can be obtained without response timeout or error. Even data should be available during synchronization, i.e. it is better to get old data than to report errors.
  • P(PartitionTolerance- Partition fault tolerance) : The partition here refers to the network partition. Usually in a distributed system, nodes are deployed to different subnets. Due to the uncontrollability of the network, the communication between nodes may fail. But in the design of such a system, we should consider this situation, to ensure the normal service, which can be understood as usually we say high availability; This index is necessary for a distributed system, otherwise it cannot be called a high availability system.
3.2 CAP portfolio

In fact, according to the above overview, C(consistency) and A(availability) are mutually exclusive. In order to ensure consistency, resources will be locked and unavailable for A short period of time, while the requirement of availability is that there must be A corresponding response to the operation, even if the data obtained is not the latest, in order to ensure availability. P(partition fault tolerance) is a necessary index in distributed systems, so the common combination in distributed systems is CP and AP.

  • CP: Give up availability and focus on consistency and partition fault tolerance. In fact, this is the so-called strong consistency, which may be used in the strong consistency business scenario such as inter-bank transfer. The specific choice depends on the business scenario.
  • AP: Abandon strong consistency and focus on availability and partition fault tolerance, which is the choice for most distributed business scenarios today, as long as final consistency is guaranteed (Base theory).
3.3 Briefly understand BASE theory

BASE, short for Basically Available, Soft State, and Eventually Consistent, is an extension of AP that allows partial service to become unavailable in the event of a failure, But keep the core services up and running. For the data, the inconsistency is allowed for a certain period of time, and the final consistency can be guaranteed through the intermediate state (soft state) transition.

For example:

Basically Available: For example, a system needs to send a message notification when a user is successfully registered, and allow the message to be unsuccessful, but the core function needs to be Available when registered.

Soft states: The most commonly seen Soft states are: “in payment”, “data processing”, etc., these states are to meet the availability and eventual consistent increase in the transition State.

Eventually Consistent: For example, in the purchase of goods, the payment process will show “in payment”, Eventually will show “payment success”, in fact, this time in the end your account and the receiving account of the transaction will Eventually be Consistent, this transaction can be understood as “flexible transaction”.

4. Common solutions for distributed transactions

  • Two-phase Commit Protocol (2PC), also known as two-phase commit Protocol, is a strong consistency solution. This is complemented by a solution called 3PC.
  • TCC (Try Confirm Cancel), compensation transaction.
  • Local message table
  • The message transaction
  • Best effort notice

Here do not detail, follow up one by one to break, and ultimately to use the code landing.

conclusion

This article is just a beginning, mainly a general review of distributed transactions commonly encountered knowledge, followed by the implementation of various solutions, together with code.

A handsome guy who was made ugly by the program. Follow “Code Variety Circle “and learn ~~~ with me