Does the redis implementation queue have to be executed with crontab timing tasks?
in the case of high concurrency such as flash sale activity, we use the redis function rpush,lpop to implement queue processing.
Why do you always use rpush to put requests in the queue first, such as rpush.php,
?
$arr = array("h","e","l","l","o","w","o","r","l","d"); //
foreach($arr as $k=>$v){
$redis->rpush("mylist",$v);
}
then use lpop to fetch each request lpop.php from the queue
$redis->lpop("mylist");
set up scheduled tasks
*/1 * * * * root php /wwwroot/workplace/redis/rpush.php
*/3 * * * * root php /wwwroot/workplace/redis/lpop.php
question: are all the steps of implementing message queues with redis like this? Separate two files for queuing and queuing, and then use crontab to execute them regularly.
I don't quite understand why I use crontab . To put it simply, message queuing is the producer-consumer model, which is generally handled separately
.
producer : if you use the PHP-FPM mode, you can directly push to the queue
Consumer : usually write a resident memory service block to get messages in the queue ( blpop ), and process new messages immediately
.
guess that crontab is used because there is no blocking method to get it, and then check every 3 seconds for new messages, but processing every 3 seconds is a bit inappropriate for second kill
generally inserts the list into the page to maintain a process to fetch the queue for processing
nohup php / wwwroot/workplace/redis/lpop.php & isn't it better for the daemon to execute
first of all, you have to state the reason for using the crontab solution that you see on the Internet. The scenario may be different, such as killing Xiaomi phone in seconds. The user orders important messages rpush into the redis queue through the interface, and then does not give rpush when the number exceeds, giving the user a consolation hint, and then lpop issues the order, the above personal opinion.
there are actually two processes:
- production program, generate messages, push to message queues
- Consumer program, read the message, pop a message and read
if there is a message, go and deal with it. If not, take a rest
crontab is to produce a timing effect, and there are programs such as workerman that can have the same effect. It is not necessary to use
.
brpop timeout is set to 0, and then create a daemon to listen. You can refer to my article based on redis message queue and keyspace notification to achieve panic buying and time-limited payment
queuing and dequeuing are two operations, one is a data producer, the other is a consumer. Producers can insert queues at any time as long as they have data, while consumers are generally resident in memory to regularly query whether the queue has data to deal with. Crontab is only a regular way, or you can write an endless loop script to query data per sleep seconds. Then the script is run as a daemon
daemon execution consumption
I think it's a simple way to do redis rpush for highly concurrent requests, and then set up an asynchronous queue for asynchronous lpop for each highly concurrent request. In addition, I think a lot of people are talking about producer and consumer models, so it is possible to use RabbitMp to generate consumption. You have to study the specific operation
.
