Redis XCLAIM JUSTID 怎样只转移消息 ID 而不返回正文
在 Redis Streams 消费组里接管超时未处理的 pending message 时，如果后续逻辑只需要把消息 ID 放进重试队列，就不必让 XCLAIM 返回整条消息正文。做法是在待接管的消息 ID 后追加 JUSTID。这样返回值只包含实际成功转移的 ID，而且这次接管不会增加消息的重试计数。
官方地址：https://redis.io/docs/latest/commands/xclaim/
记住两个判断：JUSTID 改变的是返回形状，同时改变了 retry counter 的行为；它不会让不存在、已确认或不满足最小空闲时间的消息变成可接管消息。
先看 XCLAIM 到底转移了什么
XCLAIM 面向的是消费组的 Pending Entries List（PEL）。调用方给出 Stream、消费组、新消费者、最小空闲时间和一个或多个消息 ID，Redis 只会接管已经在该消费组中挂起、且空闲时间达到要求的消息。
不加 JUSTID 时，成功项通常会带着消息 ID 以及字段和值返回；加上它以后，响应只保留成功接管的消息 ID。这里的“只转移 ID”不是只修改返回值，所有权仍然会转给新消费者，消息仍然需要后续处理和 XACK。
在命令末尾加入 JUSTID
命令参数的核心顺序是：键、消费组、新消费者、最小空闲毫秒数、消息 ID，最后才是可选项。下面的示例只展示调用关系，消息 ID 需要替换成业务中从 PEL 读取到的真实 ID。
# 中文注释：只接管空闲超过 1 小时的消息，并让响应只返回成功的消息 ID redis-cli XCLAIM orders pending-worker worker-b 3600000 1526569498055-0 1526569498056-0 JUSTID
如果两个 ID 都符合条件，响应可以抽象成下面的数组：
1) "1526569498055-0" 2) "1526569498056-0"
和普通模式相比，调用方不需要再拆解每条消息的字段和值，网络响应也不会携带正文。适合“先批量认领、再由另一段逻辑按 ID 拉取或处理”的任务。若接管后马上就要消费字段内容，普通 XCLAIM 的响应反而更直接。
三个容易误判的返回边界
| 现象 | 实际含义 | 处理建议 |
|---|---|---|
| 返回数量少于请求 ID | 部分 ID 不在该消费组 PEL、空闲时间不足，或消息已经从 Stream 中删除 | 按返回数组作为成功集合，不要按请求数量补齐 |
| JUSTID 后 retry counter 没增加 | 这是 JUSTID 的定义，不代表接管失败 | 需要重试统计时另行记录接管次数 |
| 拿到 ID 但正文读取不到 | 消息可能已被 XDEL 或裁剪，PEL 与 Stream 的生命周期不完全相同 | 把正文缺失当作可处理的清理分支 |
尤其不要把“响应为空”解释成 Redis 没有执行命令。XCLAIM 的成功集合本来就可能小于输入集合；对于已经从 Stream 删除、但仍残留在 PEL 的消息，Redis 还可能同时清理对应的 PEL 记录。
什么时候适合用 JUSTID
如果接管器只负责认领并把 ID 交给后续 worker，JUSTID 能让响应更紧凑，也避免一次接管搬运大量字段和值。worker 仍应以 ID 为依据完成业务处理，成功后确认消息；不要因为响应里没有正文就省略确认。
如果你依赖 Redis 的 retry counter 判断某条消息被反复投递，JUSTID 不适合作为唯一依据，因为官方语义明确规定它不会递增该计数。可以在应用侧记录接管次数，或在确实需要消息内容时使用不带 JUSTID 的 XCLAIM。
最后，JUSTID 只解决“返回什么”，不解决“如何自动扫描所有超时消息”。本文不展开 XAUTOCLAIM；需要从游标扫描 PEL 时，应单独设计扫描、幂等处理、确认和过期消息清理策略。
常见问题
JUSTID 会不会只读消息而不改变消费者归属？
不会。它仍然执行 XCLAIM 的所有权转移，只是把成功响应压缩为消息 ID，并改变 retry counter 的递增行为。
请求了三个 ID，为什么只收到一个？
返回数组只代表成功接管的消息。其余 ID 可能不在 PEL、空闲时间不足，或消息已经从 Stream 中删除，不能按请求数组下标强行对应。
JUSTID 能替代 XAUTOCLAIM 吗？
不能。JUSTID 是 XCLAIM 的响应选项；XAUTOCLAIM 负责自动扫描并接管符合条件的消息，两者解决的层次不同。
小结
把 JUSTID 放在 XCLAIM 命令末尾，就能只得到成功接管的消息 ID。工程上要同时记住三点：响应数量可能变少、消息正文可能已经不存在、retry counter 不会因 JUSTID 接管而增加。只要后续 worker 能按 ID 继续处理并正确确认消息，这种模式就适合做轻量的故障接管入口。
