TP5学习笔记九 队列

依赖

redis-server

redis php扩展

参考此教程

安装

composer

最好通过composer安装 composer require topthink/think-queue 1.1.4

手动安装

去 https://github.com/top-think/think-queue 里
把包 下载下来 放入 项目的Vendor里

然后在 common.php 公共函数库里 加入这么一句:

require './vendor/topthink/think-queue/src/common.php';

当你在命令行里 切换到项目根目录后, 执行 php think queue:work -h

能出现以下 结果 就表示think-queue的 安装好了

[图片上传中...(image-5d191d-1548303820123-0)]

配置

配置文件位于 application/extra/queue.php

公共配置

[
    'connector'=>'sync' //驱动类型,可选择 sync(默认):同步执行,database:数据库驱动,redis:Redis驱动,topthink:Topthink驱动
                   //或其他自定义的完整的类名
]

驱动配置

各个驱动的具体可用配置项在think\queue\connector目录下各个驱动类里的options属性中,写在上面的queue配置里即可覆盖

这里我们只需记住 redis 和sync类型的就好了,因为database是官方不推荐的,topthink 完全不开放。

下面是我的配置:

return [
    'connector'=>'redis',
    // 'connector'=>'sync',
    'expire'     => 0,
    'default'    => 'default',
    'host'       => '127.0.0.1',
    'port'       => 6379,
    'password'   => '',
    'select'     => 0,
    'timeout'    => 0,
    'persistent' => false
];

使用

队列的特点是 先进先出,本质是将同步的调用,转成别的进程里的 异步任务。

think-queue 是基于cli 的php任务管理。

入队

首先,入队是queue的 push 和delay 两个方法。但是 两个方法的名称和参数不一样。因此,我的建议是 再包一层,封装成一个方法。

    /**
     * 添加队列任务
     *
     * @param string $job_name 队列执行的类路径 不带走类fire方法 带@方法 走类@的方法
     * @param array $data 传入数据
     * @param mixed $queue_name 队列名 null 或字符串
     * @param integer $delay  延迟执行的时间  单位秒
     * @return void
     */
    public function push_job($job_name, $data, $queue_name = null, $delay = 0){
        trace($queue_name);
        config('default_return_type', 'json');
        $class_name = \strstr($job_name, '@', true);
        if(class_exists($class_name)){
            if($delay > 0){
                $ret = \think\Queue::later($delay, $job_name, $data, $queue_name);
            }else{
                trace($job_name);
                $ret = \think\Queue::push($job_name, $data, $queue_name);
            }
            trace(sprintf("加入任务%s, 时间%s", $job_name, datetime()));
            return $ret;
        }
        return $this->error('job类 '.$job_name.'不存在');
    }

think-queue 支持普通队列和延迟队列两种,分别对应push 和delay。

然后 这两个方法都有共同参数 data, $queue。job是队列入队的任务执行路径,比如’A\B@c’

如果队列任务类只有一个方法需要队列执行,请定义为fire, job里 要@后接方法名。

如果是push的话返回的是一个队列任务的id ,延迟的话返回null

执行队列任务

队列任务 类 ,最好以job为后缀,放入相关job目录里。如果就一个任务,将队列执行方法 直接命名为fire, 多个子任务的话,方法可以定义多个。在入队时 用@指定消费的任务+方法>

且传递过来的 参数基本 Job $job, $data

举例:

    public function test(Job $job, $data){
        // trace("正在执行队列:{$job->getName()}");
        // $time = rand(0, 4);
        // sleep($time);
        $isJobDone = $this->send($data);
        trace($data);
        if ($isJobDone) {
            //如果任务执行成功, 记得删除任务
            $job->delete();
            trace("队列执行完成:".__FUNCTION__." ". datetime());
        } else {
            $try_nums = $job->attempts();
            trace("报警内容:".__FUNCTION__.",报警失败{$try_nums }次, 执行时间:". datetime());
            // $job->release();
            // $job->delete();
        }
    }

队列的数据data 用户自己定义,通常是一些查询需要的条件,或者第三方服务需要的参数。

这里执行的时候注意一定不要抛异常,容易把队列进程搞挂了。

出队

当队列任务执行完毕,最好将任务删除掉。不然堆积在队列里,不断重试。

$job->delete()

再入队

$job->release()

当默认开启队列 最大重试次数参数时, 如果一直失败 一直release 的话他会无限重试。

所以最好设置一个最大重试次数。

整个任务失败

当任务重试超过最大尝试次数后, 最后会执行当前任务类的 failed方法 但是参数只有$data, 当一个类里如果有多个子任务的话 不好区分哪个任务。

失败事件

首先,我们添加 queue_failed 事件标签, 及其对应的回调方法

// 文件路径: \application\tags.php
// 应用行为扩展定义文件
return [
    // 应用初始化
    'app_init'     => [],
    // 应用开始
    'app_begin'    => [],
    // 模块初始化
    'module_init'  => [],
    // 操作开始执行
    'action_begin' => [],
    // 视图内容过滤
    'view_filter'  => [],
    // 日志写入
    'log_write'    => [],
    // 应用结束
    'app_end'      => [],

    // 任务失败统一回调,有四种定义方式
    'queue.failed'=> [

         // 数组形式,[ 'ClassName' , 'methodName']
        ['application\\behavior\\MyQueueFailedLogger', 'logAllFailedQueues']

         // 字符串(静态方法),'StaicClassName::methodName'
         // 'MyQueueFailedLogger::logAllFailedQueues'   

         // 字符串(对象方法),'ClassName',此时需在对应的ClassName类中添加一个名为 queueFailed 的方法
         // 'application\\behavior\\MyQueueFailedLogger'

         // 闭包形式
         /*
         function( &$jobObject , $extra){
             // var_dump($jobObject);
             return true;
         }
         */
    ]
];

这里,我们选择数组形式的回调方式,新增 \application\behavior\MyQueueFailedLogger 类,添加一个 logAllFailedQueues() 方法

 $jobObject->getName(), // 'application\index\job\Hello'
            'queueName' => $jobObject->getQueue(),             // 'helloJobQueue'    
            'jobData'   => $jobObject->getRawBody()['data'],  // '{'a': 1 }'
            'attempts'  => $jobObject->attempts(),            // 3
        ];
        var_export(json_encode($failedJobLog,true));

           // $jobObject->release();     //重发任务
          //$jobObject->delete();         //删除任务
          //$jobObject->failed();     //通知消费者类任务执行失败

        return self::should_run_hook_callback;         
    }
}

需要注意该回调方法的返回值:

  • 返回 true 时,系统会自动删除该任务,并且自动调用消费者类中的 failed() 方法
  • 返回 false 时,系统不会自动删除该任务,也不会自动调用消费者类中的 failed() 方法,需要开发者另行处理失败任务的删除和通知。

最后,在消费者类中,添加 failed() 方法

/**
 * 文件路径: \application\index\job\HelloJob.php
 */

/**
 * 该方法用于接收任务执行失败的通知,你可以发送邮件给相应的负责人员
 * @param $jobData  string|array|...      //发布任务时传递的 jobData 数据
 */
public function failed($jobData){
    send_mail_to_somebody() ; 

    print("Warning: Job failed after max retries. job data is :".var_export($data,true)."\n"; 
}

这样,就可以做到任务失败的记录与告警

启动队列监听服务

  • Work 模式

    php think queue:work \
    --daemon            //是否循环执行,如果不加该参数,则该命令处理完下一个消息就退出
    --queue  helloJobQueue  //要处理的队列的名称
    --delay  0 \        //如果本次任务执行抛出异常且任务未被删除时,设置其下次执行前延迟多少秒,默认为0
    --force  \          //系统处于维护状态时是否仍然处理任务,并未找到相关说明
    --memory 128 \      //该进程允许使用的内存上限,以 M 为单位
    --sleep  3 \        //如果队列中无任务,则sleep多少秒后重新检查(work+daemon模式)或者退出(listen或非daemon模式)
    --tries  2          //如果任务已经超过尝试次数上限,则触发‘任务尝试次数超限’事件,默认为0
    
    
  • Listen 模式

    php think queue:listen \
    --queue  helloJobQueue \   //监听的队列的名称
    --delay  0 \         //如果本次任务执行抛出异常且任务未被删除时,设置其下次执行前延迟多少秒,默认为0
    --memory 128 \       //该进程允许使用的内存上限,以 M 为单位
    --sleep  3 \         //如果队列中无任务,则多长时间后重新检查,daemon模式下有效
    --tries  0 \         //如果任务已经超过重发次数上限,则进入失败处理逻辑,默认为0
    --timeout 60         //创建的work子进程的允许执行的最长时间,以秒为单位
    
    

    可以看到 listen 模式下,不包含 --deamon 参数,原因下面会说明

注意点

安全

redis 默认是没密码的,可以去服务器配置 auth password

模式区别

两者都可以用于处理消息队列中的任务

区别在于:

  • 执行原理不同

  • work 命令是单进程的处理模式。

    按照是否设置了 --daemon 参数,work命令又可分为单次执行和循环执行两种模式。

    • 单次执行:不添加 --daemon参数,该模式下,work进程在处理完下一个消息后直接结束当前进程。当不存在新消息时,会sleep一段时间然后退出。
    • 循环执行:添加了 --daemon参数,该模式下,work进程会循环地处理队列中的消息,直到内存超出参数配置才结束进程。当不存在新消息时,会在每次循环中sleep一段时间。
  • listen 命令是 父进程 + 子进程 的处理模式。

    listen命令所在的父进程会创建一个单次执行模式的work子进程,并通过该work子进程来处理队列中的下一个消息,当这个work子进程退出之后,listen命令所在的父进程会监听到该子进程的退出信号,并重新创建一个新的单次执行的work子进程

  • 退出时机不同

  • work 命令的退出时机在上面的执行原理部分已叙述,此处不再重复

  • listen 命令中,listen所在的父进程正常情况会一直运行,除非遇到下面两种情况:

    • 创建的某个work子进程的执行时间超过了 listen命令行中的--timeout 参数配置,此时work子进程会被强制结束,listen所在的父进程也会抛出一个 ProcessTimeoutException 异常并退出。开发者可以选择捕获该异常,让父进程继续执行,也可以选择通过 supervisor 等监控软件重启一个新的listen命令。
    • listen 命令所在的父进程因某种原因存在内存泄露,则当父进程本身占用的内存超过了命令行中的 --memory 参数配置时,父子进程均会退出。正常情况下,listen进程本身占用的内存是稳定不变的。
  • 性能不同

    • work 命令是在脚本内部做循环,框架脚本在命令执行的初期就已加载完毕;

    • 而listen模式则是处理完一个任务之后新开一个work进程,此时会重新加载框架脚本。

      因此: work 模式的性能会比listen模式高。

      注意:当代码有更新时,work 模式下需要手动去执行 php think queue:restart 命令重启队列来使改动生效;而listen 模式会自动生效,无需其他操作。

  • 超时控制能力

    • work 模式本质上既不能控制进程自身的运行时间,也无法限制执行中的任务的执行时间。

      举例来说,假如你在某次上线之后,在上文中的 \application\index\job\Hello.php 消费者的fire方法中添加了一段死循环 :

      public function fire(){
         while(true){ //死循环
             $consoleOutPut->writeln("I am looping forever inside a job. \n");
             sleep(1);
         }
      }  
      
      

      那么这个循环将永远不能停止,直到任务所在的进程超过内存限制或者由管理员手动结束。这个过程不会有任何的告警。更严重的是,如果你配置了expire ,那么这个死循环的任务可能会污染到同样处理 helloJobQueue 队列的其他work进程,最后好几个work进程将被卡死在这段死循环中。详情后文会说明。

      work 模式下的超时控制能力,实际上应该理解为 多个work 进程配合下的过期任务重发能力。

    • 而 listen命令可以限制其创建的work子进程的超时时间。

      listen 命令可通过 --timeout 参数限制work子进程允许运行的最长时间,超过该时间限制仍未结束的子进程会被强制结束;

    • 这里有必要补充一下 expire 和 timeout 之间的区别:

      • expire 在配置文件中设置,timeout 在 listen命令 的命令行参数中设置,而且,expire 和 timeout 是两个不同层次上的概念:

      • expire 是指任务的过期时间。这个时间是全局的,影响到所有的work进程。(不管是独立的work命令还是 listen 模式下创建的的work子进程) 。expire 针对的对象是 任务。

      • timeout 是指work子进程的超时时间。这个时间只对当前执行的listen 命令有效。timeout 针对的对象是 work子进程。

  • 使用场景不同

    根据上面的介绍,可以看到,

    work 命令的适用场景是:

    • 任务数量较多
    • 性能要求较高
    • 任务的执行时间较短
    • 消费者类中不存在死循环,sleep() ,exit() ,die() 等容易导致bug的逻辑

    listen命令的适用场景是:

    • 任务数量较少
    • 任务的执行时间较长(如生 成大型的excel报表等),
    • 任务的执行时间需要有严格限制

调试方式

首先,队列的日志在runtime里cli.log 而不是web的log

因此最好的方式 时自定义一个日志统一存储位置。

然后,队列由两部分组成,业务代码和队列部分。

辅助终端神器vscode

编辑代码时直接 ctrl+` 打开终端 可以开启多个终端 添加多个队列

业务测试

最方便的方式是本地将队列改为同步, 将队列的任务从推入到消费。都给测试一便。

确保队列业务逻辑部分没有异常。

队列的测试

主要测试 业务执行失败后,会不会无限循环入队列,队列失败后,有没有进入报警和写入错误日志。

还有队列进程的内存,是否会挂掉。

思考

队列传送数据格式的定义?

什么时候该用队列重试,什么时候直接报警让技术查问题? 是不是应该在告警时留有手动补救执行队列的方式的url?

延迟队列是不是 sleep设为0 才精确

大队列数据时 是不是多几个进程能加速?

参考文档:

think-queue 笔记

官方文档

你可能感兴趣的:(TP5学习笔记九 队列)