xack必须放在业务逻辑最后一步，即所有外部依赖（DB、HTTP等）成功且事务提交后才执行，否则会导致消息确认但业务失败，引发重复消费或消息丢失。
为什么xack必须放在业务逻辑最后一步
很多重复消费问题，根源不是Redis配置，而是xack调用时机太早。比如在try块开头就执行xack，后续数据库写入失败或网络超时，消息已确认但业务没成功——这等于主动放弃重试能力。
真正安全的位置是：所有外部依赖（DB写入、HTTP调用、幂等校验）全部返回成功后，再调用xack。哪怕只差一行代码顺序，后果就是消息永久丢失或状态不一致。
- 不要在日志打印后、事务提交前调用
xack - 如果用Spring @Transactional，
xack必须在事务提交之后（不能在事务内） - 异步回调场景下，
xack要等回调结果落地才执行，不能仅凭“发送成功”就确认
重启消费者时如何接续未完成的消息
消费者进程崩溃或重启后，PEL里那些属于它的消息不会自动消失，也不会被XREADGROUP ... >拉到——因为>只读新消息。直接启动新实例继续用>，等于放弃PEL里的所有待处理消息，它们会被其他consumer抢走，造成重复。
正确做法是启动时先做两件事：
- 执行
XPENDING mystream mygroup - + 100，列出当前组所有pending消息 - 过滤出
consumer字段匹配自己实例名的条目（如consumer1） - 对每条匹配消息，调用
XCLAIM mystream mygroup consumer1 3600000 1710234567890-0主动认领 -
XCLAIM返回消息体后，再走完整业务流程并最终xack
注意：XCLAIM第三个参数是idle time阈值（毫秒），设太小可能抢不到刚超时的消息；设太大可能把还在处理中的消息误抢过来。
Spring Boot里autoAcknowledge(false)不是可选项，是必选项
Spring Data Redis默认开启自动ACK，也就是StreamMessageListenerContainer一收到消息就立刻xack，完全绕过你的业务控制。这在生产环境等于裸奔。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须显式关闭：
StreamMessageListenerContainerOptions.builder()
.autoAcknowledge(false) // 关键
.pollTimeout(Duration.ofSeconds(5))
.build()然后在onMessage里手动调用stringRedisTemplate.opsForStream().acknowledge(group, message)。别忘了异常分支里要记录错误，但绝不能在这里xack。
- 如果用
@StreamListener（已废弃），必须迁移到StreamMessageListenerContainer方式 - 手动
acknowledge时传入的message必须是原始ObjectRecord，不能是转换后的DTO对象 - 批量消费场景下，
acknowledge支持传入List<RecordId>，但必须确保整批都成功才统一确认
PEL积压不报警，等于没有ACK机制
Redis不会主动告诉你PEL里有1000条idle超5分钟的消息。它只忠实地存着，等你来查、来认领、来兜底。
运维层面至少要做三件事：
- 定时任务跑
XPENDING mystream mygroup - + 10，检查pending总数和最长idle时间 - 对idle超过阈值（如300000ms）的消息，用
XCLAIM移交至健康consumer，避免单点卡死拖垮整个group - 监控
xack返回值：返回0说明该ID不在当前group的PEL中——可能是已被别人ack，也可能是压根没拉取过，这种异常要告警而不是忽略
最容易被忽略的点是：PEL本身不解决“消息是否真失败”，它只提供重试基础。判断失败、触发补偿、实现幂等，全得靠你自己的代码和监控闭环。
