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

This article focuses on "how to understand the idempotent multiple considerations of the interface". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the idempotent multiple considerations of the interface.

Body 1 interface idempotency

That is to say, to ensure that the final result is consistent under the same operation many times.

In fact, this concept is relatively simple and easy to understand, so let's consider a question: what will be the problem if we don't guarantee the idempotence of the interface?

1.1 case

Let's take a simple example. Now there is an interface that provides the function of transferring money. A needs to transfer 1000 yuan to b. Under normal circumstances, our interface is successfully called at one time, but it is not successful because of network jitter and other reasons. So we began to retry, and suddenly the network was ready, but then three requests were sent out in succession, but this interface did not guarantee idempotence. So the result is that a transferred 3000 yuan to b, which is obviously unacceptable in the program business logic (in fact, moon can be used as b).

2 solution 2.1 token mechanism

The token mechanism is actually relatively simple, so let's talk about the process first.

First, the client requests the server, and the server generates a token. Each request generates a new token (the token must set a timeout), stores the token in the redis, and then returns the token to the client.

The client carries the token request server that has just returned to make the business request.

The server receives the request and makes a judgment.

If the token is in the redis, delete the token directly and continue to make the business request.

If the token is not in the redis, the representative has already executed the current business, then the business is not executed.

The figure is as follows:

The implementation of the token mechanism is still relatively simple, but it is not very friendly to some of our businesses that require high response speed. The disadvantage is that we need one more request to obtain the token process.

Normally, a new token will be generated every time. If there is a limit, two requests will come in with the same token, and both will go into the process of judging whether they exist, and both may find out whether they exist at the same time, so there will be problems. In this case, we can determine whether they exist before deletion and delete them. In order to ensure atomicity, this part of the logic is recommended to use lua script to complete.

2.2 deduplicating the meter

The mechanism for deduplicating the table is based on the characteristics of the mysql unique index, so let's talk about its flow first:

First of all, the client requests the server, and the server first stores the request information in a deduplicated table of mysql, which establishes a unique index or primary key index according to one of the special fields of this request.

Determine whether the insertion is successful or not

If the insertion is successful, continue to make subsequent business requests.

If the insert fails, it indicates that the current request has been executed.

The figure is as follows:

There are two problems with the deretabling mechanism:

1.mysql fault tolerance, that is, mysql itself, may affect the business if it is not highly available:

two。 Since it is a unique index, there is no way to use changbuffer when writing a table, and you have to check it out from the disk every time. For a highly concurrent interface, these are all factors that need to be considered.

2.3 SETNX key value of redis

The process is as follows:

First of all, the client requests the server, and the server stores the unique fields that can represent the request business in redis in the way of SETNX, and sets the timeout period, which can be weighed according to the business.

Determine whether the insertion is successful or not

If the insertion is successful, continue to make subsequent business requests.

If the insert fails, it indicates that the current request has been executed.

Here we take advantage of the features of redis setnx.

Setnx: set the value of the key key to value only if the key key does not exist. If the key key already exists, the SETNX command does nothing. The command returns 1 when the setting is successful and 0 if the setting fails.

The figure is as follows:

This kind of scheme can be said to be improved for the previous one, and the efficiency will be greatly improved.

2.4 State Machine Power

This mechanism applies to businesses in different states, as the last company at moon did.

In our order system, an order will have multiple states, such as pending payment, locking, paid, etc., and these states have processes and logic, according to which we can judge whether to perform follow-up business operations.

2.5 optimistic lock (update operation)

The version number field is added to the database, and each update is judged according to the version number.

The process is as follows:

First of all, the client requests the server to query the current version version.

Select version from.. Where..

Do sql operation according to version version

UPDATE.. SET... Version= (version+1) WHERE.. AND version=version

I won't draw this picture anymore. It's relatively simple.

2.6 pessimistic lock (update operation)

Suppose that every time you take the data, it is thought that it will be modified, so locking the rows of the database is also based on the database characteristics.

When the database executes select for update, it acquires the row lock of the data row in the select, so other concurrently executed select for update will be excluded if they try to select the same row (need to wait for the row lock to be released), thus achieving the lock effect.

START TRANSACTION; # Open transaction SELETE * FROM TABLE WHERE.. FOR UPDATE;UPDATE TABLE SET... WHERE.; COMMIT; # commit the transaction at this point, I believe you have a deeper understanding of "how to understand the idempotent multiple considerations of the interface", you might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow 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.