Treatment of idempotency

What is idempotency ？ Sending an interface call and sending the same interface message multiple times can get the result that is consistent with the expectation

If there is an interface that provides salary increase , If you call add... Once 500 Yuan , If you don't control the problem of idempotency ,

Keep calling the interface , Then the employee's salary has been increasing

// Inquire about 1 Employee No

Employee employee = employeeService.selectById(1);

// Update salary

employee.setSalary(employee.getSalary() + incrSalary);

// Execute UPDATE statement

employeeService.update(employee)

What's the problem? ？ Right , Every time you resend a request 1 No. salary will +500, Idempotency is destroyed

How to solve ？ The traditional method is to add pre judgment to the code , That is, by adding a flag and salary increase time

if(! The employee has been paid && Raise time +6 Months < Current system time )

{

Carry out salary adjustment

}

What's wrong with ？ There are too many areas for pre judgment , If you don't pay attention, you'll miss This technical problem should not be a factor that interferes with programmers writing business code

We need a non intrusive idempotent solution Building idempotent tables is our general solution Let the brothers concentrate on writing CRUD That's it

  advantage ： The background service has no code intrusion , No need to modify business logic

shortcoming ： The foreground application should be transformed for idempotence Increased architecture complexity , Additional deployment is required Nginx、Redis