php消费者需配置死信队列、指数退避重试、业务主键幂等校验及分层重试策略，否则易导致重复消费、负库存等问题。
PHP 消费者要真正可靠，光靠 while(true) 循环取消息远远不够——死信没配、重试乱套、重复消费不拦截，任何一环出问题，订单就可能重复创建、库存就可能扣成负数。
为什么 RabbitMQ 的 basic_reject + requeue=true 不能当重试用
RabbitMQ 默认的拒绝重入队（basic_reject(..., requeue=true)）看似是“重试”，实则是把消息立刻塞回队头，下一次 basic_consume 就可能立刻又拿到它。这会导致：CPU 空转、消费者线程卡死、瞬时流量打垮下游服务。
- 真实重试必须带退避（如指数退避），不能立即重投
-
requeue=true不经过 TTL，无法实现延迟重试，也不进死信流程 - 若消费者崩溃，这条消息会不断被其他实例抢到，形成“重试风暴”
- 正确做法是：失败时
basic_reject(..., requeue=false)，让消息进死信队列，再由专用延迟队列或定时任务触发重试
PHP 中配置死信队列的关键参数和易错点
死信不是自动发生的，必须在声明普通队列时显式绑定死信交换机与路由键；漏掉任意一个参数，消息就永远不会进 DLQ。
-
x-dead-letter-exchange必须存在且已声明为direct或topic类型，不能是fanout（否则无法按 key 路由） -
x-dead-letter-routing-key要和后续绑定死信队列时使用的 routing key 完全一致（大小写敏感） -
x-message-ttl若用于延迟，单位是毫秒；设成"5000"是 5 秒，但设成5就是 5 毫秒——极易因类型错误导致“延迟失效” - PHP 使用
AMQPQueue::setArgument()时，值必须是字符串或整数，不能传布尔值或 null
幂等性必须由业务层控制，message_id 不够用
RabbitMQ 的 message_id 是生产者可随意设置的字段，不具备唯一性和可信度；仅靠它做去重，等于把信任交给上游，风险极高。
- 推荐用业务主键哈希（如
md5("order_123456")）作为幂等 key，存入 Redis 并设 TTL（建议略长于业务最大处理周期） - 消费者必须在
process()开头就SETNX校验，成功才继续；失败直接ack或丢弃，不抛异常 - 不要在数据库里查“是否已存在记录”来判断幂等——高并发下查-写非原子操作，仍可能重复落库
- 注意 PHP-FPM 进程复用：Redis 连接未及时 close 或未重连，会导致
SETNX始终失败
重试次数和死信路由必须分层设计，不能全堆在一个队列里
把所有失败消息都扔进同一个死信队列，等于放弃重试策略的灵活性——你无法区分是网络抖动（该 1s 后重试）、还是数据格式错误（该进人工干预）。
- 建议至少两层：第一层 TTL=1s/5s/30s 的“快速重试队列”，绑定到同一业务交换机；第二层 TTL=1h 的“兜底死信队列”，路由到
dlq.fatal供告警或人工介入 - 每个重试层级对应独立的消费者进程，避免互相阻塞
- 在消费者中记录
x-deathheader（RabbitMQ 自动注入），从中提取count字段判断当前是第几次死亡，决定下一步路由 - 别忽略
content_type和encoding：JSON 消息若被误解析为 raw string，json_decode()失败后反复进死信，最终撑爆内存
最常被跳过的其实是 x-death header 解析和 Redis 连接生命周期管理——这两处不处理好，重试和幂等都会在压测时突然崩掉。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
