Redis失效不会导致RabbitMQ连接断开，因Laravel的RabbitMQ驱动不依赖Redis维持AMQP连接；真正影响消费者持续运行的是AMQP连接稳定性、进程存活及worker生命周期管理。
Redis 失效和 RabbitMQ 长连接是两件事——Laravel 的 RabbitMQ 队列驱动本身不依赖 Redis 存储连接状态，所以“Redis 失效导致 RabbitMQ 连接断开”这个前提不成立。真正影响 RabbitMQ 消费者持续运行的，是 AMQP 协议层的连接稳定性、消费者进程存活状态，以及 Laravel 队列 worker 的生命周期管理。
为什么 Redis 失效不会直接导致 RabbitMQ 连接断开
在 laravel-queue-rabbitmq 驱动中：
- Redis 仅用于 Laravel 自身的
failed_jobs表（如果用的是 database 驱动）或 Horizon 的监控/统计，不参与 AMQP 连接维持 - RabbitMQ 连接由 PHP 进程通过
amqp-client建立并持有，连接对象（Connection和Channel）生命周期绑定在当前 worker 进程内 - Redis 宕机时，
php artisan queue:work进程仍可正常消费 RabbitMQ 消息，只是失败任务可能无法写入failed_jobs（若你配置的是 redis 驱动的 failed_jobs，则会报错但不影响消费主流程）
真正需要关注的自动重连场景
实际生产中，RabbitMQ 连接中断通常来自：
- 网络抖动或防火墙超时（如 60 秒空闲被断开）
- RabbitMQ 节点重启或集群切换
- 客户端未设置心跳（
factory.setHeartbeat(30)），服务端主动关闭连接 - worker 进程异常退出后未被 supervisor 正确拉起
这些情况与 Redis 无关，但容易被误归因。关键要区分：连接层重连靠 amqp-client 自动恢复，进程层存活靠 supervisor 管理。
必须开启的两个自动恢复开关
laravel-queue-rabbitmq 底层使用 amqp-client，4.0.0+ 版本默认开启 Connection 自动恢复，但需显式启用 Topology 恢复（否则队列/交换机声明丢失）：
- 在
config/rabbitmq.php的'options'中添加：'automatic_reconnect' => true（部分封装库支持该键，本质是调用setAutomaticRecoveryEnabled(true)） - 务必设置：
'topology_recovery_enabled' => true（否则重连后 consumer 无法重新绑定到队列） - 建议配置心跳：
'heartbeat' => 30（单位秒，避免被中间设备断连） - 重连间隔可调（默认 5 秒）：
'network_recovery_interval' => 10000（毫秒）
Supervisor 是 RabbitMQ worker 的生命线
Laravel 的 queue:work 是长运行进程，一旦崩溃就彻底停止消费。Redis 失效本身不会杀进程，但其他异常（如 OOM、PHP Fatal Error、AMQP 协议错误未捕获）会。此时靠 Supervisor 重启：
-
autostart=true和autorestart=always必须启用 -
stopwaitsecs=30给 worker 时间优雅关闭 channel - 日志里看到
Connection closed unexpectedly或Broken pipe后进程退出，就是 Supervisor 该介入的时候 - 不要依赖
--tries参数来“兜底”连接问题——它只控制单个任务的重试次数，不解决连接断开
真正容易被忽略的是：Topology 恢复未开启时，重连成功但 consumer 不再收消息，日志静默，排查成本极高。
