Appearance
长连接假活与漏事件对账：把"无解"的断连间隙变成可补偿的
第二部 · Agent 实践 · 第30章
撰写日期：2026-07-12
结论
我在团队 Bot 的必回复工程里曾把"长连接重连间隙丢消息"归为无解，低频容忍。一次真实的漏回复排查推翻了这个结论：断连不是唯一的丢事件路径，更隐蔽的是假活——连接对象报告"在线"，实际已经卡死，直到心跳超时才暴露断连，这段"看着活、其实死"的窗口比真正的重连间隙长得多，也更容易被忽略。
只要长连接是事件的唯一入口，就永远存在"连接状态看起来正常、事件其实没送达"的窗口。解法不是让连接更可靠（做不到），而是给事件入口配一个独立于连接状态的对账机制：定期回查权威数据源，把没进入处理记录的事件当缺口补上。
1. 排查心法：连接"在线" ≠ 事件在送达
排查漏回复时，先查的是触发规则和权限，都正常；再查进程存活，也正常。真正的根因要多问一层：这条连接最近一次真正收到事件是什么时候，而不是"连接对象说自己是不是在线"。这次的证据链是：
| 证据 | 结论 |
|---|---|
| 权威数据源（消息历史 API）能查到这条事件，且触发条件成立 | 事件确实发生了，理应被处理 |
| 处理进程的事件日志里没有这条记录 | 事件没有进入处理流程 |
| 连接对象在事件发生后一段时间才报告断开 | 连接早就卡住了，只是心跳超时才暴露 |
只看进程存活或连接的"已连接"标志位，会把这类假活误判为"一切正常"。真正该监控的指标是最后一次收到事件的时间戳，而不是连接对象自身汇报的状态。
2. 假活的诱因之一：同应用重复监听抢占
这次假活的直接诱因是同一个 IM 应用被两处代码分别起了监听进程，后起的抢占了长连接，前一个的连接沦为僵尸态但没有立刻报错。和长期在线 Agent 自动化的工程手记里"两台机器用同一凭证建长连接、事件被对方消费"是同一类问题的不同变体：一个应用凭证只经得起一条稳定长连接，谁后启动谁占用，之前那条不会显式失败，只会安静地不再收到新事件。收敛为单一监听入口、启动时抢占锁失败就直接退出并报告占用来源，是治这一类问题的通用做法。
3. 解法：不追求连接更可靠，而是加一层对账
连接层面的假活很难根除（网络环境、平台侧行为都不受控），比起死磕连接可靠性，更划算的是给事件处理加一层独立于长连接的对账：
| 组件 | 做法 |
|---|---|
| 已处理记录 | 每条正常处理的事件写入持久化的"已处理"标记，作为事后核对的基准 |
| 定期回查 | 用短周期轮询，按原始触发条件从权威数据源（如消息历史接口）取最近一小段时间的数据 |
| 缺口补偿 | 命中触发条件但不在"已处理"记录里的，构造成事件交给原有处理流程，产出挂在原消息下，用户感知不到差异 |
| 只读隔离 | 补偿轮询本身只读、不新增长连接，异常时不能拖垮主监听进程——补偿链路挂了不该连累主链路 |
这套对账不需要判断"连接为什么假活"，它只关心一个更简单的问题：权威数据源里存在、但处理记录里不存在的事件，都算漏项，都要补。这个思路比"提高连接可靠性"更通用，也适用于任何"长连接/Webhook 是唯一事件入口"的场景，不限于 IM 机器人。
4. 对既有判断的修正
团队 Bot 的必回复工程里"长连接重连间隙丢消息，无解、低频容忍"这条结论需要更新为：断连间隙本身确实无法消除，但只要有权威数据源可回查，丢失的事件是可以补偿的——"无解"说的是连接层面，不是事件处理的最终结果。这也是这次排查里价值最高的一条：不是修好了一个 bug，而是推翻了此前"这类丢失只能忍"的判断。
5. 同一副面孔的另一种假活：静默降级为 0 掩盖采集故障
漏事件是"该处理的没处理"，还有一种更难发现的孪生故障：该采到的没采到，却降级成了一个合法的默认值。 某一路数据采集整段失败时，如果管道静默回退成 0 或空，看板会显示成"今天真的没有数据"——故障被伪装成了业务现象。
0是语义上合法的业务值，和"采集器异常退出"从结果上不可区分。观察者无法从一个合理的默认值反推链路是否健康，故障因此长期潜伏。
它和前面的假活是同一个道理：系统看起来在正常出数，其实某条链路早已断了。 治法也同源——不追求那条链路永不失败，而是让失败显式可见：告警、错误态，或至少在数据上区分"真的是 0"和"没采到"。凡是"外部枚举 / 事件采集"这类可能整段失败的链路，都不该用一个看起来合理的默认值把断链盖住。