rabbitmq集群必须启用镜像队列且三要素（exchange、queue、message）均需持久化，php worker须手动管理连接与channel生命周期并实现幂等逻辑。
RabbitMQ 集群必须启用镜像队列，否则单节点宕机=队列不可用
镜像队列不是可选项，是 PHP 分布式任务系统存活的前提。默认单节点部署时，rabbitmqctl set_policy 不生效，必须显式配置策略并验证镜像状态：
- 执行
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'后，需运行rabbitmqctl list_policies确认策略已加载 - 队列声明时必须传
durable => true，否则镜像策略不生效——非持久化队列不会被复制 - 消费者连接应使用集群 VIP 或负载均衡地址（如
amqp://user:pass@rabbitmq-lb:5672），而非直连某台节点 IP - PHP 客户端（如 php-amqplib）需设置
connection_timeout和retry_limit，避免因临时网络抖动导致连接卡死
消息持久化三要素缺一不可：Exchange、Queue、Message 全部要设 durable/delivery_mode
只设 Queue 持久化，Exchange 是临时的，重启后 Exchange 丢失，生产者发消息直接报 NOT_FOUND；只设 Message delivery_mode=2 但 Queue 不持久，RabbitMQ 重启后队列消失，消息进黑洞。真实错误现象包括：
- 服务重启后，
php artisan queue:work报错ChannelException: Channel is closed，本质是队列元数据丢失 - 消费者进程正常运行，但新消息始终不被消费——因为路由路径（Exchange → Queue binding）已失效
- 使用
php-amqplib时，$channel->queue_declare()必须显式传第 2 参数true（durable），不能依赖默认值
PHP Worker 进程管理必须与 RabbitMQ 连接生命周期对齐
常见错误是把 RabbitMQ 连接写在 Worker 循环外，长期复用一个连接，结果遇到网络闪断或心跳超时后，后续 basic_consume 调用静默失败。正确做法是：
- 每个任务处理周期内重建 Channel（不是 Connection），避免 Channel 失效累积；Connection 可复用，但需监听
AMQPConnectionException并重连 - 不要依赖 Laravel 的
queue:work --daemon模式，它不自动恢复 AMQP 连接；改用supervisord管理常驻进程，并配置autorestart=true - 消费者代码中必须捕获
AMQPProtocolChannelException和AMQPConnectionException，并在异常后主动 close channel / connection，再重建 - 设置
heartbeat=30（单位秒）并启用keepalive，否则云环境 NAT 超时会悄无声息断连
Redis 作轻量队列时，BLPOP + RPOPLPUSH 组合才能模拟可靠投递
纯 lpush/brpop 无法保证“至少一次”，Worker 进程崩溃会导致消息丢失。必须引入 pending list 机制：
- 消费者用
BRPOPLPUSH realtime_queue realtime_processing 0原子性地将消息移入处理中队列 - 成功处理后，用
LREM realtime_processing 1 $msg清除；失败则保留，由定时任务扫描realtime_processing中超时消息并重推 - PHP 中调用需检查
redis->blPop()返回值是否为false（超时），避免空循环耗 CPU - 该模式下 Redis 必须开启 AOF +
appendfsync everysec，否则实例崩溃时 pending list 丢失
真正难的是让 PHP Worker 在连接中断、消息重复、节点切换时不丢状态也不重复执行——这要求你亲手控制 Channel 生命周期、显式处理每种 AMQP 异常、并为每条消息设计幂等落地逻辑，而不是依赖框架黑盒。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
