What does queue mean? -Php Tutorial

Can you give me a detailed explanation? I heard the queue all day, and my head hurts. Baidu cannot find a good explanation. can you give me a detailed explanation? I heard the queue all day and my head hurts, baidu cannot find a good explanation. reply content: first, the queue is a data structure that can be implemented by using linked lists and arrays. the queue is characterized by putting data in the queue first and then going out of the queue.
However, we can see Redis as the topic tag. I guess the subject is a message queue (MQ) that is widely used now ). The messages here are not only simple text information, but also serialized objects. Currently, Beanstalkd, RabbitMQ, and Redis (which can be used as queue systems) are popular open-source message queue systems, its core function is to first put the message data into the queue in sequence (stored in memory) through the system interface, and then retrieve the data in order for subsequent processing as needed.
Let's take the example of the email sending system I created earlier:
The system provides services over HTTP. The main function provided externally is to send emails. the API address is/api/msg. send. You can send an email by sending a POST request to this address and passing in the parameters subject, body, and recipient.


Solution 1: Do not use databases or queues
When requesting an interface, the controller directly calls sendmail or the external smtp server to send an email. the HTTP request is in the waiting status during the entire sending process, return the sending result (only the result of calling the sender program for success, not the real sending result of the Mail, the real sending result needs to be analyzed in the mail log)
This solution is the simplest and most straightforward. it is possible to send a small number of emails at ordinary times, but its disadvantages are also obvious:
1. because the entire mail sending process is synchronized during interface calling, each request must wait for the Mail sending end to complete processing, which will inevitably lead to an increase in the waiting time for each API call.
2. when the system interface has high concurrent requests, the system availability is not only limited by the processing capability of WebServer, but also completely limited by the processing capability of the Mail sending software, if any link fails, the entire system cannot provide services.
3. if the sending software fails (for example, the SMTP connection times out) and the email fails to be sent when a request is sent, the content of the email will be completely lost and the system will not keep it, automatic resend is not supported.

Solution 2: use a database instead of a queue
When you request an interface, the Mail information to be sent is stored in the database. the table structure is as follows:
Id | subject | body | recipient | sent_at | failed_at | failed_times
Then, run a scheduled task on the server, read the records of sent_at = 0 & failed_times <10 every second, then call the Mail sending end to send the mail, and set sent_at to the current time, after the failure, set failed_at and accumulate failed_times. Solution 2 has used the idea similar to queue.

Improvement over Solution 1:
1. the synchronous mail sending operation is removed, and the interface request response will be much faster.
2. you can resend the email after the email fails to be sent. the email will not be lost.
3. when the sending end is completely invalid, the system can also accept the sending request. after the sending end is restored, the system can continue to send the mail.

But there are still disadvantages:
Each request will write a database. when a large amount of concurrency or data is large (a request contains 1 million recipients), the database load is too high to affect stability, at the same time, it will seriously increase the interface response time (it is not a joke to write 1 million records at once)

Solution 3: database + queue

When you request an interface, the Mail information to be sent is stored in the queue system in JSON format. The following figure shows a single message:
{
"Subject": "No medication today ",
"Body": "Feeling Yourself ",
"Recipient": "mengmeng@da.com"
}

The current queues are basically memory queues, and data access is very fast. it is no longer difficult to write 1 million pieces of data in an instant.
Then, run a resident process task (Worker) on the server to monitor whether a new message (Job, Mail information) exists in the queue in real time ). When a new message enters, the message is retrieved from the queue, and the mail sender is called to complete the processing. after the message is successfully sent, the message is destroyed and the message content is inserted into the database (same case 2 ), if the message fails to be sent, put the message in the queue again and add a 60-second delay mark, meaning that the message will be retrieved and processed after 60 seconds.

In this way, the throughput and response speed of the entire system will be greatly improved, and the system also supports the distributed operation capability. Each Worker process can be regarded as a processing node. distributed processing of the entire system is realized if the worker is distributed to different servers. this is also an important feature of the queue.

In my actual project, I made many improvements based on solution 3. I also used email lists and templates for group sending. the whole system is similar to Mailgun and Sendcloud, when the entire system is stable, I will consider opening up the code to Github.

This example is only a common application scenario of queues. In general, message queues can be considered in scenarios that need to relieve the pressure on database writing. In other cases, distributed processing is required, it is also a good scenario for queues.

Currently, most languages have mature Message Queue processing components, which allow you to easily use various queue systems, such
Laravel supports Beanstalkd, Amazon SQS, IronMQ, and Redis.

Please correct the shortcomings. thank you. Have you heard of queuing? Come first, stand in front of (first team), then follow behind (end team), exit from the first team when leaving, and join at the end of the team. this is the queue! As for the implementation, the linked list and array are all supported!