Use redis to change the asynchronous return of the queue to synchronous - queue usage

In web programming development, resource contention will be encountered. Example:

There are multiple products, the products are rushing to order, and each product has a quantity limit.

Whenever such problems are encountered, since ancient times, there have been two solutions: 1. Use locks, 2. Use queues.
You can use either one.

The easiest way to use a queue is to not consider locking. There is also no need to use database locks.

Put all the requests into the queue, and then return the result of the queue processing to the client. Check whether the remaining quantity of the product is 0 each time, and reject the request if it is 0.

If there are too many commodities, you can divide them into multiple queues according to the categories of commodities. This processing speed is faster.

The question now is: the queue is returned asynchronously, what should I do?

Conceived the scenario, process A handles web requests (there will be multiple processes similar to A at the same time), process B is a queue, and process C is a daemon process that listens to the queue.
The simple way is: A puts the request into the queue, and then process C handles it and directly informs the client asynchronously, but this requires the help of a long connection such as nodejs. Because to send.

So use the following solution:
use redis to change the asynchronous return of the queue to synchronous 1. Add the redis daemon D. New scenario: Process A handles web requests (there will be multiple processes similar to A at the same time), process B is a queue, and process C is a daemon process that listens to the queue. Process D is redis. 2. Web request process A: Create a random number random. Send the processing message to the queue, but add random to the message. Use $result = $redis->blPop(random, 30);// 30 seconds is the waiting time,








$redis->delete(random); // After removing the message, this key is useless.
BLPOP is a blocking popping primitive for lists.

It is a blocking version of the LPOP command, when there are no elements to pop in the given list, the connection will be blocked by the BLPOP command until the wait times out or an element to pop is found.

Then just get the return of process C from $result.

3. Daemon C:
Take rendom out of the message, process the entire message, and get the result.
Then put the result into the redis list with random as the key name. That's it.

$redis->lPush(random, 'processing result');//After this sentence is executed, the blPop method of process A will return immediately!

4. Disadvantages:
This solution has no disadvantages, only the disadvantage of the queue itself, that is, if there are too many concurrent requests and cannot be processed, the client needs to wait.
The solution is to add multiple queues, add multiple daemon processing queues, and the daemons and queues can also be distributed on different servers.

5. Advantages:
super simple, redis is great.