Do you know how to consider the idempotence of interfaces?

table of Contents

Preface

    Today's topic: the solution of interface idempotence . Originally, I wanted to shed light on the storage process and memory layout of the object, but it changed temporarily. Haha, let's keep this part of the content in the next issue. There is a good saying, but it's hard to be done, right.

    In the actual project development, the interface is something we often come into contact with in the development, and we often write it frequently. Each project may be accompanied by a large number of interface developments. In the months when moon came to doodle, it was basically The interface is struggling. In addition to business-related new requirements, the design table and interface are written.

    Of course, we have to consider many issues in interface design, such as security, format, design, and so on. Today, let’s talk about the idempotent solutions for interfaces in a high-concurrency environment.

text

1 Interface idempotence

     It means that the final result is consistent under the same operation multiple times.

    In fact, this concept is relatively simple and easy to understand, so let's think about a question. What will be the problem if the interface idempotence is not guaranteed ?

1.1 Case

    Let's take a simple example. Now there is an interface that provides the function of transferring money. A has to transfer 1,000 yuan to b . Normally, our interface is called successfully at one time, but it fails because of network jitter and other reasons. I started to try again and again. Suddenly the network was ready, but three consecutive requests were sent, but this interface did not guarantee idempotency, so from the result, a was transferred to b by 3,000 yuan , which is obviously It is unacceptable in the business logic of the program (in fact, moon can be used as b).

2 Solution

2.1 token mechanism

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

• First, the client requests the server first, and the server generates a token. Each request generates a new token (this token must be set with a timeout period), stores the token in redis, and then returns the token to the client.
• The client carries the token just returned and requests the server to make a business request .
• The server receives the request and makes a judgment.
  • If the token is in redis , delete the token directly, and then continue to make business requests.
  • If the token is not in redis , it means that the current business has been executed, and the business is not executed.

    The icons are as follows:

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

    Normally, a new token will be generated every time you request. If there is a limit, if two requests come in with the same token, they will both enter the process of judging whether they exist, and the existence may be found at the same time . This will also cause problems. In this case, we can judge whether it exists before deleting, and delete it if it exists. In order to ensure atomicity, this part of the logic is recommended to be completed with lua scripts .

2.2 Deduplication table

    The mechanism of deduplication table is based on the characteristics of mysql unique index. Let's talk about its process first:

• First, the client first requests the server, and the server first stores the request information in a mysql deduplication table . This table needs to establish a unique index or primary key index based on a special field of the request .
• Determine whether the insertion is successful
  • If the insertion is successful , continue to make follow-up business requests.
  • If the insertion fails , it means that the current request has been executed.

    The icons are as follows:

    There are two problems with the de-duplication mechanism:

• 1. MySQL fault tolerance, that is, if MySQL itself is not highly available, then the business may be affected:
• 2. Since it is the only index, naturally there is no way to use the changbuffer when writing the table. It must be checked from the disk every time and then written. For a highly concurrent interface, these are all factors that need to be considered.

2.3 Redis's SETNX key value

    The process is as follows:

• First, the client first requests the server, and the server saves the only field that can represent the requested service this time in redis in the form of SETNX , and sets the timeout period. The timeout period can be weighed according to the business.
• Determine whether the insertion is successful
  • If the insertion is successful , continue to make follow-up business requests.
  • If the insertion fails , it means that the current request has been executed.

    Here we use the characteristics of redis setnx to complete.

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

    The icons are as follows:

    This kind of scheme can be said to be an improvement on the previous scheme, and the efficiency will be much improved.

2.4 State machine power

    This mechanism is suitable for businesses with different statuses, as the last company of Moon did.

    In our order system, an order has multiple states, such as: pending payment, locked, paid, etc., and these states have processes and logic. We can judge whether to perform subsequent business operations based on this state.

2.5 Optimistic locking (update operation)

    It is to increase the version number field in the database, and each update is judged according to the version number

    The process is as follows:

• First, the client first requests the server, and first queries the current version.
  • select version from … where …
• Do SQL operations based on version
  • UPDATE … SET … version=(version+1) WHERE … AND version=version;

    I won’t draw this icon anymore, it’s relatively simple

2.6 Pessimistic lock (update operation)

    Assuming that every time you get data, you think it will be modified, so locking the rows of the database is also done based on the characteristics of the database.

     When the database executes select for update, it will acquire the row lock of the data row in the select. Therefore, if other concurrently executed select for update tries to select the same row, it will be rejected (need to wait for the row lock to be released), thus achieving the lock effect .

START TRANSACTION; # 开启事务
SELETE * FROM TABLE WHERE .. FOR UPDATE;
UPDATE TABLE SET ... WHERE ..;
COMMIT; # 提交事务

Conclusion

    Regarding the idempotence of interfaces, the solutions are actually the same, and the principles of many methods are the same. Most of them are actually filtered in the business link, and many of them are solved by message middleware. By default, it is directly filtered out at the middleware layer. Of course, each method has its own advantages and disadvantages, which need to be selected in combination with the current business. Have you got the content of today's article?

    I’m moon, next article, I’m really going to talk about jvm~ see you next time~