rabbitmq重复消费根源在于amqp协议“至少一次投递”机制及默认行为：消费者断线未ack消息会requeue重投，而php7.4 amqp扩展不自动处理message_id或幂等，必须由生产者显式设置全局唯一message_id，并由消费者用redis setnx原子去重。
PHP7.4 + amqp扩展下，重复消费的根源在哪
不是你的代码写错了，是 AMQP 协议和 RabbitMQ 的默认行为决定的：消费者断线后，未 ack 的消息会自动 requeue，broker 重新投递时，新连接上的消费者根本不知道这条消息是否已被处理过。PHP7.4 的 amqp扩展（基于 librabbitmq-c）本身不提供幂等能力，也不自动携带或校验 message_id；如果你没显式设置 message_id、也没在消费前做去重判断，那断线重连后重复消费就是必然结果。
必须由生产者显式注入 message_id，不能依赖 broker 自动生成
RabbitMQ 默认的 message_id 字段为空字符串，所有消息共享同一个空 key —— 这意味着你用 Redis 做 setIfAbsent 时，第一条消息就占满整个“空 ID”，后续所有消息都判定为重复。必须由生产者在发消息时手动赋值：
- 使用
AMQPBasicProperties显式设置：$props = new AMQPBasicProperties(['message_id' => uniqid('msg_', true)]); - 确保该 ID 全局唯一且稳定（比如拼接业务类型+时间戳+随机串，避免纯
rand()） - 不要用数据库自增 ID 或订单号直接当
message_id，除非你确认它在全系统维度不重复（例如跨分库分表场景下易冲突）
消费者端用 Redis setIfAbsent 实现原子去重
PHP7.4 下推荐用 Predis\Client 或 phpredis 扩展调用 SETNX（即 setIfAbsent），关键点不是“存”，而是“原子性判断+设置”一步完成：
- 调用
$redis->set($msgId, '1', ['NX', 'EX' => 86400])，返回true表示首次消费，false表示已存在 -
EX参数必须设 —— 不设 TTL 会导致 Redis 中堆积大量死 key，24 小时（86400 秒）是常见值，应略大于业务最长生命周期（比如订单超时关单是 30 分钟，这里至少设 3600） - 不能先
GET再SET，这是竞态漏洞：两个并发消费者可能同时读到 null，然后都写入成功 - 如果业务逻辑抛异常，需确保不执行
basic_ack，让消息重回队列重试；但幂等 key 已写入，下次进来直接跳过
为什么不用数据库唯一约束做幂等
在 PHP7.4 高频消费场景下，MySQL 唯一索引方案容易成为瓶颈：
- 每次消费都要走一次 INSERT，即使失败也要触发唯一键校验，IO 和事务开销远高于 Redis 的内存操作
- 若业务本身不落 DB（比如只是发短信、推通知），额外加一张
t_idempotent_log表反而引入不必要的复杂度和延迟 - 事务回滚时，InnoDB 的 gap lock 或 insert intention lock 可能导致死锁，尤其在 prefetch > 1 时
- 仅适合“消费即落库”且 QPS UNIQUE(order_id)
真正容易被忽略的是：幂等 key 的生命周期必须覆盖「消息可能被重试的最大时间窗口」，而不是业务处理耗时。比如你设了 1 小时 TTL，但 RabbitMQ 因网络问题卡了 2 小时才重发，那这条消息还是会重复执行 —— 所以 TTL 要按运维侧最大重试间隔来定，不是拍脑袋。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
