Laravel队列从本地Redis迁移至AWS ElastiCache后任务不执行

版本兼容性结论 #

首先明确：predis 1.1.1 与 Redis 6.2.6 不存在阻断队列运行的兼容性问题。
Laravel队列依赖的LPUSH/BRPOP等基础列表命令在Redis 3.2到6.2版本间逻辑完全一致，predis 1.1.x默认使用RESP2协议通信，可正常对接Redis 6.x分支，版本差不是该问题的核心诱因。

按优先级排查解决步骤 #

• 第一步：先验证基础网络与连通性
  直接在运行队列worker的服务器上执行连接测试：

  redis-cli -h <替换为你的ElastiCache节点内网地址> -p 6379 -a <替换为Redis密码，无密码则省略> ping
  

  正常应返回PONG。如果连不通优先排查：

  • ElastiCache绑定的安全组是否放开了应用服务器内网IP对6379端口的入站权限
  • 服务器与ElastiCache是否在同一VPC下，ElastiCache默认不支持公网访问，跨VPC需提前做对等连接
  • 如果ElastiCache开启了传输中加密（TLS），predis 1.1.1默认不识别加密连接，需要把配置里的host值加上tls://前缀，否则会出现连接超时、无明确报错的情况
  • 如果ElastiCache开启了ACL权限控制，确认使用的账号有配置的3号库的读写权限

• 第二步：确认配置真实加载，排除缓存/进程残留影响
  php artisan queue:restart的作用是向当前配置指向的Redis中写入重启信号，让正在运行的worker收到信号后自杀重启，切配置场景下这个命令完全不可靠：你之前执行命令返回的

  Broadcasting queue restart signal.
  仅代表重启信号写入了当前连接的Redis，如果你执行命令时已经把Redis配置切到ElastiCache，但老worker还连着本地127.0.0.1的Redis，worker根本收不到重启信号，会一直跑在旧连接上。
  正确操作流程：

  1. 先停掉所有托管队列worker的进程，比如用supervisor管理的就执行supervisorctl stop all
  2. 清除Laravel配置缓存：php artisan config:clear，避免旧配置缓存覆盖.env修改
  3. 进入tinker验证实际加载的配置：

     php artisan tinker
     >>> config('database.redis.default.host')
     

     确认返回值是ElastiCache地址而非127.0.0.1，同时检查config('queue.connections.redis.connection')对应的Redis连接配置和你使用的队列连接匹配
  4. 重新启动队列worker进程

• 第三步：验证任务投递与消费的链路匹配
  连接到ElastiCache实例，切换到3号库查看队列key：

  redis-cli -h <ElastiCache地址>
  > SELECT 3
  > KEYS queues:*
  

  投递一个测试任务后重复执行KEYS queues:*：

  • 如果看不到新生成的队列key，说明任务投递逻辑依然在连本地Redis，配置没有全局生效
  • 如果能看到队列key且列表长度持续增长，说明worker进程没有成功连接到ElastiCache，直接查看storage/logs/laravel.log中的Redis连接报错即可定位问题，常见原因是TLS配置缺失、密码错误、安全组拦截

• 特殊配置排查
  如果你创建的ElastiCache是集群模式（启用Cluster Mode），当前配置里'cluster' => false会导致连接失败，需要把cluster配置改为true，并调整predis的集群连接参数。

内容的提问来源于stack exchange，提问作者Ammar Tariq