Redis Streams 怎样用 XACK 设计幂等确认

Redis Streams 的 XACK 解决的是“这条消息还要不要留在消费组的待确认列表里”，不是“业务副作用会不会执行两次”。要让消费链路真正可重试，通常要把业务事件 ID 作为幂等键，把去重记录和业务写入放在一个可提交的边界内，只有处理成功后才确认消息。

官方地址：https://redis.io/docs/latest/

稳妥的顺序是：读取消息 → 用事件 ID 判断或提交幂等业务结果 → 业务结果成功后执行 XACK。处理失败或进程在中间退出时不要确认，让消息留在 PEL 中，后续再通过检查和接管恢复。

• XREADGROUP 读取新消息后，Redis 会把消息放进消费组的 PEL。
• XACK 只从指定消费组的 PEL 移除已处理的消息。
• 重复投递仍然可能发生，所以业务层必须用稳定的事件 ID 做幂等判断。
• XPENDING 观察积压，XAUTOCLAIM 接管长时间没有确认的消息。

先厘清 XREADGROUP 和 XACK 的生命周期

消费组不是“读到就删除”的模型。消费者用 XREADGROUP 取到消息后，Redis 会记住消息由哪个 consumer 领取，并将它放进该消费组的 Pending Entries List，也就是 PEL。只要消费者还没有执行 XACK，这条消息就仍然属于未确认状态。

# > 表示领取尚未投递给任何消费者的新消息
XREADGROUP GROUP order-workers worker-a COUNT 10 BLOCK 5000 STREAMS orders >

# 只有业务处理已经成功，才确认指定的 Stream 消息
XACK orders order-workers 1720000000000-0

这里最容易犯的错误是把“收到消息”当成“处理完成”。如果消费者在业务写库前崩溃，消息会继续留在 PEL；如果先 XACK 再写库，进程恰好在两条操作之间退出，消息已经不再等待恢复，业务结果却没有落下。

幂等键要来自业务事件，而不是每次消费生成

Redis Stream 的消息 ID 可以帮助定位消息，但业务幂等键最好直接来自生产者生成的事件 ID，例如 order.created:9001:v1。同一件业务事件重试时必须携带同一个值；如果每次重试都生成新的 UUID，去重表只能看到“不同事件”，自然无法阻止重复扣款或重复发货。

# 生产消息时把稳定的业务事件 ID 写入字段
XADD orders * event_id order.created:9001:v1 order_id 9001 amount 299

# 查询某个事件的处理记录；返回已完成时，消费者可以安全跳过副作用
HGET processed:event:order.created:9001:v1 status

幂等记录至少要能回答两个问题：这个事件是否已经成功完成，以及成功结果是什么。对于订单、库存、账务等需要写数据库的场景，常见做法是在业务表上给 event_id 建唯一约束，把“插入处理记录”和“业务更新”放进同一个数据库事务；事务提交成功后再调用 XACK。

把已处理判断、业务副作用和确认拆成三个责任

一条可重试的消费链路可以按下面的责任边界组织：

1. 先从消息中取出稳定的 event_id，检查业务系统是否已经成功处理。
2. 未处理时执行业务副作用，并在同一个可靠提交边界内写入去重记录。
3. 确认业务提交成功，再用 XACK 移除 PEL 记录。
4. 如果发现已处理，说明这次是重投；不重复执行业务副作用，但仍然要 XACK 这次拿到的消息 ID。

“已处理”分支也要确认消息。否则消费者每次恢复都会重复收到同一条记录，PEL 会一直保留它。反过来，业务失败时不能因为拿到了消息就确认；让它留在 PEL，才能交给重试或恢复流程。

去重存储怎么选才不会留下半成功状态

如果业务副作用发生在数据库中，优先把事件 ID 的唯一约束和业务更新放在同一个事务中。这样消费者即使因为确认请求失败而重投，第二次也会被唯一约束识别为已处理，然后只补做 XACK。

# 伪 SQL：业务表的唯一键是幂等边界，具体表名按业务替换
BEGIN;

# 首次事件插入成功；重复 event_id 会触发唯一键冲突或已存在分支
INSERT INTO order_event_log(event_id, order_id, status)
VALUES ('order.created:9001:v1', 9001, 'processing');

# 只有同一事务内的业务写入成功，才把事件标记为完成
UPDATE orders SET paid = 1 WHERE id = 9001;
UPDATE order_event_log SET status = 'done' WHERE event_id = 'order.created:9001:v1';
COMMIT;

# 数据库提交成功后，再确认 Redis 消息
XACK orders order-workers 1720000000000-0

如果副作用本身只发生在 Redis 内部，可以把“检查去重键、写入结果、更新状态”设计成一个 Lua 脚本的原子操作。但 Redis 里的原子脚本无法自动和外部 HTTP、数据库或支付系统组成跨系统事务；外部场景仍要依靠业务唯一键、事务、状态机或补偿记录。

不要使用“先 SETNX 去重，再调用外部服务”的简单写法后就认为安全：消费者可能在 SETNX 成功、外部服务调用之前崩溃，重试时看见去重键便跳过，反而造成业务结果丢失。去重记录的“完成”状态必须在真实副作用成功后提交。

用 XPENDING 和 XAUTOCLAIM 接上异常恢复

消费者宕机、网络中断或处理时间超过预期时，消息会留在 PEL。XPENDING 可以查看某个消费组的待确认总数、最小和最大消息 ID，以及各 consumer 的积压数量；这一步适合做监控和恢复前的判断。

被 XAUTOCLAIM 接管不等于可以直接执行副作用。恢复消费者仍然要回到同一套事件 ID 去重逻辑：已经成功的事件只补确认，未成功的事件才继续处理。空闲阈值应大于正常处理的合理上限，否则两个健康消费者可能同时争抢同一条慢消息。

失败重试和确认顺序要提前定规则

幂等确认通常至少要区分三类失败。参数错误、数据不符合业务规则的问题，不适合无限重试，可以写入失败记录后确认并告警；数据库暂时不可用、依赖超时等可恢复错误，先不确认，让消息保留在 PEL；业务已提交但 XACK 请求失败，则按“可能已经确认”的不确定状态处理，重新领取后依赖事件 ID 判断，不能再次执行副作用。

还要把消息保留和去重记录的生命周期放在一起考虑。Stream 被裁剪并不代表业务去重记录可以立即删除；只要历史消息仍可能从 PEL 恢复，去重信息就要保留到足以覆盖最长重试和接管窗口。否则旧消息再次投递时，业务系统已经忘记它处理过，幂等边界会失效。

• 确认前：业务结果必须已经成功提交，或已经明确进入不可重试的失败状态。
• 确认后：监控仍要能发现业务提交与确认之间的异常，必要时允许按事件 ID补偿。
• 恢复时：先查幂等记录，再决定重做副作用还是只补 XACK。
• 观测时：同时看 PEL 数量、最老消息空闲时间、重复事件数和业务失败数。

上线前用这张清单检查

可以按下面的顺序复查设计，而不用把 XACK 当成一个神奇的去重开关：

1. 生产者是否为同一业务事件携带稳定且可追踪的 event_id？
2. 业务副作用和“事件已完成”是否共享一个可靠提交边界？
3. 消费者是否只在业务提交后调用 XACK？
4. 重复投递时是否会跳过副作用，但仍确认当前消息 ID？
5. 是否用 XPENDING 监控积压，并用 XAUTOCLAIM 设置合理的空闲阈值？
6. 去重记录的保留期是否覆盖 Stream 消息可能被恢复的时间窗口？

总结

Redis Streams 的消费组提供的是至少一次投递语义：消息被 XREADGROUP 领取后进入 PEL，处理成功后用 XACK 移除。它不会替业务保证幂等，也不会把外部数据库或接口调用变成原子事务。

真正可靠的设计是以稳定事件 ID 为索引，把业务副作用与完成记录放进可提交的幂等边界，成功后再确认；异常时依靠 PEL、XPENDING 和 XAUTOCLAIM 恢复。这样即使确认请求丢失，重投也只会补确认，不会重复扣款、发货或写入业务结果。

相关问题

XACK 返回 0 是不是代表 Redis 出错？

不一定。Redis 官方说明中，已经不在 PEL 中的消息不会计入成功确认数；消息可能已被其他处理流程确认，或者 ID 本身不属于当前消费组。应用应结合 PEL 和业务幂等记录判断，而不是仅凭返回数做业务结论。

能不能一读取消息就 XACK，后面异步处理？

只有在你已经把消息可靠地转移到另一个持久化任务队列，并且那个队列拥有自己的幂等和恢复机制时才适合。直接先 XACK 再异步处理会让 Redis 失去这条消息的恢复责任，进程退出可能造成业务丢失。

使用 XAUTOCLAIM 后还需要做幂等判断吗？

需要。XAUTOCLAIM 只是改变待确认消息的归属，让健康消费者能够继续处理；它不会判断业务副作用是否已经完成。恢复消费者仍要使用同一个 event_id 查询去重记录。