做PHP后端这几年，要说哪类问题最让人头疼，消息重复消费绝对排得上号。你辛苦写了半天的消费逻辑，在测试环境跑得风调雨顺，一上生产就开始给你反复执行同一条消息——扣款扣两次、库存减两次、短信发两条，问题一出就是线上事故。我自己就经历过一次凌晨两点被叫起来修重复入账的经历，从那以后，"幂等消费"这四个字直接刻进了我的开发习惯里。这篇文章就把我这套基于PHP的幂等消费方案完整拆开讲清楚，包括为什么需要、怎么设计、怎么落地、有哪些坑，适合正在用消息队列处理业务、或者被重复请求折磨过的小伙伴参考。
1. 幂等消费到底解决的是什么问题
1.1 先搞清楚消息为什么会重复
很多人一开始想不明白：消息队列又不是快递，怎么会送两次？实际上，重复消费是分布式系统的常态，不是偶然。绝大部分消息队列（比如RabbitMQ、Kafka）为了保证消息不丢，都采用"至少一次"（at least once）的投递语义。意思是：消息可能会重复，但不能丢。这个语义背后是消息队列的精力和网络现实妥协后的结果——生产者发送消息后没收到确认，它会重发；消费者处理完消息后还没来得及提交ack，连接就断了，消息队列就会重新投递；消费者进程在处理消息过程中崩溃、重启，未提交的消息也会被再次投递。
我举一个最常见的场景：你用的是RabbitMQ手动ack模式，消费逻辑执行完毕，业务数据也入账了，结果在调用basic_ack的一瞬间网络闪断，消息没有确认成功。Broker以为消费者没处理完，过了一会儿就把同一条消息重新投递给你了。这时候你的业务代码已经跑过一遍，再跑一遍就出问题了。这个现象在PHP长连接消费者里尤其常见，因为PHP脚本挂了之后重启很快，Broker还没来得及等超时，就又塞了一条消息过来。
1.2 不幂等的后果是实打实的钱和信任
重复消费不是理论问题，是直接的经济损失。我这里说几个真实案例。
案例一：用户在小程序里下单，后端订单服务通过消息队列通知积分服务加积分。由于消费端没有幂等保护，网络抖动导致同一条"订单完成"消息被投递了三次，用户的账号里多了三倍积分。这种问题对用户来说像是"天上掉馅饼"，但对公司来说就是实打实的负债。如果场景换成余额扣减、库存扣减，那就直接变成资损事故了。
案例二：营销短信场景。用户在活动页触发了一条"注册成功送券"消息，消费端没做幂等，消息重试三次，用户手机上就收到三条一模一样的短信。用户的第一反应不是"这平台真大方"，而是"这平台系统有毛病"，信任感直接崩塌。
案例三：对账文件生成。凌晨跑批，定时任务从消息队列里消费一批交易记录去生成对账文件，如果消息被重复消费，同一个交易就会出现两次，对账结果直接不平，财务早上来上班就得灭火。
这些案例有一个共同点：系统本身没有感知到"这条消息我之前处理过"。幂等消费的核心，就是让系统在重复收到同一条业务消息时，能识别出来，并且忽略掉，或者返回之前的结果，保证业务数据只被处理一次。
1.3 幂等和去重、并发控制的区别
聊幂等之前，有三组容易混淆的概念先理清楚：幂等、去重、并发控制。
去重指的是在数据写入环节通过唯一键等机制，丢弃重复数据；幂等是一个更上层的能力，强调"同一个请求执行多次，最终结果一致"；并发控制则是防止多个请求同时操作同一份数据导致不一致。
这三者经常一起出现。比如你的消费逻辑是"插入一条支付流水"，那既要做幂等（重复消息不重插），又要做并发控制（同一笔订单不能有两个支付请求同时插入成功），还要做去重（按订单号+渠道流水号唯一约束）。方案设计时这三者要统筹考虑，不能只解决一个。下文要讲的方案里，Redis锁解决的主要是并发和重复问题，数据库唯一键解决的是最终一致性的兜底问题，两者配合才是完整的幂等方案。
2. 幂等方案怎么选：从简单到复杂的四套打法
2.1 方案一：业务层天然幂等（适合状态机型业务）
最轻量的做法，是让业务本身具备幂等性。什么叫业务天然幂等？就是"无论这个操作被调用多少次，产生的结果都一样"。
最典型的是状态机业务。以订单系统为例，订单状态流转是：待支付 → 已支付 → 已发货 → 已完成。如果消费逻辑是先判断当前订单状态，只允许"待支付"状态下执行扣款和状态变更为"已支付"，那么即使同一笔支付成功的消息重复投递十次，也只有第一次能成功执行状态流转，后面的都被状态判断拦截了。MySQL的行级锁配合状态条件更新（UPDATE orders SET status='paid' WHERE id=? AND status='pending'），天然就能实现幂等。
这种方案的优点是代码零额外依赖，纯粹利用业务规则的约束。缺点是适用范围窄，只适合状态流单一、有状态可判的场景。如果业务没有状态，比如"给用户增加积分"、"追加一条操作日志"，业务天然就不幂等，得靠下面几个方案。
2.2 方案二：数据库唯一约束保底（最硬核的兜底）
利用数据库唯一索引，是防重复消费最后一道防线。做法是：在业务表上建立唯一键，这个唯一键由业务幂等ID（比如订单号+业务类型）构成。消费逻辑执行时，先尝试插入一条带有幂等ID的记录，如果插入成功说明是首次消费，执行后续业务逻辑；如果插入失败因为唯一键冲突（MySQL报1062错误），说明这条消息已经处理过，直接跳过。
我一直认为，任何核心交易链路都必须有这个兜底。Redis可能丢数据，分布式锁可能超时，但数据库的唯一索引一旦建立，除非有人把约束删了，否则它就是物理级别的幂等保证。这个方案特别适合与业务数据同库写入的场景，它不需要额外的中间件，维护成本低。
需要注意：唯一键冲突本身会占用一次写事务、产生一次死锁检测的开销，高并发场景下大量重复消息同时涌来，唯一键冲突会拖慢数据库性能。所以方案二一般是"保底"，不是"首选"。优秀的设计是：先用Redis拦住99%的重复消息，只有极少数漏网之鱼落到数据库唯一键上。
2.3 方案三：Redis幂等标记（性能最佳的拦截层）
Redis做幂等标记是业界最常用的方案，适合对性能要求高、请求量大的场景。核心思路：用一个唯一消息ID作为Redis key，消费前用SET key value NX EX timeout（或者SETNX）抢占这个标记。抢到了，说明这是第一次消费；没抢到，说明消息重复了，直接丢弃。
这个做法相当于给消息发了一张"已处理"的凭证。每次消费的第一件事不是去查数据库、不是执行业务逻辑，而是先在内存级的Redis里做一次存在性判断。因为Redis的单线程模型保证SETNX是原子操作，多个并发请求同时来，只有一个能成功，这正是我们要的。
方案三最适合作为系统的第一道拦截层。但要注意，它只能防"处理过的消息重复到达"，防不了"第一条还没处理完，第二条重复消息就到了"的情况——这种情况需要引入锁的语义，或者把幂等标记的过期时间设置大于消息重试间隔。具体技术细节在第四章详细说。
2.4 方案四：消息表+本地事务（分布式环境最稳的保证）
当Redis不可靠（比如Redis挂了）、网络分区、消费进程崩溃时，需要最后兜底。方案一不行、方案二有冲突性能损耗、方案三防不住极端情况，这时候可以用"本地消息表"。
做法是这样的：消费者在本地数据库里建一张message_processed表，字段包含消息唯一ID、业务类型、处理状态、处理时间。消费流程是：
- 开启数据库事务；
- 查询
message_processed表里是否存在这条消息ID； - 不存在则插入消息记录，同时执行真正的业务逻辑（比如更新订单、变更账户余额）；
- 事务提交。
因为消息记录的插入和业务数据更新在同一个事务里，要么一起成功，要么一起回滚，不存在"业务更新了但消息没标记"的中间状态。即使消费者在处理完业务后、事务提交前崩溃了，消息队列重新投递时，本地消息表里查不到记录，就会再处理一遍，但这个"再处理"是安全的，因为事务回滚了，业务也没真正生效。
这四种方案不是互斥的，而是可以组合使用的。我自己的最佳实践是：Redis拦截（方案三） + 数据库唯一约束兜底（方案二）。Redis负责挡住绝大多数重复消息，数据库唯一约束负责挡住极端情况下Redis失效后的漏网之鱼，性能与可靠性兼得。
3. PHP落地实操：Redis去重 + 数据库唯一键双保险
3.1 整体流程设计
我用一个"用户签到送积分"的业务来演示。用户每天签到一次，系统给他加10积分。签到事件从API服务发到消息队列，积分服务消费这条消息。
这个业务看起来简单，但"用户同一天重复签到"就是个天然的消息重复场景。暴力测试一下：一天内用户连续点击签到按钮十次，API层即使有防抖，网络重试也可能把同一天的签到消息发多次。
我的消费流程设计是这样：
- 消费者从队列里拿到消息，解析出消息唯一ID（这里用
user_id + 业务日期拼一个签到幂等ID）； - 先用Redis的
SET NX EX尝试写入幂等标记； - 抢到标记的，继续往下走；没抢到的直接ack，不重复处理；
- 抢到标记后，写签到记录表，同时依靠签到记录表的
user_id + sign_date唯一索引兜底； - 签到记录插入成功后，执行加积分逻辑；
- 最后释放Redis标记（或者等它自然过期）。
流程图在脑子里过一遍就是：Redis拦截 → 业务处理 → 数据库兜底。每一层各司其职，相互配合。
3.2 关键代码实现
先看消息实体。假设队列里投递过来的消息是JSON格式：
{ "msg_id": "9f8e7d6c-5b4a-3c2d-1e0f-abcdef123456", "biz_type": "user_sign", "user_id": 10086, "sign_date": "2025-01-15" }msg_id是全局唯一消息ID，由生产者生成。biz_type区分业务类型，user_id和sign_date是业务数据。
我一般会封装一个幂等消费的辅助类，把它做成一个简单的中间件。先看PHP代码实现：
<?php class IdempotentConsumer { private Redis $redis; public function __construct(Redis $redis) { $this->redis = $redis; } /** * 尝试获取幂等标记 * 返回 false 表示消息重复，不用处理 */ public function tryAcquire(string $idempotentKey, int $ttl = 3600): bool { // Redis SET NX EX 原子操作 // NX：key不存在时才设置成功 // EX：设置过期时间，单位秒 $result = $this->redis->rawCommand( 'SET', $idempotentKey, '1', 'NX', 'EX', $ttl ); return $result === true || $result === 'OK'; } /** * 处理消息的统一入口 * $handler 是一个闭包，里面是真正的业务逻辑 */ public function consume(string $idempotentKey, callable $handler, int $ttl = 3600): void { if (!$this->tryAcquire($idempotentKey, $ttl)) { // 说明这条消息已经处理过或者正在处理中 return; } try { $handler(); } catch (Throwable $e) { // 业务处理失败，释放幂等标记，允许消息重试 $this->release($idempotentKey); throw $e; } } /** * 释放幂等标记 * 只有在业务处理失败时才需要释放 */ public function release(string $idempotentKey): void { $this->redis->del($idempotentKey); } }注意rawCommand是PHP Redis扩展的一种用法，它可以把SET key value NX EX ttl当作一条原生命令发给Redis，确保原子性。如果你用的是Predis这类纯PHP客户端，写法略有差异，但命令本身是一样的。
使用这个辅助类的消费逻辑：
<?php // 假设这是消息队列框架的消费者入口 function handleSignMessage(array $message): void { $idempotentKey = sprintf( 'idempotent:sign:%s:%s', $message['user_id'], $message['sign_date'] ); $consumer = new IdempotentConsumer($redis); $consumer->consume($idempotentKey, function () use ($message) { // 1. 插入签到记录（利用数据库唯一索引兜底） $inserted = insertSignRecord( $message['user_id'], $message['sign_date'] ); // 2. 插入成功才加积分 if ($inserted) { addPoints($message['user_id'], 10); } }, 86400); // 幂等标记保留一天，保证当天重复签到不会二次处理 }这里有一个细节：插入签到记录用INSERT IGNORE还是先查后插？我的习惯是用INSERT ... ON DUPLICATE KEY UPDATE或者INSERT IGNORE，让它通过数据库唯一键直接把重复数据拦掉，返回受影响行数为0就说明是重复记录，不需要抛异常。这样数据库层面天然幂等，代码也不用区分"异常导致失败"和"重复导致冲突"。
再看数据库表结构：
CREATE TABLE `user_sign_record` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `user_id` INT UNSIGNED NOT NULL COMMENT '用户ID', `sign_date` DATE NOT NULL COMMENT '签到日期', `points` INT NOT NULL DEFAULT 10 COMMENT '获得积分', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_user_date` (`user_id`, `sign_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户签到记录表';uk_user_date这个唯一索引就是数据库层的幂等保证。同一用户同一天只能有一条签到记录，不管消息被投递多少次，第二次插入必然冲突。配合INSERT IGNORE，冲突不会报错，数据库帮我们静默忽略了重复数据。
加积分这个操作如果也想做幂等，最简单的做法是：把积分变更记录也做成一张流水表，唯一键是user_id + sign_date + type，同样用唯一索引兜底。核心逻辑就是：所有会产生累计效果的业务操作，都必须走"插入流水"而不是"直接改总数"。有了流水表，就算消费重复了，插不进去第二条流水。
3.3 与主流队列框架的配合
实际项目里，大家用的队列框架五花八门。这里说说ThinkPHP Queue、RabbitMQ和Kafka下怎么套用这套逻辑。
ThinkPHP Queue：这是国内PHP项目最常用的队列组件之一。在消费者类的fire方法里，把上面handleSignMessage的逻辑整体包起来即可。需要注意的是ThinkPHP Queue默认是自动ack的，也就是说pop出来后框架会立即删除消息，不存在"处理失败重新投递"的可能。如果你要手动控制重试，需要实现shouldHandle方法或者在消费失败时抛出异常，确保消息回到队列。
RabbitMQ：重点在于ack机制。消费者处理完消息后手动调用basic_ack，处理失败时调用basic_nack并决定是否重新入队。这种情况下，幂等标记要特别设计：如果业务处理失败了，一定要主动释放Redis的幂等标记，不然消息重新入队后再次投递，会因幂等标记还在而直接被丢弃，业务永远无法成功。我的做法是在catch块里调用release方法，把标记删掉，让重试的消息重新走一遍完整流程。
Kafka：Kafka的enable.idempotence是针对生产者防止消息重复发送的，和消费者幂等不是一回事。Kafka消费者靠的是offset提交机制来防止重复消费，但offset提交失败也会导致重复消费。所以Kafka这边同样要做消费幂等。注意Kafka默认的消费逻辑是拉取一批消息处理完后统一提交offset，批量处理时，幂等标记要按单条消息维度设置，不能用一个批量key代替。
4. 实战中的几个关键设计决策
4.1 幂等Key的设计：不能拍脑袋
幂等Key是整个方案的灵魂。Key设计得不好，要么挡不住重复，要么误杀正常业务。
先说Key的组成。最标准的格式是：业务类型 + 业务唯一标识。比如订单支付消息：idempotent:pay:order:{order_id}；签到消息：idempotent:sign:user:{user_id}:date:{sign_date}。这里的核心是"业务唯一标识"必须能唯一确定一条业务记录，而且不会因为参数顺序、空格、大小写变化而变化。
我之前踩过的一个坑：直接用消息队列自动生成的msg_id做幂等Key。消息重投时，有些生产者在重发时会重新生成一个msg_id，这就导致同一笔业务消息被赋予了不同的幂等Key，幂等失去了意义。所以幂等Key应该基于业务字段来生成，而不是依赖传输层的消息ID。生产者那边应该把这个msg_id固定下来，重试时复用同一个ID。如果你控制不了生产者，那就老老实实用业务字段拼Key。
4.2 Redis过期时间的选取策略
Redis幂等标记的过期时间（TTL）设置大有讲究。设短了，消息还没处理完标记就被清理了，后面重试的消息会再次进来；设长了，Redis key堆积，浪费内存，也可能误伤很久之后的重试请求。
我的经验是三个值取最大：业务并发处理峰值耗时 + 消息队列最大重试间隔 + 时钟偏移冗余。签到场景的处理逻辑很简单，几十毫秒就能跑完，消息重试间隔大多是几秒到几分钟，那TTL设置为1小时就够了。订单处理可能涉及调用外部接口、异步对账，耗时可能到秒级甚至分钟级，消息重试间隔可能到几分钟，那TTL建议设置2小时或更长。
有一个反向场景需要特别注意：延迟任务。有时候业务逻辑本身要等很久才完成（比如等待第三方支付回调），消费流程会在中途把消息重新入队延迟处理。此时幂等标记的TTL必须覆盖整个延迟周期，否则标记一过期，回调通知到达时又变成"第一次消费"，逻辑又跑一遍，数据可能就重复了。这个坑我在4.3节细说。
4.3 处理失败与重复消息怎么区分
这是最容易踩坑的地方。我遇到过不少同事，把"处理失败"和"消息重复"混在一起处理，结果业务数据莫名其妙就丢了。
严格来说，它们应该分开处理：
消息重复：消息内容一样、幂等Key一样，系统之前已经处理成功过。此时应该直接ack，跳过不处理。
处理失败：消息内容一样、幂等Key一样，但系统之前处理失败了，数据库里没有成功记录。此时应该允许它重试，不能因为幂等标记存在就直接丢弃。
区分方法很简单：幂等标记写入成功 ≠ 业务处理成功。理想的设计是幂等标记只在业务成功后写入。但现实是，业务处理往往需要一系列操作，你没法在"最开始"就知道最后能不能成功。
我的做法是分两个阶段：
- 先用
SET NX EX抢一个"处理中"标记； - 处理成功后，在同一个事务（或紧随其后）更新标记值为"success"；
- 处理失败时，主动删除标记，让下一条重试消息重新竞争。
坏消息是Redis没有原生的"比较值再删除"命令，用GET+DEL会有原子性问题。好在Redis官方有Lua脚本，可以原子地实现"如果值等于success才删除"。我在生产环境用的是这个方案。
真实项目中，我用Lua脚本做"删除指定值的key"：
-- 如果当前值等于 success 才删除 if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end但更多时候我干脆不主动删标记，而是把TTL设置得足够长，让"处理中"标记自然过期。处理成功的消息，幂等标记一直留着；处理失败的消息，等标记过期后重试消息就能再次进来。这样省掉了删除的复杂度，代价是Redis内存多占一会儿。对于日活百万以下的项目，这个代价完全可以接受。
4.4 消费处理的拆箱与装箱
PHP的消费逻辑里还有一个小细节：消息体解析。队列里传输的通常是JSON字符串，PHP端要json_decode成数组再处理。这里有一个我用得比较多的小技巧：
json_decode默认把JSON对象解析成stdClass对象，很多人习惯转成数组（第二个参数传true）再访问，这本身没问题。但如果消息里包含嵌套对象，数组转来转去容易丢失类型。更好的方式是用一个DTO类来承接消息，在构造函数里统一做数据校验和类型转换。比如：
class SignMessage { public function __construct( public readonly int $userId, public readonly string $signDate, public readonly string $msgId ) { } public static function fromJson(string $json): self { $data = json_decode($json, true, 512, JSON_THROW_ON_ERROR); // 这里可以做参数校验，缺字段就抛异常 return new self( (int)$data['user_id'], (string)$data['sign_date'], (string)$data['msg_id'] ); } }这样做的好处是：消息结构变化时，改动只集中在一个类里；消费代码里拿到的是强类型对象，不用到处写isset判空。对于长期维护的项目，这种"先装箱、再消费"的模式能让代码清爽不少。
5. 常见问题与排查技巧实录
5.1 Redis宕机后幂等失效怎么办
有同学问我：幂等依赖Redis，Redis挂了是不是就废了？这话只对了一半。Redis宕机，第一道拦截确实失效了，但我们的方案还有数据库唯一索引兜底。签到场景下，数据库唯一索引照样拦住重复数据。所以在设计时一定要记住：Redis是拦截层，不是保底层。真正的保底永远在数据库。
如果你的业务确实连数据库都拦不住（比如只有Redis才能承载的高频写操作，计数器类业务），那就需要对这个Redis做高可用。生产环境建议至少用Redis Sentinel或者Redis Cluster，主从切换后确保数据不丢。如果对一致性要求极高，可以考虑引入RedLock或者在业务上设计"允许小概率重复、事后补偿"的策略。
5.2 唯一键冲突导致业务异常
INSERT IGNORE虽然能静默处理重复，但如果你的业务对插入结果有区分需求（比如插入成功才加积分），直接用INSERT IGNORE拿不到"是否真的插入了"的信息，得用ROW_COUNT()或者改成ON DUPLICATE KEY UPDATE配合自增字段的技巧。
MySQL的INSERT ... ON DUPLICATE KEY UPDATE在冲突时会触发更新操作，ROW_COUNT()返回2（更新1行）或0（无变化）。要区分首次插入和重复冲突，可以用这样的小技巧：
INSERT INTO user_sign_record (user_id, sign_date, points) VALUES (10086, '2025-01-15', 10) ON DUPLICATE KEY UPDATE id = id; -- 影响行数为 1：首次插入 -- 影响行数为 0：重复冲突（没有实际更新）然后通过PDO::rowCount()判断是否产生了实际影响。用id = id这种无操作更新，既不会改动数据，又能触发MySQL的"匹配但未改变"逻辑，返回0或2，方便我们判断。
5.3 长任务与锁续期问题
我在4.2节提到过，TTL必须大于处理耗时。但如果你没法预估处理耗时上限（比如消息处理中要等第三方接口响应、要做人工介入），TTL固定值就不可靠了。这时需要"看门狗"机制，也就是给幂等标记续期。
实现不复杂：在业务处理过程中，如果发现标记快过期了，就重新设置TTL。用Redis Lua脚本或者直接EXPIRE命令都行。我在项目里是这样处理的：起一个定时器（或者利用PHP的pcntl_alarm/Swoole Timer），每30秒检测一次，如果业务还在处理中，就给幂等标记续期到另一个30秒。这样长任务永远不会因为TTL过期而被重复消费。
如果用纯PHP CLI做长任务，记得处理完业务后把定时器关掉，不然进程退出时会有隐患。
5.4 PHP常驻进程的内存泄漏排查
PHP做消息消费者有两种形态：一种是用框架自带的短生命周期进程（如ThinkPHP的php think queue:work，处理完一批就退出），一种是Swoole Workerman这类常驻内存进程。后者要注意内存泄漏。
我在一个Swoole消费服务里遇到过一个怪问题：批量消费时，内存图形一路往上爬，跑几天后OOM被系统杀掉，然后消息重新入队，再消费，再OOM，形成了一个死循环。
排查过程走了不少弯路。后来用memory_get_usage(true)打印内存快照，发现是json_decode出来的对象被业务代码长时间持有引用，导致垃圾回收器一直没有把它回收。解决方法是：在批量处理完一批消息后，主动unset()大变量，再调用gc_collect_cycles()。同时给消费者进程设置内存上限，超过就平滑重启。
这里给一个参考：PHP里的gc_collect_cycles()并不是每次都要调，它会阻塞进程。更推荐的做法是让Swoole的max_request或者max_coroutine机制自动回收，或者定期重启进程。内存问题靠"手动到处unset"是治标不治本，核心还是在代码里避免持有不必要的引用。
5.5 消息乱序到达的场景
有时候消息队列不保证有序（Kafka的单个分区默认有序，但业务可能跨分区；RabbitMQ的多个消费者并发消费天然乱序）。这会给幂等带来一个额外问题：后一条消息先到，先处理了；前一条消息后到，却被幂等拦截了。
举个具体例子：订单取消消息（status=cancelled）先到，处理成功，幂等标记写入；几分钟后，订单创建消息（status=created）才到，因为幂等Key相同（比如都是order:12345），被当成重复消息丢弃了。结果就是订单数据只有取消状态，没有创建记录，对账直接不平。
解决办法有两个层面。第一层：如果消息依赖业务先后关系，尽量让同一个业务ID的消息进入同一个队列分区/队列，保障顺序。第二层：如果顺序实在无法保证，幂等Key就不能只包含业务ID，还要包含一个版本号或时间戳。比如订单消息的幂等Key做成order:12345:v2，这样不同版本的消息可以各自处理，最终以版本号大的为准。相应的，消息体里要带上版本号，消费逻辑要按版本号做合并策略。
我第一次做幂等方案时，完全没考虑到乱序，上线后第二天就出了数据异常。从那之后，我设计任何消费逻辑都会先问自己一个问题：“如果是两条顺序颠倒的消息，数据还能不能正确收敛？”答案如果是否，就必须在幂等Key上做文章。
6. 踩坑后的几点补充经验
最后再分享几条实战中沉淀下来的经验，每条都是用线上事故换来的。
第一，幂等方案不能只靠一层。Redis的SET NX很高效，但Redis可能丢数据、可能主从切换丢key；数据库唯一索引很可靠，但高并发下冲突处理要花心思。任何生产级系统，都应该至少有两层幂等保障：一个高性能拦截层 + 一个强一致兜底层。
第二，幂等标记绝对不能只依赖消息队列自带的msg_id。我已经强调过，如果生产者重试时重新生成了msg_id，幂等就失效了。必须在消息体里带上业务幂等ID（order_id、user_id+date等由业务字段组合的ID），并且由生产端保证同一笔业务重试时幂等ID不变。
第三，测试要模拟真实的重试场景。不要只测"正常消费一次"，要专门写脚本把同一条消息连续投递十次、百次、千次，观察数据是否始终收敛到同一结果。有条件的话，把消费者进程在业务处理过程中强杀（kill -9），再重新消费，看消息是否安全重试。
第四，线上排查时，如果发现"消息没有重复消费，但数据还是不对"，先别急着怀疑幂等代码。看看是不是多个消费者实例同时消费了不同分区的同一条消息副本（Kafka Consumer Group rebalance时会重复消费），或者是消费逻辑本身依赖了外部状态（比如时间、余额快照）发生变化。幂等只能保证"同一条消息重复执行结果一致"，如果外部环境变了，结果天然会变。
做PHP这几年，我越来越觉得，幂等不是一个可以事后补的功能，而是从设计第一天就要规划的架构能力。前期多花点时间梳理业务场景、设计幂等Key、确定兜底方案，比后来半夜爬起来处理重复数据要划算得多。希望这篇文章能让你在设计自己的PHP消费方案时少走一些弯路。如果你有其他幂等场景的实战经验，也欢迎一起交流。
