First public account: Binary community, reprinted contact: [email protected] Idempotence was originally a concept in mathematical operations. Wikipedia defines it as:
- In a binary operation, an idempotent element refers to an element whose result is repeated by itself (or compounded for a function) equal to its own.
- When a certain element operation is idempotent, its effect on any element twice will be the same as its effect once. For example, the Gaussian symbol is idempotent.
Derived into the field of microservices, idempotence refers to calling the same API multiple times with the same parameters, and the impact on the backend is the same. Many people understand that the results returned by multiple calls are the same. This view is wrong. Yes, even the most basic query interface cannot return the same result for multiple queries. The idempotent focus is on the impact on the back-end and does not care about the returned data. Idempotence is a problem that all client-server systems need to consider, whether you are in CS or BS mode, but in BS mode, this problem is more prominent, especially under the popular microservice architecture in recent years. Because in the microservice mode, a single application is simple, but the service as a whole is more complicated. To complete a function requires a longer call chain. The overall link may be implemented by different languages and different frameworks. Each microservice is in order to ensure the quality of service. , It is often fault-tolerant to deal with problems caused by some uncertain factors (such as network abnormalities, resource exhaustion, etc.). The typical measure is to retry. 
The above picture is a very streamlined call process in Internet applications. It should be said that the links of many companies are far more complicated than this, and each link in the process may be retried:
- Users may click buttons frequently
- The browser resends the request when the network is unstable
- Reverse code is resent to another instance due to gateway response timeout or network abnormality
- The gateway may also automatically call another service due to timeout/error
If the request only involves resource query, obviously calling multiple times will not change the back-end data, so the query API is naturally idempotent, but if this is an order creation interface, we have to consider idempotent The problem, the process of creating an order will involve operations such as inventory deduction, balance deduction, order data storage, message notification, etc. to modify the back-end resources. In order to prevent such requests from being repeatedly submitted to the back-end, the front-end page is usually Click the Disable button after submit. After the backend is successful, the form will be cleared to jump to the prompt page. For back-end services, the following methods are usually used to achieve idempotence:
- Database unique constraint: Through business design, determine a few uniquely identifiable order fields and set them as unique indexes. The advantage of this method is simple, the code is basically unchanged, and the disadvantages are also obvious. Therefore, repeated requests must penetrate the entire link. Until the database can be judged heavy, it consumes a lot of resources on the link, and will put huge pressure on the database. Even if the service is expanded, TPS is difficult to go up.
- MVCC: Multi-version concurrency control method, bring the version number when operating: update t1 set x=y ,version=version+1 where version=xxx, the advantage is that the concurrent response ability is improved, the implementation is also simple, the disadvantage is that only the update interface is applicable , The repeated requests will still reach the database, the database pressure is greater
- The state machine mechanism is essentially a variant of the MVCC method: an order has multiple business states, and each operation data will bring a state. Only when the previous state matches, the data will be updated. The advantages and disadvantages are similar to those of MVCC, but this This mechanism solves the problem of insertion, not only for updating interfaces
- Token mechanism, this is a very efficient idempotent mechanism, which achieves good results in performance and function. Next, we will discuss the implementation of this mechanism in detail.
The core of the Token mechanism is that each request of the client must carry a UUID. There are many algorithms for generating UUIDs, such as: snowflake algorithm, ObjectID, and common development languages also have corresponding implementations. Even if the client has difficulty generating UUIDs, you can also call ID. The generator pre-generates a batch of caches to the local, which will not be expanded here. With this UUID, interception can be achieved in multiple links, and this judgment is very efficient. Almost all O(1) time complexity is far faster than the database unique constraint judgment. For example, in nginx, we can use Lua obtains the UUID in the request, puts the UUID in leveldb, redis, memcache, and determines whether the value exists in the next request. If there is an error, it will be released directly. Layer implementation, for the java language (other languages are similar), transparent processing can be achieved: Idempotentfilter is registered in the gateway, and the filter extracts the UUID, and also judges whether it can be released through the cache of leveldb, redis, memcache, etc., obviously the token solution can Finding and intercepting orders as early as possible will greatly reduce resource consumption, reduce database pressure, and be transparent and non-immersive to the business, but relying only on the token mechanism is obviously flawed: when the cache service fails, the LDB file is lost, the redis data is accidentally emptied, and the memcache is unexpectedly restarted. , Will lead to the loss of our UUID mark, then we need the database to cover the bottom, the only constraint of the database is indispensable, when these extreme conditions occur, even if the request reaches the DB, it will not cause data duplication. For interfaces with idempotent requirements, it is recommended to use the token mechanism to efficiently eliminate duplicate requests.Of course, the final landing needs to be combined with specific business scenarios.