Feeling of Queue Service (queue) in Laravel 4.2

In the past half month, I participated in rewriting a WeChat WeChat official account back-end system, and used laravel 4.2 and queue, which laravel is proud of.

Because the whole system involves multi-terminal interaction and has a large number of voice transmission and processing services, we found that the response time is too long in some places. The previous system is based on node. js and mongoDB. Because node is inherently asynchronous and has daemons, this problem has not occurred, and this rewrite must introduce asynchronous processes. Queue came into our sight.

According to this 1 page of "Chinese document", which is almost all in English, laravel just introduced redis as queue storage in version 4.2, which is a very good news. OK, the background is introduced here, and the dry goods are pulled below.

The queue service in laravel is no different from other queue services, and it is the simplest and most common process that most conforms to human thinking: there is one place to store queue information, one PHP process writes tasks at runtime, and the other PHP daemon polls queue information, and executes and deletes tasks that meet the execution requirements. Since PHP is a synchronization language driven by url and is itself blocking, it is not surprising that laravel provides a daemon tool to query and execute queue information.

The queue configuration file of Laravel is/app/config/queue. php. In the item Default Queue Driver, five drivers can be selected: "sync", "beanstalkd", "sqs", "iron" and "redis".

1. sync is a synchronous driver for local debugging

2. beanstalkd is a professional queue service driver: http://kr. github. io/beanstalkd/

3. sqs and iron are foreign third-party queue services

4. The last item of redis gives us a reason to use redis, so we migrate both the caching service and the session service to redis by the way.

0. By the way, don't use mysql for session drive. The processing time of 1S is not a dream. Hey, look at who it is, it is you, brother 1S!

Queue service needs to create new task classes specially. As independent classes, they don't need to inherit classes, because the tasks in the queue are called independently by PHP daemon when they are executed. Of course, if you want other classes under use1 to call again, there will be no mistakes. Previously, I separated many additional services into a separate folder/app/services, such as input information verification validator, special security verification module, etc. This time, queue classes are located in it.

The use of queue is very simple. Here is a simple example:

use Queue;

Queue::push('CurlJsonQueue', [

 'url' => $url,

 'json' => $json

]);

This is a standard queue press-in process. Of course, here I put the CurlJsonQueue class in the root directory of services, which has been registered by me in the "autoload" of composer. json, which is located in the top-level namespace and can be called directly. If you need to call the non-top-level namespace, you can write App\ OOXX. Our system needs a lot of interaction with WeChat server, so this class is independent.

<?php
class CurlJsonQueue extends BaseController{
 public function fire($job, $data)

 {

  $url = $data['url'];

  $json = $data['json'];
  parent::base_post_curl($url, $json);
  $job->delete();

 }

}

The default method of this class is fire (), and the parameters are also fixed two $job and $data. Since I encapsulated the curl module of post in BaseController, I called 1. In addition, there is a small pit here. At that time, protected was used when writing base_post_curl (), which made use BaseController invalid and must be inherited.

By executing the above code, a new task is put into queue, and laravel starts the daemon with the following command:

php artisan queue:listen

Then the daemon begins to process the queue. Please adjust the path of the PHP command and the artisan file in this code.

As you may have noticed, The queue system we're going to use uses the redis and PHP command lines, If you are in the test environment, you can add a startup or even a manual startup, but in the production environment, you need more stable tools to guard these two programs. We use supervisor. For the installation and configuration of supervisor, you can refer to this article: http://blog.segmentfault.com/qianfeng/1190000000532561. Note that there are small pits in the article, please step on them yourself. . .

OK, after all configuration, run redis and PHP command lines, and the whole system starts to run happily ~

Use experience:

Queue service is super easy to use. The previous interaction process with app needs 6-7S, which is reduced to less than 2S after asynchronous, which is basically the transmission time and the running time of PHP code. The time-consuming special operation has been asynchronous. However, the queue service defaults to 1S and opens one process to check whether there is a service that can run in redis once. On Alibaba Cloud server, it can account for about 10% of the single core, which consumes a little more, and the queue processing time is relatively long, because there is no file loading benefit during previous synchronization. However, if there are multiple tasks, the PHP process will execute continuously, instead of 1S executing one.

Let's talk about the pit:

1. Because the queue core class uses a special function, variables with no explicit type will be stored in json in the form of unit prime array and then in redis. The solution is to put ''in front of every data to be put in. The above $url and $json did not do this step because they have already been declared in quotation marks.

2. If you want to pass url to a queue, the system queue class will prefix every 1/with two\\. This may have a fatal impact on 1 special operation. (Kidding, is there a fatal one above!)