Redis XAUTOCLAIM 怎样清理已删除的待处理消息

Redis 7.0 起，XAUTOCLAIM 在扫描消费组的待处理列表 PEL 时，如果遇到消息体已被删除或裁剪的 ID，会清除该组中的失效引用，并把 ID 放进返回数组的第三段。它不会恢复消息体，也不能证明这条业务消息曾处理成功。

官方命令文档：https://redis.io/docs/latest/commands/xautoclaim/。上线前需确认服务端和客户端都支持包含 deleted IDs 的返回结构；命令本身从 Redis 6.2 提供，不等于所有版本都有这项清理返回。

把失效 PEL 引用与业务成功分开

先区分两个对象：Stream 保存消息字段，消费组 PEL 保存尚未确认的投递记录。XDEL 删除消息条目，并不是对业务消费成功的确认。消息体不在了，PEL 中却仍可能存在相应 ID。

因此目标不是把 pending 数字“清成零”，而是把无消息体的失效引用从当前组移走，同时为仍可读取的消息安排正常恢复。多个消费组有各自的 PEL，本次指定一个 group，并不代表其他组也被一并清理。

准备带删除条目的独立测试流

下面用全新测试键 demo:pel-clean:article 构造一条消息体已删除、另一条仍可恢复的情况。只能在独立测试实例执行；确认键不存在，不要为了重复实验直接删除同名生产键。每条命令都通过 redis-cli 执行，示例未在本机运行。

# 在独立测试实例确认该键不存在；若已存在，停止并换全新测试键。
redis-cli EXISTS demo:pel-clean:article

# 使用固定 ID 便于读者观察，不覆盖任何已有流。
redis-cli XADD demo:pel-clean:article 1-0 job alpha
redis-cli XADD demo:pel-clean:article 2-0 job beta
redis-cli XGROUP CREATE demo:pel-clean:article demo-group 0-0

# 读取两条但不确认，使它们进入 old-worker 的 PEL。
redis-cli XREADGROUP GROUP demo-group old-worker COUNT 2 STREAMS demo:pel-clean:article '>'

# 仅删除第一条消息体，保留待观察的投递引用。
redis-cli XDEL demo:pel-clean:article 1-0

准备条件是：键原先不存在、建组成功、两条消息确实被消费组读取。若任一步报错，应停止，不把错误当成已经准备完成。XDEL 的作用参考：https://redis.io/docs/latest/commands/xdel/。

读取三段返回并保存扫描游标

在这个隔离实验中，使用 min-idle-time 为 0，省去等待时间。它只为演示，不是生产建议。

# 认领并扫描少量条目；0 只用于这个没有真实消费者的测试流。
redis-cli XAUTOCLAIM demo:pel-clean:article demo-group recovery-worker 0 0-0 COUNT 10

按上述准备，预期第二段包含 2-0 的消息，第三段包含 1-0；这只是实验预期，不是执行回执。不要把两个列表拼接成一个“成功消息列表”。第三段的 ID 不再有消息体，不能交给正常业务处理函数假装恢复。

循环时使用返回起点继续扫描，起点为 0-0 表示这一轮到达末尾，而不是保证 pending 为空。即便第二段是空列表，只要返回起点还不是 0-0，就不应仅据空消息列表宣布扫描结束。应给每轮设置调用次数或时间预算，避免无节制扫描。

限制认领权限与重试范围

XAUTOCLAIM 会改变符合条件的消息归属，并不是只读清理命令。生产 min-idle-time 应结合正常处理时长设置，不能照抄 0 去抢走仍在工作的消费者任务。JUSTID 也不是“只观察”：它仍会认领，只是不返回完整字段，且不增加相同的重试计数。

恢复账号应限定到需要处理的键及必要命令，不因清理 PEL 就赋予任意删键或全量管理权限。组名、消费者名、阈值和 COUNT 都应由受控配置提供；传输与身份认证沿用现有安全连接，不把凭据写进命令日志。

客户端若只暴露认领消息而丢失第三段，就无法直接记录这次清理的 ID。此时需核对客户端返回类型与版本，而不是把“没有看到 deleted IDs”解释成“服务端一定没有清理”。

分别记录认领数和删除 ID

建议分开记录认领消息数量、失效引用清理数量、扫描起点与服务端错误；日志不输出消息载荷。对已删除 ID，可按 stream、group、ID 标识一次缺失事件，避免重试日志被误统计为多次消息丢失。

清理后的 PEL 下降与业务完成率是两种指标。仍有消息体的 2-0，应在业务幂等处理成功后再调用 XACK；第三段已移除的失效引用无需靠再次 XACK 才完成本次清理。

# 只在确认测试消息 2-0 的业务处理已经成功后执行。
redis-cli XACK demo:pel-clean:article demo-group 2-0

XACK 从指定组 PEL 移除确认记录，不是重建 Stream 消息，参见：https://redis.io/docs/latest/commands/xack/。消息体已丢失且没有外部可靠来源时，应按业务缺失处理，不能凭 ID 推测原始内容。

上线前检查协议与清理边界

• 确认 Redis 版本支持 7.0 起的失效引用清理及三段返回。
• 确认客户端保留返回起点、认领消息和 deleted IDs。
• 阈值保护正常消费者，COUNT 与扫描预算保持有限。
• 认领后的消息仍按幂等业务处理，不把归属变化当作独占业务执行保证。
• 清理范围只针对指定消费组，不能声称所有消费组已完成。

返回 0-0 后还需要再扫描吗？

需要按恢复任务周期决定。它只表示这轮到达末尾；以后其他 pending 的空闲时间可能达到阈值，适合在后续受控轮次重新从头扫描。

删掉的消息会被自动补投吗？

不会因这次清理恢复字段。第三段提供的是缺失 ID，不是可重放的内容。

清理 PEL 可以代替正常确认吗？

不能。正常消费者应在业务成功后确认；XAUTOCLAIM 的失效引用清理是处理消息体已不存在的另一条路径。

独立实验结束后，只有在确认这个键完全属于本实验且不再使用时才删除它。不要用批量删键替代生产恢复。

# 仅删除本实验创建的专用测试键；消息与消费组状态将不可恢复。
redis-cli DEL demo:pel-clean:article

最小可行方案是保留三段返回、按游标扫完一轮、分开统计认领与缺失，并继续为可恢复消息负责。这样清理掉的是失效引用，不是把业务问题从监控中抹去。