Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the concept of ACID, CAP and BASE". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "what is the concept of ACID, CAP and BASE"!

1 Case Background

The user buys a piece of clothing on the e-commerce website. After the payment is successful, the payment system needs to change the order status to payment completion. It is necessary to pay attention to the consistency between the payment result and the order result. After successful payment, the order status cannot be modified, otherwise the user will be confused: the order is in the status of waiting for payment.

The easiest way to think about this kind of simultaneous success or failure scenario is to use transactions. We assume that the payment table and the order table belong to the same database.

This scenario code is not difficult to implement, as long as we take advantage of the database transaction features, we can ensure that the two data tables either succeed at the same time or fail at the same time:

public class PayServiceImpl implements PayService { @Transactional public void pay() { updatePayInfo(); updateOrderInfo(); }}

But it's not that simple in distributed scenarios. In the distributed scenario, orders are maintained by the order team, and payments are maintained by the payment team. Therefore, the order system and payment system are basically two systems, deployed on different servers and providing services respectively, and it is even more impossible to use a database:

So in distributed scenarios the code above doesn't work anymore and we need a new solution. We need to explain some theoretical knowledge before we talk about the specific scheme.

2 Theoretical knowledge

2.1 ACID

Traditional data transactions have four characteristics: atomicity, consistency, isolation, and persistence, which are collectively referred to as ACID characteristics.

Atomicity Consistency Isolation Durability

(1)atomicity

A transaction either commits all successfully or rolls back all failures. You cannot execute only a part of the operation.

(2)consistency

Database system failure occurs in the process of operation, some transactions are forced to interrupt before completion, if some of these transactions have been written to the database, then the database is in an inconsistent state, this situation cannot be allowed

(3)isolation

Transactions are isolated from each other, and the execution of one transaction cannot be interfered with by other transactions.

(4)persistent

When the transaction succeeds, the changes made to the database remain in the database forever. Even if the database fails, as long as the database can be restarted, it can be restored to the successful end of the transaction state

In the same database scenario of the above e-commerce system, it is the use of ACID that can meet our expected business requirements. But this is no longer applicable in distributed scenarios, and solving distributed transaction problems in distributed scenarios is not easy, which leads to the next concept: CAP theory.

2.2 CAP

In 1998 Eric Brewer, a computer scientist at the University of California, proposed that distributed systems have three metrics, which together are called CAP theory.

Consistency Availability Partition Tolerance

(1)partition tolerance

In distributed systems, different nodes (servers) are typically deployed in different subnetworks, each of which is called a zone. Different subnetworks may fail in network communication, and we need to accept this situation.

(2)availability

The server must respond whenever it receives a user request, and the user must get a timely response when accessing the data

(3)consistency

In a distributed system, multiple copies of the same data may be stored in different nodes. When the update operation is successful and returned to the client, all nodes (servers) must have the same data at the same time.

However, CAP theory cannot satisfy all three criteria simultaneously. We need to prove this proposition. I analyzed a lot of proof articles and thought that the method of contradiction was clearer. Here I prove this proposition by contradiction:

Assuming CAP satisfies C Assuming CAP satisfies P Since C satisfies, there can be no network failure in data transmission between nodes. The third point contradicts the second point. Proof is complete.

We see that CAP theory is a bit inadequate in distributed practice, and here we introduce the next concept: BASE theory, which is the guiding theory for many distributed practices.

2.3 BASE

BASE theory extends CAP theory. The core idea is that since strong consistency cannot be achieved, each application can adopt appropriate methods to achieve final consistency according to its own business characteristics. This theory is also the theoretical basis of our distributed transaction scheme. BASE consists of three phrases:

Basically Available Soft State Eventually Consistency

(1)Basic availability

When a distributed system fails, it is allowed to lose part of the system availability. For example, when the e-commerce system cannot withstand the traffic peak, it may lead the user to the degraded page, or trigger the service fuse to ensure that most users are available.

(2)flexible state

CAP theoretical consistency This indicator does not allow intermediate states, all states must ensure strong consistency. But flexible states allow short-term inconsistencies between nodes

(3)eventually consistent

Since there is a short period of inconsistent state between nodes, then after a period of time through business means, the state between nodes needs to be finally agreed upon. Distributed practice does not pursue strong consistency, but ultimate consistency

3 Transactional messaging practices

There are many distributed transaction solutions, such as two-phase commit, TCC, transactional messaging. I use transactional messages most often in distributed transaction practices. Let's start by describing what a transactional message is with a life example.

Xiaoming goes to a noodle shop to eat noodles. There are many people waiting in line. Xiaoming paid and sat down, because the empty seats were randomly distributed, so how could the waiter ensure that the noodles could be delivered to Xiaoming's table accurately? The answer is to rely on Xiaoming's receipt. The receipt is Xiao Ming's purchase voucher and consumption basis. With the receipt, you don't have to worry about not eating noodles. The receipt is a transactional message.

This chapter explains the transactional messaging scheme thoroughly, or uses the case of an order system and a payment system.

3.1 scene one

Suppose you are a member of the payment team and the order system is maintained by the order team. If the order team is willing to cooperate with you in system modification, the following transactional message architecture diagram can be used:

According to this diagram, analyze how transactional messages work: when the user pays successfully, the payment system saves the payment completion data in the database, and adds a message in the same transaction with the status of "pending". Note that this message is strongly consistent with the payment data save, both successful and unsuccessful. We call this message transactional.

After saving the successful transactional message, the transactional message is sent into the message queue. After the order system subscribes to this message through the message queue, the corresponding order status is set to paid, and at the same time, the payment system interface is called to set this message to "processed", and the whole forward process ends.

However, the order system may fail to call the modify message interface, that is, although the business processing is successful, the transactional message status is still "pending", and then the timing compensator needs to play a role. The timing compensator sends messages with status of "pending" to the message queue at regular intervals, and the order system subscribes to process them again, which requires the order system to ensure idempotency.

At this point in the analysis, the working principle of transactional messages has been clearly explained, but it cannot stop there. Let's go on to analyze a problem: Suppose the order system has been unsuccessful for a long time, resulting in the message being "pending"?

The reason for this may be that the order system is down, so the compensator has been retrying frequently without results, so we have to give the message retry a ladder time: the first unsuccessful retry after 5 minutes, the second unsuccessful retry after 15 minutes, the third unsuccessful retry after 30 minutes, this can give the order system recovery time.

We also set a maximum number of retries, assuming that after ten unsuccessful attempts, the system sets the message to "expired" and sends an alarm and manual intervention. Transactional messaging scenarios typically do not roll back when an exception occurs in the traditional transaction mode, but rather continue the link by retry or manual intervention.

3.2 scene two

Suppose you are a member of the payment team and the order system is maintained by the order team. The order system only interacts with the outside world by exposing interfaces, and there is no time to adapt the system to listen to message mode. Faced with this scenario, we need to modify the scene-architecture diagram, but the core idea remains unchanged.

According to this diagram, we analyze how transactional messages work: when the user pays successfully, the principle of saving payment business data and adding new messages is the same as scenario 1. After saving the successful transaction message, directly call the order processing business interface, and set this message to "processed" after successful call, and the whole forward process ends.

When the call to process the order business interface fails or there is no response, the message status is still "Pending." The timing compensator periodically calls the order processing service interface again for messages with a status of "pending" some time ago, which requires the order system to ensure idempotent.

If the order system does not guarantee idempotency, when calling the order processing interface again, you need to query whether the order interface has been processed, and call it only when it explicitly returns that it has not been processed. Otherwise, you give up this compensation call and wait for another retry. The compensation retry strategy is the same as that of Scenario 1.

4 RocketMQ

If RocketMQ messaging middleware is used, its transactional messaging mechanism can be used directly, and final consistency can be achieved by sending half messages, committing or rolling back half messages, and timing business lookbacks.

At this point, I believe everyone has a deeper understanding of "what is the concept of ACID, CAP and BASE". Let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.