Shulou(Shulou.com)06/01 Report--

This article mainly explains "java distributed interview interface how to ensure idempotent", the explanation content in the article is simple and clear, easy to learn and understand, please follow the small series of ideas slowly in-depth, together to study and learn "java distributed interview interface how to ensure idempotent" bar!

1. Concept of idempotent

Interviewer:

Do you understand the concept of idempotent? What interfaces in your system use idempotent design?

Problem analysis:

The concept of idempotent first you must understand, simple and easy to understand, that is, whether you are Http interface or RPC interface, input parameters unchanged, no matter how many times the request, the result is the same, the request result will not change because of the number of requests, no task side effects.

A: In my first year of work, I worked in a company that bought tickets online (movie tickets) App to do background system development. At that time, I was responsible for the points system and received such an online activity demand at work. Business Scenario Description: Every day, users use the App to click the check-in button to participate in activities and receive corresponding points. Each user can only participate in the check-in activity once a day. After clicking the check-in button once, it will change from gray to unclickable state. I am responsible for developing this interface for receiving points and providing API to client colleagues. After launching, such a bug appeared. At that time, there was no perfect business monitoring system. The second day after the function was launched, I asked out of curiosity how many points the person with the highest points in the system had. I ran an sql in the background. This curiosity surprised me to find that some users had tens of thousands of points, because in addition to signing in to receive points, most of them consumed accumulated points. One dollar can accumulate one point. I doubt it. What kind of person can watch movies for tens of thousands of dollars?

With this question, I checked his accumulated points record and found that most of the points were obtained by check-in. According to the rules of the event, a person can only participate in check-in once a day, so it is impossible to have so many points. However, this user checked in hundreds of times a day. Later, after checking bugs with the front end, the problem was discovered. The reason is that although the check-in button turned gray, the requested url was not hidden on the front page. The user repeatedly refreshes the interface by technical means to bypass the front limit of button graying, and repeatedly obtains points.

Post hoc problem analysis:

The biggest problem with this bug is still with me, because my interface is not idempotent. The correct logic should be idempotent according to the current date of the system. After idempotent, no matter how many requests the user makes, the final result is the same. The integral is accumulated only once. Fortunately, this bug was not discovered by the black industry, and only a few users found that the loss was controllable.

Because I lack design experience, do not understand idempotent design, leaders did not remind me, so this kind of bug appears, after experiencing more money-related system development, I understand a truth, any system design, must consider the security of the business, internal system can be in order to save manpower, appropriately simplify the design, do not guard against gentlemen, assume that your colleagues are gentlemen, for C-end user's system, not only to guard against gentlemen, but also to guard against villains, risk prevention can not all rely on risk control system, Sometimes bugs may come from inside the system, for example, the user does not mean malicious theft, but the network is not good, the user waited for two seconds before loading a few more check-in buttons, my interface did not do idempotent design, as long as the request will give the user more points, this time can blame the user? It's obviously the developer's responsibility.

About the idempotent design of this interface

Here's how I solved it:

Points interface background generates unique serial number according to user mobile phone number + userId + system current date after splicing, saves according to serial number, if user repeatedly initiates request, check in background according to unique serial number, if serial number exists, directly returns the previous request result, considering concurrency, status judgment uses lock processing.

Develop a business monitoring system, generate a list of the highest growth of Top100 points in the system every day by using regular tasks, and observe whether there is any abnormality every day by operation or technical personnel.

After this bug reflection, I learned two things:

Understand the importance of idempotent design, and be cautious about features related to money.

The importance of monitoring system, monitoring here is about business monitoring, if I didn't wonder who had the highest points in the system that day, when would this bug be discovered?

Interviewer: Oh, interesting, you really wrote a big bug, understand the lesson is good, but do not enter my project team after taking our system to write this bug.

In-depth analysis:

A characteristic of an idempotent operation in programming is that any number of executions has the same effect as a single execution. An idempotent function, or idempotent method, is a function that can be executed repeatedly with the same parameters to obtain the same result. These functions do not affect the state of the system, and there is no fear that repeated execution will cause changes to the system. For example, the "setTrue()" function is an idempotent function whose result is the same no matter how many times it is executed. More complex idempotent operations are guaranteed using unique transaction numbers (serial numbers).

--Baidu Encyclopedia

If you understand the Restful style interface, I believe you are familiar with GET / POST /Deleted verbs. In an interview with Hammer Technology, the interviewer asked me if I understood the Rest interface. I balabala answered these commonly used verbs. The interviewer asked me again: Do you have any other understanding besides knowing that GET is to obtain resources from the server? At that time, I didn't answer it. After leaving the company, I remembered that the design of GET action should be idempotent. Delete is also idempotent, so if your interface GET / Delete isn't idempotent, you might want to rethink it.

2. Common idempotent design scenarios in work

If you do the function and money related, or is able to pay back, then you have to be careful, each interface should first consider whether to need idempotent design, the following are two common requirements scenarios.

Coupon issuing/points interface, which usually uses orderId userId for idempotent verification.

Payment/refund interface. We don't want users to receive money from users when they initiate multiple payments. Users will complain and return money to users. It is useless for the system or customer service personnel. The payment system is very complex. If you want to do a good job in the payment system, there are still many things to learn. We must consider various unstable factors such as network delay, service abnormality, order center timeout, etc. Usually front-end control, logic layer state control, and data layer unique index control are adopted. And the control of distributed locks, discussed much in idempotent.

3. Common design schemes of idempotent interfaces

Client-side button submission limits, buttons are disabled each time a request is submitted.

The background system logic layer processes, generates and stores unique ID (serial number), checks whether the serial number already exists for each request, and if it exists, it means repeated operation, and directly returns the previous operation result.

Token verification mechanism, client requests token first, the same token is processed only once, no token or the same token is not processed.

Distributed locks, such as the introduction of Redis distributed locks, prevent duplication of operations by other requests.

Request queuing, introducing MQ queuing to allow requests to be processed in an orderly manner, and the application of asynchronous operations will be explained in a later chapter.

Each solution has its own advantages and disadvantages, such as customer service button submission limit, simple implementation, but can not fundamentally solve the problem, background generation unique ID, determine the existence of the state must ensure atomic operation, can use a combination of multiple solutions to solve the idempotent problem, our goal is to solve the problem with the easiest maintenance method.

Thank you for reading, the above is "java distributed interview interface how to ensure idempotent" content, after the study of this article, I believe that we have a deeper understanding of java distributed interview interface how to ensure idempotent this problem, the specific use of the situation also needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.