Laravel 的队列队列系统，说白了就是队列把耗时任务往后挪。不是队列所有活儿都得当场干完，比如发邮件、队列处理图片、队列调用第三方API——这些操作让用户干等几秒，队列体验直接崩盘。队列Redis 作为队列驱动，队列性能比数据库驱动高一个量级，队列内存操作，队列毫秒级响应。队列

配置起来不复杂。队列`.env` 文件里把 `QUEUE_CONNECTION` 改成 `redis`，队列然后 `composer require predis/predis` 装上依赖。队列Laravel 底层用 `illuminate/redis` 组件管理连接，队列默认走 `default` 连接池。这里有个坑：如果你用了 Redis 集群，得在 `config/queue.php` 里单独配置 `redis` 连接的选项，不能直接用默认配置。

任务类长这样：

namespace App\Jobs; class SendWelcomeEmail implements ShouldQueue {  use Dispatchable, InteractsWithQueue, Queueable, SerializesModels; public $user; public function __construct(User $user) {  $this->user = $user; } public function handle() {  Mail::to($this->user->email)->send(new WelcomeMail()); } }

分发的时候 `SendWelcomeEmail::dispatch($user)` 就完事了。但有个细节：Eloquent 模型会被序列化后塞进 Redis，任务执行时再反序列化。如果这期间模型被删了，任务会直接失败。所以任务里用 `$this->user->fresh()` 或者只存 `user_id`，别直接操作序列化后的模型。

跑队列的命令是 `php artisan queue:work`，生产环境用 `queue:work --daemon`（老版本）或者直接 `queue:work`（新版自动常驻）。这里有个实际场景：我见过一个团队把队列进程跑在 `supervisor` 里，但忘了设置 `--tries=3`，结果任务无限重试，Redis 内存爆了，整个服务挂了。最后加了个 `$tries = 3` 属性，再配合失败队列 `failed_jobs` 表，才算稳住。

Redis 队列有个特性：任务可以延迟执行。`SendWelcomeEmail::dispatch($user)->delay(now()->addMinutes(10))`，底层实现是 Redis 的 sorted set，按执行时间排序。这玩意比 `sleep()` 靠谱多了，不阻塞进程，还能跨机器分布式执行。

监控队列状态，用 `php artisan queue:monitor redis:default` 能看任务数、延迟时间、失败率。个人经验：别迷信这个命令，它只能看当前连接的状态。真正出问题的时候，不如直接 `redis-cli llen queues:default` 看列表长度，`zcard queues:delayed` 看延迟队列，比啥监控都直观。

还有个冷门但实用的技巧：`queue:work` 可以指定处理特定队列，比如 `php artisan queue:work redis --queue=emails`。业务量大时，把邮件队列和图片处理队列分开跑不同进程，互不干扰。我见过有人把所有任务塞进一个队列，高峰期一个任务卡住，后面全堵着，那叫一个酸爽。

最后说个坑：Redis 队列的任务重试机制是 Laravel 自己实现的，跟 Redis 的持久化策略有关系。如果你用的 Redis 没开 AOF 持久化，重启 Redis 后队列数据直接丢，所有未完成任务消失。生产环境务必开启 `appendonly yes`。别问我是怎么知道的——线上事故换来的一行配置。