# IM 2000 人群聊 r5 复测分析

日期：2026-09-28

Run ID：`group2k-r5-20260928-01`

## 1. 结论

本轮再次证明服务端对稳定客户端的群消息可靠性没有丢失，失败集中在机器 A 的本地代理/TUN 链路：

- B：1000 次发送全部 ACK，1426000 次 ACK 台账内投递全部到达，断线、重复、乱序和实时缺失均为 0。
- A：574 次发布结果未知、657 次统计窗口内断线、464596 次 ACK 台账内实时缺失。
- A 的 broken pipe 全部写向 `198.18.0.81:443`；本机 DNS 也将 `api.118im.com` 解析为 `198.18.0.81`，路由经 `utun19827 -> 172.19.0.1`。`198.18.0.0/15` 是代理/TUN 常用 Fake-IP 网段，不是 API 的真实公网地址。
- 机器 A 压测进程 CPU 平均占用不高、内存峰值约 150MB，B 在同一服务端负载下完全稳定，不支持“服务端全局过载”解释。
- 新增观测台账生效：574 条结果未知中，241 条被实时观测并加入历史核验，241 条全部找到。
- 历史总核验 1667/1667，持久化丢失为 0。
- 历史回查仍产生 1197 次 `topic broadcast queue full`，但全部发生在历史阶段，不在实时发送阶段。

总体结论：**群消息落库通过，B 侧实时可靠性通过；A 侧 TUN/Fake-IP 链路失败；历史查询限速仍需继续降低。**

## 2. 汇总结果

| 指标 | A | B | 合计 |
|---|---:|---:|---:|
| READY | 1000 | 1000 | 2000 |
| 发送尝试 | 1000 | 1000 | 2000 |
| ACK | 426 | 1000 | 1426 |
| 明确拒绝 | 0 | 0 | 0 |
| ACK 超时 | 444 | 0 | 444 |
| socket 结果未知 | 130 | 0 | 130 |
| 断线 | 657 | 0 | 657 |
| ACK 台账内应收 | 1426000 | 1426000 | 2852000 |
| ACK 台账内实收 | 961404 | 1426000 | 2387404 |
| ACK 台账内实时缺失 | 464596 | 0 | 464596 |
| ACK 台账外额外投递 | 185738 | 241000 | 426738 |
| 历史核验 | 1667/1667 | 0/0 | 1667/1667 |
| 未 ACK 观测消息核验 | 241/241 | 0/0 | 241/241 |

服务端实际处理消息至少为 `1426 + 241 = 1667` 条。其余 333 条结果未知既没有 ACK，也没有任何实时观测证据，不能证明服务端接受。

## 3. A 机器故障证据

### 3.1 网络路径

测试结束后的本机检查结果：

```text
api.118im.com -> 198.18.0.81
route: 198.18.0.81 -> gateway 172.19.0.1, interface utun19827
broken pipe remote: 198.18.0.81:443
```

A 的错误构成为：

- `ctrl_timeout=444`
- `websocket_closed=103`
- `broken_pipe=27`
- 其他 1

连接从 `17:05:12 UTC` 开始下降，随后从 1000 持续降至约 333；B 同期保持 1000 连接。下一轮前必须关闭该代理/TUN，或至少将 `api.118im.com` 设置为 DIRECT，并确认 DNS 不再返回 `198.18.0.0/15` Fake-IP。

### 3.2 本机资源

- 进程 RSS 峰值约 150MB。
- 压测期间累计 CPU 增量约 75 秒，对约 625 秒窗口而言不构成 CPU 饱和。
- open FDs 在连接大量断开后仍约为 1011。`WSClient.readLoop` 在读失败返回时没有立即关闭底层连接，虽然进程结束时会统一关闭，但应修复运行期 FD 滞留。

## 4. 服务端和历史核验

实时发送和 drain 阶段没有新增以下错误：

- `sub.broadcast channel full`
- `cluster: proxy channel full`
- `topic's broadcast queue is full`
- Redis fanout publish failure

历史核验约在 `17:13:15 UTC` 开始。`im-server-2` 从 `17:13:22` 到 `17:14:14` 记录 1197 次群 Topic broadcast queue full。当前 1 worker、每页 50 条、100ms 间隔仍会让单次历史回放快速灌入容量为 64 的 Topic 队列。

尽管重试后 1667 条全部找到，历史核验不应持续制造队列丢弃。建议调整为：

- `history_page_size=20`
- `history_query_interval=500ms`
- `history_workers=1`
- 历史超时保持 3 分钟；1667 条约需 42 秒完成首轮查询。

## 5. 下一步

1. 修复 `WSClient.readLoop` 退出时未关闭底层连接的问题。
2. 将历史分页调整为 20 条、查询间隔 500ms。
3. 在 A 机关闭 TUN/代理，或配置 `api.118im.com` DIRECT；起压前检查 DNS 和路由不再进入 `198.18.0.0/15`、`utun*`。
4. 测试环境尚未应用 metrics RBAC，`kubectl auth can-i list pods.metrics.k8s.io` 仍返回 `no`，因此本轮没有 Pod CPU/内存数据。需要将 `backend-debug-metrics-rbac.yaml` 加入实际 ArgoCD overlay。
5. 完成上述三项后再运行同规模 r6。若 A/B 都稳定，再根据 B 本轮 ACK P95 约 1.14s、同机投递 P95 位于 2s 桶的结果继续做服务端延迟优化。