Author: Chinese Shi Shan
Interview questions
How Idempotence distributed service interface design (such as not a duplicate charge)?
Interviewer psychological analysis
From this question, the interviewer has entered the interview actual production problem at all.
A distributed system of an interface, how to ensure idempotency? In fact, this thing is a technical problem in the production environment when you do a distributed system must be considered. What does it mean?
You see, if you have a service provides a number of interfaces for external calls, the service deployed on five machines, then there is the interface payment interface. Then when people on the front-end user actions, I do not know why, in short, is an order accidentally initiated a payment request twice, and then dispersed in maybe request a different machine on the deployment of the service, well, the result of an order debit deduction twice.
Or order payment system payment system call, the results are not careful because the network time-out, and then walked order system retry mechanism that we saw earlier, click, give you retry a handful of, well, a payment system to receive payment request twice, and because the load balancing algorithm falls on different machines, embarrassing. . .
So you definitely have to know this thing, otherwise you do out of distributed systems it is probably easier to bury the pit.
Face questions analysis
This is not a technical problem, this is not a universal method, this should be combined with business to ensure idempotency.
The so-called idempotent, that is an interface with a request to initiate many times, you have to ensure that this interface results are accurate, such as no more deductions, you can not insert more than one data, statistics can not pay more 1. This is idempotent.
In fact, to ensure Idempotence mainly three points:
- There must be a unique identifier for each request, give chestnuts: order the payment request, certainly have to include an order id, once a payment order id the most of it.
- After each request has been handled, there must be a record identifying the request processed. The common solution is to record what the states in mysql, recording a pay water this order before such payment.
- Every time receiving a request needs to be determined, before determining whether or not treated. For example, if there is an order has been paid, they have to pay a water, then repeat if the request is sent, it is first inserted at this time to pay water, orderId already exists, unique key constraint into effect, error insertion do not go. Then you will not have to charge up.
The actual operation of the process, you have to combine their businesses by, for example, the use of redis, with orderId as the only key. Only successfully inserted the payment of water before they can perform the actual payment charge.
Requires a payment order, you must insert a pay water, order_id build a unique key unique key. Before you pay for an order, first insert a pay water, order_id has been entered. You can write an identity to redis go inside set order_id payed, over the next repeat request, first check the redis order_id corresponding value, if it is payed it explained that it had been paid, and you do not repeat paid.