RabbitMQ重复消费需靠幂等性解决，而非ack/nack；推荐Redis set(NX+EX)基于messageId实现轻量幂等，辅以数据库唯一约束或业务状态机等方案。
PHP 使用 AMQP 扩展消费 RabbitMQ 消息时，ack/nack 是控制消息生命周期的关键操作，但它们本身不解决重复消费问题。重复消费是 RabbitMQ “至少一次投递”语义下的必然现象，必须由消费者主动实现幂等性。核心思路是：不管消息来几次，业务处理结果一致。
ack/nack 的真实作用与常见误区
ack 表示“我已成功处理，可安全删除这条消息”，nack（带 requeue=true）表示“这次处理失败，麻烦重发一次”。但要注意：
- 手动 ack 不等于防重复 —— 即使你每次都正确调用 ack，网络中断、进程崩溃仍会导致 broker 重发
- autoAck = true 更危险：消息一发出就删，一旦消费者宕机，消息直接丢失
- nack 后重发 ≠ 重复消费可控：它只是触发重试，不保证只重试一次，也不阻止其他消费者同时拉到同一条消息
幂等设计首选：Redis setIfAbsent + 全局 messageId
这是目前 PHP 场景下最轻量、高并发友好、原子性强的方案。关键不在“怎么存”，而在“怎么判断+怎么设过期”。
- 生产者必须显式设置 messageId，例如：
$msg->set('message_id', uniqid('msg_', true))；不能依赖 RabbitMQ 自动生成（默认为空） - 消费者拿到消息后，立即执行：
$redis->setex($messageId, 86400, '1')或更优的原子命令：$redis->set($messageId, '1', ['NX', 'EX' => 86400]) - 若返回 false（key 已存在），直接 ack 并 return；若 true，执行业务逻辑，完成后正常 ack
- TTL 必须设 —— 建议按业务消息最长有效周期定，比如订单类设 48 小时，通知类设 24 小时
数据库唯一约束方案：适用但有边界
适合业务本身强依赖 DB、且消费即落库的场景，比如“创建订单后发 MQ 更新库存”，此时在库存操作表加 UNIQUE INDEX (msg_id) 即可。
立即学习“PHP免费学习笔记（深入）”；
- 用
INSERT IGNORE INTO consume_log (msg_id) VALUES (?)或事务内先查再 insert，失败则跳过 - 缺点明显：每次消费都写 DB，QPS 上千时易成瓶颈；事务未提交前其他请求查不到记录，仍有竞态风险
- 不适合纯内存操作型业务（如发短信、调第三方 API），为幂等额外加 DB 落盘得不偿失
业务逻辑层幂等：最根本也最易被忽略
技术手段是兜底，真正的健壮性来自业务设计。例如：
- 支付回调：用“订单状态机”，只允许从
unpaid → paid，重复回调时状态已是paid，直接返回成功 - 积分发放：先查用户当前积分快照，再按「期望发放后积分 = 当前 + X」执行
UPDATE user SET score = ? WHERE id = ? AND score = ?，影响行为 0 则说明已被处理 - 避免“先查后改”这种非原子操作，尽量用带条件的单条 SQL 或 Redis Lua 脚本封装校验+变更
