IM 2000 人群聊 r6 复测分析

日期：2026-09-28

Run ID：group2k-r6-20260928-01

1. 结论

r6 比 r5 有改善，但仍未通过。A 去掉 Fake-IP 后 ACK 数从 426 增加到 758，统计窗口断线从 657 降到 213；然而 api.118im.com 的真实公网 IP 仍经 utun4，A 在正式开始前就发生 28 次连接抖动，正式开始后继续成批断线。后续排查确认该 utun4 由 OpenVPN Connect 的全局路由持有，而不是 LightXtreme。B 也出现 2 次断线和 1 次发布结果未知，不再是完全零错误。

历史落库仍然可靠：ACK 台账和未 ACK 观测台账合计核验 1870/1870，持久化丢失为 0。FD 修复已验证生效，A 的存活连接从 1000 降至 787 时，open FDs 从约 1013 同步降至约 799，不再滞留断开的 socket。

历史限速和退出行为仍会污染服务端队列指标：历史查询阶段约产生 436 次 Topic 队列满；A 结束时一次性关闭大量群订阅连接，又集中产生约 598 次队列满。

总体结论：落库正确性通过；FD 修复通过；实时可靠性失败；A 的 OpenVPN/TUN 链路仍未绕过；历史回放与集中断连仍需改进。

2. 汇总结果

指标	A	B	合计
READY	1000	1000	2000
发送尝试	1000	1000	2000
ACK	758	999	1757
ACK 超时	122	0	122
socket/连接结果未知	120	1	121
实际明确拒绝	0	0	0
断线	213	2	215
ACK 台账内应收	1757000	1757000	3514000
ACK 台账内实收	1468873	1756514	3225387
ACK 台账内实时缺失	288127	486	288613
ACK 台账外额外投递	94965	112984	207949
历史核验	1870/1870	0/0	1870/1870
未 ACK 观测消息核验	113/113	0/0	113/113

服务端实际处理消息至少为 1757 + 113 = 1870 条。其余 130 条结果未知没有 ACK 或实时观测证据，不能证明服务端接受。

3. 报告口径修正

合并报告当前显示 91 次明确拒绝和 152 次结果未知，这是错误分类：

A 的 91 次 use of closed network connection 被归类为 other。
该错误是连接关闭后的写失败，应该归类为 socket 结果未知。
修正后本轮明确拒绝为 0，结果未知为 243。

此外，群历史只由 A 执行。A 已证明全部 1757 条 ACK 消息落库，但 B 的 realtime_lost_but_persisted 无法读取 A 的历史结果，因此 B 的 486 次实时缺失没有计入“实时缺失但已落库”。合并报告需要共享全局历史核验结果后再计算该字段。

4. A 网络与 FD

本轮 DNS 返回真实地址：

64.118.158.131
216.236.31.189
216.236.31.191

但到真实地址的系统路由仍为：

gateway: 172.27.240.1
interface: utun4

这说明 Fake-IP 已关闭，但流量仍进入 VPN/TUN。A 在 barrier 提交前持续掉线重连，正式开始后约 50 秒开始掉线，最终只剩约 787 个连接。后续确认 OpenVPN Connect 下发了 0/1 和 128.0/1 两条全局路由；LightXtreme 的 DIRECT 规则无法绕过另一套 OpenVPN TUN。r7 前已为 api.118im.com 当前三个 IP 添加经 192.168.1.1/en1 的 /32 主机路由，保留 OpenVPN 内网访问的同时让压测 HTTP/WS 直连。

FD 时间序列证明 read loop 修复有效：

READY 1000 时 open FDs 约 1013。
READY 901 时 open FDs 约 913。
READY 787 时 open FDs 约 799。

连接每减少一个，FD 基本同步减少一个。

5. Topic 队列满

实时发送和 drain 阶段仍没有 Topic/Proxy 满队列。im-server-2 的 1034 次 topic's broadcast queue is full 分为：

00:35:59–00:36:11 UTC：约 436 次，发生在历史回查阶段。
00:37:19 UTC：约 598 次，发生在 A agent 完成后批量关闭连接阶段。

20 条/500ms 虽有改善，但 Topic 历史数据仍以突发方式回送。建议：

历史每页进一步降至 10 条，查询间隔保持 500ms。
每页请求后等待本页目标消息全部收到或超时，再发送下一页，而不是只按固定时间节流。
agent 退出时按 10–20ms 间隔分批关闭连接，避免 1000 个群订阅同时离线。

6. 后续修复

已将 use of closed network connection 分类为 socket 结果未知。
已在 coordinator 共享两机历史命中 ID，使 B 也能正确计算实时缺失但已落库。
历史回查已改为每页 10 条：同一 Topic 每页完成确认后再请求下一页，不同 Topic 最多 12 路并行。
agent 已改为在 10 秒窗口内渐进关闭 WebSocket。
r7 开始前重新解析 api.118im.com，确认每个 IP 都通过 /32 主机路由走 en1；OpenVPN 重连、DNS 变更或机器重启后必须重新核验。

4.7 KiB Raw Blame History Unescape Escape