test: report ambiguous group publish outcomes

2026-09-27 22:59:17 +08:00
parent e90e92a59e
commit fc875cc84e
3 changed files with 129 additions and 3 deletions
@@ -0,0 +1,107 @@
+# IM 2000 人群聊压测问题分析
+
+日期：2026-09-27  
+Run ID：`group2k-r1-20260927-01`  
+场景：A/B 各 1000 个 WebSocket，各 500 个发送者发 2 条，计划发送 2000 条群消息。
+
+## 1. 结论
+
+本轮失败，且不能仅解读为 WebSocket 丢包。核心问题是 2000 人群每条消息触发 O(群成员数) 的额外用户 `me` Topic 路由，导致 Topic master、集群通道和 MySQL 连接池连锁积压。服务端处理吞吐下降后，发送端先经历 ACK 超时，随后 Topic 队列写满并返回 503。
+
+同时，压测程序对 ACK 超时的口径不完整：超时后服务端仍可能接受、广播并落库，不能把 `ctrl_timeout` 直接当作明确拒绝。
+
+## 2. 客户端结果
+
+| 指标 | A | B | 合计 |
+|---|---:|---:|---:|
+| WS READY | 1000 | 1000 | 2000 |
+| 发送尝试 | 1000 | 1000 | 2000 |
+| 收到 2xx ACK | 16 | 19 | 35 |
+| 503 | 224 | 272 | 496 |
+| ACK 超时 | 732 | 709 | 1441 |
+| socket 错误 | 28 | 0 | 28 |
+| 断线 | 21 | 0 | 21 |
+| ACK 台账内实时缺失 | 735 | 0 | 735 |
+| ACK 台账内历史落库缺失 | 0 | 0 | 0 |
+| 未在 ACK 台账中的实时投递 | 368270 | 377000 | 745270 |
+
+35 条 ACK 消息理论上应产生 70000 次本轮投递，实际共记录 69265 次，其中 A 端少 735 次。但这不是服务端实际接受的全量；额外 745270 次投递来自“未及时收到 ACK，但服务端已处理”的消息。
+
+## 3. 服务端证据
+
+### 3.1 实际接受和落库
+
+- `im_message_publish_stage_duration_seconds_count{kind="group",stage="save",result="ok"}` 增加 488。
+- `im_kafka_message_persist_total{kind="group",result="batch_ok"}` 增加 488。
+- 群消息 Kafka 批持久化平均约 46.6ms，488 条全部 batch success。
+
+因此，服务端至少接受并落库 488 条，而不是客户端 ACK 台账中的 35 条。其中至少 453 条属于“已接受但 ACK 未在 20 秒内返回”。
+
+### 3.2 队列溢出
+
+| Pod | 日志 | 次数 |
+|---|---|---:|
+| `im-server-2` | `s.publish: sub.broadcast channel full` | 496 |
+| `im-server-2` | `hub: topic's broadcast queue is full` | 1655 |
+| `im-server-1` | `cluster: proxy channel full` | 47 |
+
+群 Topic `grp3Ita5tyBIMs` 的 master 在 `im-server-2`。其 `clientMsg` 队列容量只有 192，proxy 响应队列容量为 128。队列满时会立即返回 503 或丢弃 proxy 响应。
+
+### 3.3 每条群消息的路由放大
+
+`Topic.saveAndBroadcastMessage` 在每条消息中同步执行：
+
+1. `presSubsOffline("msg", ..., offlineOnly=true)` 遍历 `t.perUser` 的 2000 个成员。
+2. 为每个成员构建一条用户 `me` Topic presence 消息。
+3. `routeUserServerMessage` 同时走 Tinode 原生 Cluster 路由和 Redis user fanout。
+4. 最后才向群 Topic 的会话广播 `{data}`。
+
+488 条已接受群消息产生了约 98 万次额外用户路由：
+
+- `realtime_fanout_events_total{stage="publish",target_type="user"}` 增加 979979。
+- `realtime_fanout_events_total{stage="receive",target_type="user"}` 增加 894360。
+- Redis 接收后真正本地投递只有 666 次，`no_local_session` 为 893694。
+- Cluster route 约增加 109 万次。
+
+这证明绝大多数用户 fanout 在当前全员已订阅群 Topic 的场景中完全无效，却阻塞了 Topic master 的串行处理协程。
+
+### 3.4 MySQL 连接等待
+
+3 个 Pod 的 `meeting_im` 连接池在测试窗口中合计：
+
+- 等待次数增加 4011。
+- 等待时间增加约 35399 秒。
+- DB `exec ok` 增加 3453，平均耗时约 501ms。
+
+连接池每 Pod 最大 24 个连接。这不是本轮第一个堵点，但会进一步拖慢群权限检查、未读数更新和其他业务 SQL。仅提高连接数不会消除 O(成员数) 的放大。
+
+## 4. 压测程序口径问题
+
+1. `ctrl_timeout` 和 socket 错误属于发布结果未知，不是明确拒绝。
+2. recorder 能够统计 `unexpected_messages`，但 merge 报告没有汇总该字段，也没有将它加入门禁。
+3. 历史回查只检查 ACK 台账，因此只检查了 35 条，无法单独证明其他超时消息的落库情况。
+4. 群聊应增加“已 ACK”、“已明确拒绝”、“结果未知”、“未 ACK 但已观测广播”和“最终落库”五种状态。
+
+## 5. 改进顺序
+
+### P0
+
+1. 停止在原生 Cluster 已开启时对同一条 user message 再做 Redis user fanout，避免双通道重复路由。
+2. 重构群消息的 unread presence：已订阅该群 Topic 的用户不再生成额外 `me` 通知；未订阅但在线的成员使用节点级批量 fanout，不得在 Topic master 协程中逐人跨 Pod 路由。
+3. 为 Topic `clientMsg`、proxy 响应队列和 session send queue 增加 length/capacity/drop Prometheus 指标。
+4. 压测 merge 报告增加结果未知及 unacked-observed 口径，并把 `unexpected_messages` 纳入失败门禁。
+
+### P1
+
+1. 检查群消息未读数更新和 Push receipt 是否对 2000 人逐人访问 Redis/MySQL，改为批处理或延迟合并。
+2. 为 `CanPost` 的全员禁言和单人禁言结果增加短 TTL 缓存，管理操作时精确失效。
+3. P0 完成后先跑 100、500、1000、2000 人群阶梯，每档检查 ACK P95、Topic 队列水位、Cluster route 数、DB pool wait 和 Kafka lag，不直接重跑全量。
+
+## 6. 本轮验收结论
+
+- 连接建立：通过，2000/2000 READY。
+- 发布成功率：失败。
+- ACK 延迟：失败，已超过 20 秒超时窗口。
+- 实时广播：失败，存在队列丢弃和断线。
+- Kafka 持久化：已处理的 488 条全部成功，但该结论不代表计划的 2000 条均被接受。
+- 总体：失败，必须完成 P0 后按阶梯重测。