test: stabilize distributed load verification

2026-09-28 09:50:33 +08:00
parent d3c679878d
commit a974572f72
12 changed files with 344 additions and 46 deletions
@@ -0,0 +1,93 @@
+# 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 返回真实地址：
+
+```text
+64.118.158.131
+216.236.31.189
+216.236.31.191
+```
+
+但到真实地址的系统路由仍为：
+
+```text
+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 历史数据仍以突发方式回送。建议：
+
+1. 历史每页进一步降至 10 条，查询间隔保持 500ms。
+2. 每页请求后等待本页目标消息全部收到或超时，再发送下一页，而不是只按固定时间节流。
+3. agent 退出时按 10–20ms 间隔分批关闭连接，避免 1000 个群订阅同时离线。
+
+## 6. 后续修复
+
+1. 已将 `use of closed network connection` 分类为 socket 结果未知。
+2. 已在 coordinator 共享两机历史命中 ID，使 B 也能正确计算实时缺失但已落库。
+3. 历史回查已改为每页 10 条：同一 Topic 每页完成确认后再请求下一页，不同 Topic 最多 12 路并行。
+4. agent 已改为在 10 秒窗口内渐进关闭 WebSocket。
+5. r7 开始前重新解析 `api.118im.com`，确认每个 IP 都通过 `/32` 主机路由走 `en1`；OpenVPN 重连、DNS 变更或机器重启后必须重新核验。