Concurrency problem 1000 concurrent, 3 prizes, how to ensure the stability of the second kill?

1000 Concurrent 3 Prizes guaranteed to stabilize in seconds, and the number of winners and prizes do not go wrong
How to deal with this problem, MySQL hope that you have experienced students to share the next experience and solutions, thank you, earlier and so on

Reply content:

1000 Concurrent 3 Prizes guaranteed to stabilize in seconds, and the number of winners and prizes do not go wrong
How to deal with this problem, MySQL hope that you have experienced students to share the next experience and solutions, thank you, earlier and so on

Redis queue
Redis can handle high concurrency scenarios because its read-write requests are single-threaded and there is no concurrency problem. And Redis is memory-based and read and write faster than MySQL.

Because there are only three prizes, so no matter how many requests come up, there can be up to three requests to get the prizes correctly, so you could make most of the requests do not do any processing, directly return to the second kill failure, leaving a small request into the next link, when the concurrency is very small, so the next processing can almost no longer consider concurrency problems.
Of course, this scheme is only because of the small number of prizes, if the prize itself is many, even discard most of the request, the system also suffer a large concurrent impact, at this time need to consider other scenarios.

Please use the cache to add all the prizes to the inside. And then all the cache seconds, seconds to update the database.

See you describe your second kill scene feel a little bit simpler than ours, if not to consider the very rigorous extensibility, only consider the present, I can actually be the following way simple implementation:

If you optimize under the MySQL or upgrade the hardware, 1000 concurrent all query MySQL database is still inventory, can be able to live, then only need a queue service, all the concurrent seconds to kill the user all into the queue to filter out 3 of the winning users, Then when the order is generated to deduct the inventory in MySQL, and respond to the front page to detect whether the process is successful, the other 997 users all respond to the front-end process seconds kill reminder

Assuming you don't have a roof or no money to upgrade? Then use a service like Redis to cache 1000 prizes, and the seconds to kill the inventory quantity in MySQL and Redis when the order is successfully generated

Because the main statement uses only MySQL, I think I can do this:

1. Put 3 prizes in one table;
2. After the system enters the high concurrency State, then your prize random algorithm lets the user win the lottery and deletes the record;
3. Whether there is any data in the test table;

You can also do this:

1. Create a special counting table for winning;
2. After the system enters the high concurrency State, then your prize random algorithm allows the user to win and increase the count;

As for the optimization scheme (which can be thought of for the time being, I hope the Great God adds):

1. Storage engine use MEMORY ;
2. At the entrance of the program can be set an expiration time, 3 prizes, 10 seconds enough, after the entrance closed or jump;

The simplest way to do this is to pull the 1000 concurrent queue to linear, and when a request finds that the inventory is gone, all subsequent requests return a second kill failure.

Only 1000 of the concurrency/data, why use the database. The speed of the database is still very slow.
The server saves a timestamp directly for each request, and then sorts it out. After 1-2 seconds the user will not have any special feeling about the result.

Saves the request to the queue, fetching only the first three values of the queue, and all subsequent returns are sold out.

Need a queue service, put all the concurrent seconds to kill the user, all into the queue to filter out all the 3 winning users, and then when the order is generated to deduct the inventory in MySQL, and respond to the front page to detect whether the second kill process can be successful, All other 997 users respond to the front-end process with a second-kill failure reminder

Use the MySQL memory table. Use hash user_id and so on to randomly discard a part of the request

Then update the memory table directly, for example:

``
Update award set USER_ID=XXX where Id=1 and user_id=0
``

