App interface development: How to restrict an app from sending the same request multiple times at a time

Problem: There is a credit system in the app. When a user signs in, a request is sent to the server to record the user's sign-in information. However, the app sends multiple identical requests concurrently, the result is that although there is a verification to check whether or not to sign in, multiple requests will penetrate this verification (no sign-in letter has been written for multiple requests... problem:
There is a credit system in the app. When a user signs in, a request is sent to the server to record the user's sign-in information. However, the app sends multiple identical requests concurrently, the result is that, although there is a verification of whether to sign in, multiple requests will penetrate this verification (no sign-in information has been written to the database for multiple requests) as a result, two identical records may occur in the database. How can this problem be solved?

Current solution:

select ... for update

The database locking method can be used to solve the problem. But this way, the problem is thrown to the database. How can this problem be solved?

Question supplement
Use the cache (redis) to block the same request, but it cannot be completely resolved:

// Shield the same request // generate key $ forbidsameRequest = md5 (implode ('', $ reqDatas) for the request data; if (Cache: has ($ forbidsameRequest) {Log:: info ("the same request", $ reqDatas); return Util: returnError ();} Cache: put ($ forbidsameRequest, true, $ this-> _ forbiddenTime ); omitting logical processing... // release the keyCache after processing: forget ($ forbidsameRequest );

Reply content:

Problem:
There is a credit system in the app. When a user signs in, a request is sent to the server to record the user's sign-in information. However, the app sends multiple identical requests concurrently, the result is that, although there is a verification of whether to sign in, multiple requests will penetrate this verification (no sign-in information has been written to the database for multiple requests) as a result, two identical records may occur in the database. How can this problem be solved?

Current solution:

select ... for update

The database locking method can be used to solve the problem. But this way, the problem is thrown to the database. How can this problem be solved?

Question supplement
Use the cache (redis) to block the same request, but it cannot be completely resolved:

// Shield the same request // generate key $ forbidsameRequest = md5 (implode ('', $ reqDatas) for the request data; if (Cache: has ($ forbidsameRequest) {Log:: info ("the same request", $ reqDatas); return Util: returnError ();} Cache: put ($ forbidsameRequest, true, $ this-> _ forbiddenTime ); omitting logical processing... // release the keyCache after processing: forget ($ forbidsameRequest );

This is a typical anti-replay attack scenario.
The request end is required to carry a random string state (which can also be generated by specific rules or even requests from the server ), the server (using a filter or interceptor does not affect the Business Code) caches the data for a certain period of time (depending on the service and hardware) After receiving the data ), each request checks whether the state value exists in the cache (or whether the rule is met, or whether it is generated by the server). If the state value is discarded or a special response is given, the first accepted request is processed normally.
It should be noted that it is an atomic operation to determine and cache.

Curious, why does it resend twice and try a simple verification on the APP?

You can first record the sign-in information to the Redis cache. The verification logic also directly uses the data in the Redis cache, and then asynchronously writes the sign-in data to the database.

What are the fields recorded in your data table? If it is something similar to a user id (uid) and a timestamp, you can set these two fields as unique key.

In this case, you can use Nginx buckets.limit_req_zoneSet the speed limitlimit_reqTo control the concurrency of A Single IP address. for example, you can set it as follows: only one request is processed per second for each IP address, and the maximum number of concurrent requests is 5. One of the five concurrent requests sent within one second will be processed, the other four go to latency processing.

Or all requests are put in one queue and processed in sequence.