Explain the idempotence of distributed system in detail

Idempotent means that one and more requests for a resource should have the same effect .

What is distributed idempotent

First , Let's imagine the following scenarios ：

• Scene one ： stay App When you confirm your order , Click many times and no response , You can only click several times . under these circumstances , If the idempotence of the interface cannot be guaranteed , Then there will be the problem of repeated orders .

• Scene two ： When receiving messages , Message push repeat . If the interface that processes the message cannot guarantee idempotence , Then the news of repeated consumption may have a great impact .

Usually , For high availability 、 High performance and high scalability , The distributed system has many service nodes , But it is easy to lead to long and complex service call chain , The network communication complexity between service nodes increases exponentially , A slight network failure may cause the whole service to be abnormal .

meanwhile , Considering the possibility of hardware equipment failure , So distributed systems face a common problem ： A message （ Mission ） May be consumed repeatedly . therefore , How to ensure that single consumption and repeated consumption of the same message have the same effect , That is, idempotency of messages has become a hot issue .

Other common distributed solutions

1. Add a unique index to the database , For example, the order number is the unique index , Prevent duplicate production orders ;

2. Using distributed locks , Prevent concurrent operations in applications ;

3. use Token Mechanism , Effectively prevent repeated submissions . Submit background tape Token value , It needs to be judged first Token Whether there is , If it exists , Delete Token, Execute business logic ;

4. Database through optimistic lock ;(update table_name set version=version+1 where version=0)

5. Database pessimistic lock , It is usually implemented with transactions through primary keys or unique indexes .

These are other common idempotent solutions , Different methods are often used in different business scenarios . Because our main business is distributed storage ,IO from Client To Server The link of is not very long , So we refer to it Token Mechanism , A set of “ new ” Mechanism to deal with idempotent problems in business scenarios .

Message processing in different states

As shown in the figure , This is a simple task system ,Server Successfully executed ① The command sent , But no corresponding result was received . This is because the storage with network factors encounters problems ,Client You need to retry the task , To eliminate the impact of network instability , But in different cases ,Server When a retry message is received , Different solutions are needed . At this time , There are three possible situations ：

Case one ,Server No corresponding message was received , Because there is network instability ,Client You need to try again , At this time Server The message will be received again and processed , After normal processing, the corresponding result is returned .

The second case ,Server Received the corresponding message , Still processing , Due to other factors, the task execution time is too long . This is because the task is still being carried out , So in order to guarantee idempotence , We need to wait until the previous task is completed , Then get the execution result and return it to the client .

The third case ,Server Received the corresponding message , And it has been processed , But network factors lead to Client   Have not received ② Result ,Server After receiving the retry request , Get the received result directly and return it to Client.

In order to achieve the above functions , We need a reasonable mechanism to save the received message status , And you need to be able to judge that the message has been Client Clear this state when the result is received , Here we introduce SeqNumber To do these things .

SeqNumber The mechanism of

Every time we request, we will carry a request serial number that has been completed before ACK And current serial number Seq,Server When processing, it will be based on Seq To determine the status of the current message , To ensure a Seq Will not be executed many times . meanwhile , Will release ACK The corresponding serial number , Because only at this time can we guarantee Client The corresponding request has been completed correctly .

We are Client There are two queues at the end finished and running, There are tasks being performed and completed ID. stay Server There's one side map, All uncleaned messages are saved （ Include Being implemented , Execution completed ）.

We have the following steps for a request ：

1. Generate an unused Seq, Pictured here request Generated in  12;

2. Put this Seq Insert running queue ;

3. From what has been done finished The queue gets the smallest Seq As ACK, Pictured ACK=1, Come here Client Send the prepared message to Server;

4. Server Receive a request , First of all, I will ACK The cache of the corresponding request is released , Then get the corresponding Seq The news of , If not, it means that it is new news , Directly inserted into the , Otherwise, according to map Do the corresponding processing for the state in （ The processing method corresponding to the above three states ）;

5. After finishing the task , Return the result to Client, Come here Server Task processing has been completed ;

6. Client Received the result of the message , Can confirm Server The task has been completed , At this time release finished In line ACK=1 The item , Then what will just be finished is Seq=12 The task of moves to finished In .

summary

Distributed system is a very large and complex system , Idempotence is only a very important and complex problem , In the construction of distributed system , Different systems have different requirements for idempotence , I hope this article can help you .