Just write it down and record your thoughts to avoid memory loss. . . . . . . . . . . . . . . . . . .
I recently encountered such a scene in a project:
Coupon module:
When creating a coupon, use a template to create a corresponding number of coupons, and each coupon will generate a piece of coupon data in advance.
The first step for users to receive coupons is to query all coupons under the corresponding template to take one by default, but in the case of high concurrency, multiple users will occupy the same coupon. I have not done many similar scenarios before, I did not expect It's a great way. During the solution process, I considered the solution and finally chose the last one:
1. Distributed lock:
When the user picks up, the template is locked, and the user who occupies the lock can only process it by other users. In this case, there is no order in which locks can be obtained preferentially, and some users may not be able to obtain locks all the time.
2. Add a weighting table:
Add a table with the coupon id as the main key. When the user receives the coupon, first insert the corresponding coupon into the reordering table. If it succeeds, it will be occupied. If it fails, it means that it has been occupied. You can also use the redis cache to solve the reordering problem.