XAUTOCLAIM 怎样自动转移超时消息

Redis Streams 的消费者异常退出后，已经投递但还没有确认的消息会留在消费组的 PEL 中。XAUTOCLAIM 可以把空闲时间超过阈值的 pending 消息转交给健康消费者，但它只完成“改变归属”，不会替你完成业务处理，更不会自动执行 XACK。因此可靠用法是：从 0-0 开始按游标扫描，接管后做幂等处理，业务成功后再确认。

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

先确认要接管的对象

一个完整的接管调用至少要把五件事对齐：Stream key、消费组、接管后的消费者、最小空闲时间，以及开始扫描的消息 ID。这里的“超时”不是 Stream 消息的创建时间，而是该消息在消费组 PEL 中没有被确认或再次接管的空闲时间，单位是毫秒。

例如订单消费组使用 billing-workers，恢复消费者叫 worker-recovery，只接管空闲至少 60 秒的记录：

# 从 PEL 开头扫描，60 秒内没有确认或接管的消息才符合条件。
redis-cli XAUTOCLAIM orders billing-workers worker-recovery 60000 0-0 COUNT 20

命令不按原消费者名称过滤，而是由 Stream 和消费组共同确定待处理范围。原消费者仍然存活时，也不要只因为消费者名字看起来“旧”就接管；应该用业务处理最长正常时长来设置阈值，否则慢任务可能被第二个消费者重复处理。

用返回游标持续扫描超时消息

XAUTOCLAIM 的语法是 XAUTOCLAIM key group consumer min-idle-time start [COUNT count] [JUSTID]。返回结果通常有三部分：下一次调用使用的游标、成功接管的消息，以及流中已经不存在而从 PEL 清理掉的消息 ID。

# 第一次从 PEL 开头开始；COUNT 是本次尝试扫描的上限，不是保证接管数量。
redis-cli XAUTOCLAIM orders billing-workers worker-recovery 60000 0-0 COUNT 20

# 下一轮把上一次返回的游标作为 start，继续扫描同一个消费组。
redis-cli XAUTOCLAIM orders billing-workers worker-recovery 60000 1690000000000-0 COUNT 20

COUNT 默认是 100，用来限制每次尝试接管的数量；由于 Redis 还要过滤未达到空闲阈值的记录，实际接管数可能小于它。返回 0-0 表示本轮已经扫描到 PEL 末尾，不代表从此以后永远没有新消息。定时恢复任务下一轮可以重新从 0-0 开始，也可以在同一轮按业务策略重新扫描。

如果只需要 ID，不需要立即取出字段，可以加 JUSTID。它让返回内容只包含成功接管的 ID，同时不会增加这些消息的重试计数；如果恢复逻辑需要完整字段，就不要用这个选项。

把接管和业务确认分开

接管成功只说明消息的新所有者变成了恢复消费者。应用仍需执行实际业务，并让这段业务具备幂等性：同一个 Stream ID 可能因为崩溃、网络超时或重复恢复而被再次处理。业务持久化成功后，再用 XACK 从这个消费组的 PEL 中移除对应 ID。

# 接管后先完成订单处理；以下确认命令应放在业务成功之后。
redis-cli XACK orders billing-workers 1690000000000-0

# 只查看该组的待处理摘要，不把 pending 数量当成业务成功数。
redis-cli XPENDING orders billing-workers

不要把“返回了消息”“业务函数返回成功”和“XACK 返回 1”混成一个状态。恢复消费者应记录 Stream key、消费组、消息 ID、接管次数和业务结果；对持续失败的 ID 设置重试上限或转入人工处理路径。接管后立刻批量确认会丢失失败恢复线索。

处理 0-0、删除记录和重复投递

Redis 7.0 起，扫描 PEL 时如果发现消息正文已被删除或被截断，XAUTOCLAIM 不会接管它，而会把这类 ID 从对应 PEL 清掉，并在第三段返回中列出。这个返回区应被记录，否则运维看到 pending 下降时，可能误以为业务消费者已经处理成功。

min-idle-time 应该设置多长？

至少覆盖正常处理时长、短暂 GC 和网络抖动，并给故障恢复留出空间。它不是越短越好；过短会让仍在工作的消费者被频繁接管。

XAUTOCLAIM 会删除 Stream 消息吗？

正常接管不会删除 Stream 正文。只有扫描到正文已经不存在的 ID 时，Redis 才会把该 ID 从 PEL 清理，并通过返回结果告知调用方。

接管后可以直接 XACK 吗？

除非业务已经通过其他可靠路径完成，否则不应该。正确顺序是接管、幂等处理、业务成功持久化，再确认。

参考资料：https://redis.io/docs/latest/commands/xautoclaim/；https://redis.io/docs/latest/develop/data-types/stream/。