From distributed transaction to cap theory and base theory

Objective

I detail the isolation level of database transactions in two articles, the isolation level for database transactions and transactions and the re-discussion of database transaction isolation levels. This article will start with a distributed transaction, as well as the cap theory and base theory.

Distributed transactions

With the development of distributed computing, transactions have been widely used in the field of distributed computing. In a stand-alone database, we can easily implement a set of transaction processing systems that meet the acid characteristics, but in a distributed database, where the data is scattered across different machines, how to do distributed transaction processing of these data is of great challenge.

A distributed transaction is a contributor to a transaction, a server that supports transactions, a resource server, and a transaction manager, respectively, on different nodes of a distributed system, typically involving operations on multiple data sources or business systems in a distributed transaction.

We can imagine the most typical distributed transaction scenario. A cross-bank transfer operation, such as a transfer from CCB's account to the ABC account, which involves the need to call services on two different nodes in the distributed 1. Withdrawal Service 2. Deposit services for the target account.  The two services are stateless and are kept separate from each other, and together constitute a completed distributed transaction. If a call to the first withdrawal service succeeds, and the deposit service for the target account fails for one reason, it must be rolled back to the state before the withdrawal, otherwise the user will find that the money in the account is missing.

a distributed transaction can be seen as being made up of multiple distributed sequences of operations . We call these sequence of operations a child transaction . Therefore, distributed transactions can also be called nested transactions, while also having an acid-like transactional nature. However, in a distributed transaction, the execution of each sub-transaction is distributed. Therefore, it is difficult to achieve distributed transactions that guarantee acid properties.

In a set of traffic, high concurrency distributed systems, if you want to implement a strict acid characteristics of distributed transactions, it will cause system availability and strict consistency of the conflict, strict consistency, it means that the system needs to sacrifice the availability of. Therefore, there is a difficult problem in usability and strict consistency, so the theory of CAP and base.

Cap theory

Professor Eric Brewer, from the University of California, Berkeley, who seems to be a very powerful professor, is said to be a tenured professor at the University of California, Berkeley, for the first time he has made the famous cap conjecture. Later, Seth Gilbert and Nancy Lynch from MIT came to the theory to illustrate this conjecture, and since then there has been a recognized cap theorem: A distributed system cannot meet consistency [consistency], usability [ Availability], and partition fault tolerance [Partition tolerance] These three basic requirements, can only meet at the same time two of them .

① consistency.

consistency is the ability to maintain consistency between multiple copies of data . If the data in multiple nodes is consistent, after performing an update operation, you should ensure that the data of the system is then in a consistent state.

For a data copy to be distributed across different distributed nodes, if the data of the first node is updated and the update succeeds, the second node is not updated accordingly. When the external system calls the second node, it still gets the raw data, which is the case of inconsistent distributed data. In a distributed system, if it is possible to perform a successful update on a data item, all users can read the latest value, and such a system is considered strong consistency.

② availability.

Availability means that the services provided by the system must be in a consistent state of availability, and that for each operation request of the user, the results are always returned for a limited period of time .

Limited time: For a user's action request, the system must be able to return the corresponding result within the specified time. If this time is exceeded, the system is considered unavailable.

The return result is a very important indicator of availability, which requires the system to return a normal response after the user's request has been processed. The normal response result contains success or failure, rather than a result that confuses the user.

③ partition fault tolerance.

In the case of any network partition failure, the distributed system still needs to provide services that satisfy the consistency and availability.

Cap theorem: I found a ready-made picture from the Proccesson template.

Since a distributed system cannot meet the above three requirements at the same time, we need to discard one when applying the cap theorem.

① Selecting a CA

The simple way to discard partition fault tolerance is to put all the data on a distributed node. Does that become a standalone application?

② Select CP

Given the availability, once a network failure occurs, the affected service needs to wait for a certain amount of time because the system is in an unusable state.

③ Select AP

Discard consistency, where the consistency is strong consistency, but ensure eventual consistency. is the choice of many distributed systems.

Summary: From the cap theorem it can be seen that partition fault tolerance is a basic requirement, because since it is a distributed system, it is necessary to deploy to two or more than two nodes, otherwise, it is not a distributed system, so we can only find consistency and availability of balance.

Base theory

Base is shorthand for basically Available (basic available), Soft State (soft), and eventually consistent (final consistency) three phrases. Base is the result of a tradeoff between consistency and availability in the CAP. is based on the theory of Cao evolved, the core idea is that even if not strong consistency, but each application according to its own business characteristics, the use of appropriate means to achieve final and implementation of the system.

① Basic Availability

The basic use refers to the time when the distributed system has unpredictable failures, allowing the loss of some of the availability. The response time is reasonably prolonged, and the function is properly degraded.

② Weak state

Weak state refers to allowing the data in the system to exist in the middle State, and that the intermediate state will not be the overall availability of the system, that is, to allow the synchronization of data at each node has a delay.

③ Final Consistency

Final consistency emphasizes that all copies of the data in the system can eventually reach a consistent state after a little time of synchronization. Therefore, the essence of final consistency is the need for the system to ensure that the data is ultimately consistent. Without the need to guarantee the consistency of system data in real time.

From distributed transaction to cap theory and base theory