laravel异步事件中`shouldQueue`存在的问题

测试异步队列事件shouldQueue存在的问题，方法如下：

在shouldQueue添加判断条件，值小于5继续操作
在handle中阻塞操作，并添加条件

代码如下：

<?php

namespace App\Listeners\Test;

use App\Events\Test\RollEvent;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Support\Facades\Redis;

class CapterBEventListener implements ShouldQueue
{
    use InteractsWithQueue;

    public function handle(RollEvent $event)
    {
        $redis = Redis::class;
        $num   = $redis::incr('capter_test');

        echo '执行：',$num,PHP_EOL;
        $redis::expire('capter_test', 3600);

        sleep(10);
        echo '结束',PHP_EOL;
    }

    public function shouldQueue(RollEvent $event) 
    {
        $redis = Redis::class;
        $num   = $redis::exists('capter_test') ? (int)$redis::get('capter_test') : 0;

        return $num < 5;
    }
}

测试如下：

执行结果跑了10遍

预期应该是跑4遍后停止

$ php artisan tinker
>>> for($i = 0; $i < 10; $i++) event(new App\Events\Test\RollEvent(5))

我想可能有人会说，那么你把判断条件放到handle中不就好了吗？例如：

    public function handle(RollEvent $event)
    {
        $redis = Redis::class;
        $num   = $redis::exists('capter_test') ? (int)$redis::get('capter_test') : 0;

        if ($num < 5) 
        {
            // doit...
        }
    }

那么不就回到主题了么，shouldQueue方法不是很鸡肋么？还有存在的意义么？同步事件又不支持，异步事件又存在问题？

上面我用redis是为了便于举例，同理，比如操作mysql数据库，或者发起异步请求，同样会出现类似的问题

levi

65 声望

暂无个人描述~

0 人点赞

以构建论坛项目 LaraBBS 为线索，展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。

从零开始带你一步步开发一个 Go 博客项目，让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。

MArtian

版主 3.8k 声望

最佳答案

你大概对 shouldQueue 方法有些误解，shouldQueue 是决定是否将任务放入队列。

在你执行循环

for($i = 0; $i < 10; $i++) event(new App\Events\Test\RollEvent(5))

的时候，这10个次时间是同一时间触发的，并不会因为你在 handle() 方法中添加了 sleep() 就会阻塞，sleep() 只会在队列执行时阻塞，但因为是异步，所以这里是没意义的。

事件的触发流程大概是这样：

for 循环触发10个事件
当 i 等于 0 时 shouldQueue 条件成立，队列被执行
当 i 等于 1 时，前一个的队列刚刚被分发出去，还没执行完，redis获取到的值还是 0 ，条件成立
以此类推，所以 10 次循环条件都成立。

怎么来验证这一点呢？在你的代码中添加日志打印

public function shouldQueue(RollEvent $event) 
{
    $redis = Redis::class;
    $num   = $redis::exists('capter_test') ? (int)$redis::get('capter_test') : 0;

    Log::info($num);

    return $num < 5;
}

你会发现 10 次日志的值全部是 0，一瞬间就被打印出来了，但此时你的队列还没执行完。

所以如果你要添加阻塞，应该在 shouldQueue 或 for 中去添加，而不是在 handle 中添加阻塞，最好是在 for 中添加，这样不会影响 shouldQueue 的逻辑。

for($i = 0; $i < 10; $i++) 
{
    sleep(10);
    event(new App\Events\Test\RollEvent(5))
}

但这样会造成请求阻塞，如果不想请求阻塞，就在 handle 中去动态判断。

结论：

在 shouldQueue 方法中，不应该以队列中不断变化的值去作为判断，因为队列是异步，而 shouldQueue 是在队列分发之前同步执行的，速度要快于队列，很可能会造成误判。

shouldQueue 方法是没问题的，我们在怀疑一个事情的时候应该自己先仔细求证，不要着急下结论。

3年前评论

MArtian （作者）

@levi 在 handle 中做判断其实也不是最优解，最优解应该是队列不被发出去执行。所以我觉得应该在 shouldQueue 处理并发问题。

MArtian （作者）

@levi 还是按着你上面的代码来，不做改动，我们来改动以下 shouldQueue 的判断：

public function shouldQueue(RollEvent $event)  
{
    if(Redis::incr('dispatch_capter_test_times') < 5)
    {  
        return true;
    }
    return false;
}

这样就可以解决你说的并发问题，而且不会发出额外的队列，我们使用了一个额外的 Redis 缓存来计数队列分发次数。当然了，队列执行失败后的就需要你自己来处理了。

levi （楼主）

①你没理解我的用图，我为什么要同时for个10次？因为我要模拟高并发……这里的sleep不是由你来决定的。②我当然知道shouldQueue中redis还没有递增，我这么做就是为了验证这个问题有多么低级，比如说一个入库请求，你在shouldQueue去获取库存，没有再通过handle入库，而并发的时候可能首次还未入库，后面已经加入队列导致重复入库好几次！③最后，目前怎么唯一的解决办法是在handle中去判断库存，那么不就回到了上面我提的问题了嘛，shouldQueue同步事件用不了，异步事件高并发下有问题，这不是鸡肋函数吗？④再补充一点吧，在此之前我考虑过队列唯一的做法，实验结果队列唯一可以用在队列，而不能用在异步事件。

levi （楼主）

再补充一句吧，我for个10次是为了模拟高并发，这里的sleep不是由你能决定的，我在handle去sleep是为了模拟慢请求，整个下来就是为了验证在高并发下的慢请求操作shouldQueue是会存在严重问题的，我考虑过队列唯一性，但是只能用于队列不能用于异步事件，我在另外一篇问题提问了

levi （楼主）

问答：请教关于异步事件任务的唯一的问题这篇提问，我问了为什么laravel异步事件不能队列唯一操作，如果可以实现，这样高并发下，也可以解决重复请求的问题，目前测试来看，队列唯一只能用在队列，但是不能用在异步事件，这个问题目前无解

MArtian （作者）

@levi 嗯。。。shouldQueue 其实只是一个判断函数而已，我们也不能指望一个简单的判断来解决并发问题。但如果在 shouldQueue 方法中使用互斥锁，行锁，等我们平时常用的并发处理方式来做判断呢？

levi （楼主）

好的，谢谢，明白了

讨论数量: 12

MArtian

版主 3.8k 声望

你大概对 shouldQueue 方法有些误解，shouldQueue 是决定是否将任务放入队列。

在你执行循环

for($i = 0; $i < 10; $i++) event(new App\Events\Test\RollEvent(5))

事件的触发流程大概是这样：

for 循环触发10个事件
当 i 等于 0 时 shouldQueue 条件成立，队列被执行
当 i 等于 1 时，前一个的队列刚刚被分发出去，还没执行完，redis获取到的值还是 0 ，条件成立
以此类推，所以 10 次循环条件都成立。

怎么来验证这一点呢？在你的代码中添加日志打印

public function shouldQueue(RollEvent $event) 
{
    $redis = Redis::class;
    $num   = $redis::exists('capter_test') ? (int)$redis::get('capter_test') : 0;

    Log::info($num);

    return $num < 5;
}

你会发现 10 次日志的值全部是 0，一瞬间就被打印出来了，但此时你的队列还没执行完。

所以如果你要添加阻塞，应该在 shouldQueue 或 for 中去添加，而不是在 handle 中添加阻塞，最好是在 for 中添加，这样不会影响 shouldQueue 的逻辑。

for($i = 0; $i < 10; $i++) 
{
    sleep(10);
    event(new App\Events\Test\RollEvent(5))
}

但这样会造成请求阻塞，如果不想请求阻塞，就在 handle 中去动态判断。

结论：

shouldQueue 方法是没问题的，我们在怀疑一个事情的时候应该自己先仔细求证，不要着急下结论。

3年前评论

MArtian （作者）

@levi 在 handle 中做判断其实也不是最优解，最优解应该是队列不被发出去执行。所以我觉得应该在 shouldQueue 处理并发问题。

MArtian （作者）

@levi 还是按着你上面的代码来，不做改动，我们来改动以下 shouldQueue 的判断：

public function shouldQueue(RollEvent $event)  
{
    if(Redis::incr('dispatch_capter_test_times') < 5)
    {  
        return true;
    }
    return false;
}

levi （楼主）

MArtian （作者）

levi （楼主）

好的，谢谢，明白了

MArtian

版主 3.8k 声望

你大概对 shouldQueue 方法有些误解，shouldQueue 是决定是否将任务放入队列。

在你执行循环

for($i = 0; $i < 10; $i++) event(new App\Events\Test\RollEvent(5))

事件的触发流程大概是这样：

for 循环触发10个事件
当 i 等于 0 时 shouldQueue 条件成立，队列被执行
当 i 等于 1 时，前一个的队列刚刚被分发出去，还没执行完，redis获取到的值还是 0 ，条件成立
以此类推，所以 10 次循环条件都成立。

怎么来验证这一点呢？在你的代码中添加日志打印

public function shouldQueue(RollEvent $event) 
{
    $redis = Redis::class;
    $num   = $redis::exists('capter_test') ? (int)$redis::get('capter_test') : 0;

    Log::info($num);

    return $num < 5;
}

你会发现 10 次日志的值全部是 0，一瞬间就被打印出来了，但此时你的队列还没执行完。

所以如果你要添加阻塞，应该在 shouldQueue 或 for 中去添加，而不是在 handle 中添加阻塞，最好是在 for 中添加，这样不会影响 shouldQueue 的逻辑。

for($i = 0; $i < 10; $i++) 
{
    sleep(10);
    event(new App\Events\Test\RollEvent(5))
}

但这样会造成请求阻塞，如果不想请求阻塞，就在 handle 中去动态判断。

结论：

shouldQueue 方法是没问题的，我们在怀疑一个事情的时候应该自己先仔细求证，不要着急下结论。

3年前评论

MArtian （作者）

@levi 在 handle 中做判断其实也不是最优解，最优解应该是队列不被发出去执行。所以我觉得应该在 shouldQueue 处理并发问题。

MArtian （作者）

@levi 还是按着你上面的代码来，不做改动，我们来改动以下 shouldQueue 的判断：

public function shouldQueue(RollEvent $event)  
{
    if(Redis::incr('dispatch_capter_test_times') < 5)
    {  
        return true;
    }
    return false;
}

levi （楼主）

MArtian （作者）

levi （楼主）

好的，谢谢，明白了

levi

65 声望

今天写业务的时候回想起这个问题，发现其实是不存在的，准确一点来说在单个队列中是不存在的。

为什么这么说，先说Laravel异步事件加入队列的生命周期，最少包含三个阶段（可能有更多）：

触发事件event
通过事件侦听器的shouldQueue来判断是否将异步事件加入队列，并将event对象序列化
按照先后顺序执行队列handle

说明：

其中步骤1，这个阶段出现高并发时是不确定的，只要触发就会执行，并且将所有触发的事件按照堆栈的形式组成一个list
而从步骤2到步骤3，按照先进先出的原则，从list中先pop第一组先进入的event
之后从弹出的这组event中，按照事件侦听器的顺序，从上至下依次执行
结束之后，继续从list中pop下一组event循环执行

结论：

无论高并发如何没有规律，没有顺序的去触发事件
队列的前提始终是一个队列，执行的顺序会one by one，可以用redis的Lists数据类型来理解
也就不存在第一组event在handle执行之前，后面的event开始进入shouldQueue来判断要不要加入队列，更不会重复去执行handle
也就是说，后面的event在执行shouldQueue，判断要不要加入队列时，前一组event肯定已经执行完handle了

衍生问题：

这个结论仅限于单个队列，或者多个不同级别的队列，比如说有2条队列，一条负责task，一条负责order，各司其职，互不干扰，这样是绝对没有问题的
但是如果存在多个队列同时处理相同的异步事件时，可能就需要考虑分布式锁了，亦或者是mysql的排它锁，但是这个复杂程度就高很多了，目前我的需求还没这么高，暂且不做考虑，等以后真的需要这方面的需求的时候我再考虑
上面推导出来的结论都是建立在异步事件执行成功的前提下，当业务中handle抛出异常，那么当前队列会结束，并将其重新加入队列末尾，最后执行，直至成功或失败最大程度

末尾补充：
对衍生问题最后一点，异步事件处理过程中抛出异常的解决办法

在高并发下执行相同操作，当前队列抛出异常并不影响整个流程，无非是哪个操作先执行而已，所以这个情况不是问题
在高并发下执行不同操作，这个时候通常要根据业务来考虑handle如何执行，具体情况具体操作，举个简单的例子，当下架商品的同时，有个买家抢先一步下了个单，那么只要在下架商品的handle中下架商品，并根据最终情况来统计最终库存即可

3年前评论

MArtian

版主 3.8k 声望

也就是说，后面的 event 在执行 shouldQueue，判断要不要加入队列时，前一组 event 肯定已经执行完 handle 了

这个你确定吗？如果真的是按照 list 的情况触发 shouldQueue，假如有100个 handle 要执行，那这里不就发生阻塞了？因为 shouldQueue 是和请求同步执行的。

我认为 shouldQueue 方法和 handle 并不发生联系，也不会等待前一个 event 的 handle 结束再来判断，而是 event 触发时同步触发 shouldQueue，shouldQueue 也不用去理队列的执行情况，只根据当下的判断去决定是否应该分发队列。

如果你觉得你的结论是正确的，可以贴出你的伪代码，再来讨论一下，我对这个话题也很感兴趣。

3年前评论

levi （楼主）

①你说的对，shouldQueue和handle不是同步执行的关系，是异步的，所以这里还是要考虑加锁，比如通过redis或者mysql；②而handle之间就如上条回复说的，在单个队列中是先进先出的原则，one by one；③redis加锁你上面给出思路了，但是还需要考虑解锁，这就需要在handle和failed中分别添加，比较繁琐；而在shouldQueue中通过mysql加锁，由于和handle是异步执行的，那么就存在handle还未执行，shouldQueue已释放锁了；④最后又回到原点了，有个最简单的方法，当前event要操作的model，在handle通过mysql排它锁去判断是否要执行，而shouldQueue仅作为非当前业务的判断，这样是最简单的，举个简单例子，退款处理：shouldQueue只判断订单是否存在，只要存在就添加到队列，而handle才会通过mysql排它锁去判断是否已经退款，这样来看，是最简单，且最万无一失的，无论同时并发多少

MArtian （作者）

@levi 同意 :+1:

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容，与人为善，比聪明更重要！

帮助

laravel异步事件中`shouldQueue`存在的问题

代码如下：

测试如下：

结论：

高认可度评论：

结论：

结论：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

laravel异步事件中`shouldQueue`存在的问题

代码如下：

测试如下：

结论：

高认可度评论：

结论：

结论：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

请登录