XACK 解决“交付完成”
业务写入成功后才执行 XACK。过早确认会丢任务，永不确认会让 PEL 持续膨胀。
Redis Stream / fulfillment 消费者组
PEL 故障恢复实验室
模拟时钟
14:30:00
消息进了 PEL 只表示“已经交给某个消费者”，不表示业务成功。消费者宕机后必须认领并重试；一旦确认结果丢失，同一订单就可能再次抵达，所以幂等是业务职责。
当前命令：等待操作
orders:events
group = fulfillment点击一行选择消息。Stream 记录不会因 XACK 消失；XACK 只会把它从消费者组的 PEL 中移除。
| 选择 | Stream ID | orderId | owner | 投递次数 | idle | 业务状态 |
|---|
Stream 里还没有事件先投递一笔订单，观察它如何从未消费状态进入 PEL。
PEL 追踪的是交付，不是业务事务
owner + delivery count + idle 能帮助判断谁拿过消息、多久没有确认，却不知道数据库事务是否真的提交。
死信是隔离区，不是垃圾桶
达到重试阈值后，将原消息和失败原因写入 DLQ，再 XACK 原消息；后续仍要告警、诊断和补偿。
XAUTOCLAIM 解决“谁来接手”
用合理的 min-idle-time 认领疑似失联消费者的消息。阈值太短，慢任务会被并发重复处理。
幂等解决“再来一遍”
以 orderId + eventType 建唯一约束，将业务写入和幂等记录放进同一个数据库事务，再安全确认消息。