fix: move group push work off topic loop
This commit is contained in:
richjohnrambo
@@ -146,3 +146,61 @@ Run ID：`s60-group-r2-0929`。
|
||||
- 群聊 R2：`loadtest/im-pressure/results/s60-group-r2-0929/`
|
||||
|
||||
结果目录包含 coordinator、A/B summary、合并 report 和 agent 指标 JSONL。
|
||||
|
||||
## 12. 精确成员规模诊断复测
|
||||
|
||||
为区分“在线连接数”和“群成员总数”的影响，新增 300、600 人独立群复测。每个测试群在起压前均按用户 ID 集合核验，要求实际成员与目标账号完全相等。
|
||||
|
||||
| 场景 | Run ID | 在线/群成员 | ACK | 实时投递 | 历史 | DB 精确命中 | ACK P95 | 投递 P95 |
|
||||
|---|---|---:|---:|---:|---:|---:|---:|---:|
|
||||
| 原 1200 人群、仅 300 人在线 | `s300-group-r1b-0929` | 300/1200 | 45/300 | 13500/13500（按 ACK 台账） | 206/206 | 45 ACK + 210 结果未知全部落库 | 18994ms | 89489ms |
|
||||
| 精确 300 人群 | `s300m-group-r1-0930` | 300/300 | 300/300 | 90000/90000 | 300/300 | 300/300 | 235.177ms | 500ms 桶内 |
|
||||
| 精确 600 人群 | `s600m-group-r1-0930` | 600/600 | 600/600 | 360000/360000 | 600/600 | 600/600 | 235.177ms | 500ms 桶内 |
|
||||
| 精确 900 人群 | `s900m-group-r1-0930` | 900/900 | 890/900 | 800555/801000（按 ACK 台账） | 899/899 | 890 ACK + 9 结果未知落库 | >10s，最大19.272s | >10s，最大55.279s |
|
||||
|
||||
三轮均未出现 WS 发送队列满、WS 写失败或 Kafka lag。精确 300、600 人群在实时阶段也没有新增 `session_topic_publish`、`topic_client`、`topic_server` 满队列，说明 WS 写链路在 600 在线规模内不是瓶颈。
|
||||
|
||||
原 1200 人群仅 300 人在线时有约 900 个离线成员。群消息处理会在 Topic 串行路径中为每个离线成员逐个调用 Redis presence 查询；上一条消息 ACK 后的推送准备持续占用 Topic goroutine，使后续消息长时间等待，最终表现为 ACK 超时和分钟级投递延迟。精确成员群消除这部分离线成员后，同等 300 在线规模恢复正常，验证了该路径是主要根因。
|
||||
|
||||
600 人实时发送通过后，240 秒错峰下线仍使群主 Pod 的 `topic_server full` 从 36 增至 128，净增 92；其他两类内部队列无增量。该问题来自最后会话离线时的 presence 扩散，与消息保存、Kafka 消费和 WS 实时投递无关，仍需在服务端合并或限流离线状态广播。
|
||||
|
||||
精确 900 人群出现容量拐点：900 次发送中 890 次 ACK，9 次 ACK 超时、1 次 socket 失败；7 条连接在实时阶段超时断开并自动恢复。按 ACK 台账计算的 445 次实时缺口全部可从历史补回，890 条 ACK 全部精确落库；9 条结果未知实际落库，1 条 socket 失败未落库。因此本轮没有持久化丢失，但实时正确性和延迟门禁未通过。
|
||||
|
||||
900 人实时阶段三个内部队列的 full 计数均无增量，Kafka lag 为 0。成功处理的 899 条消息中，`permission_check` P95 不超过 10ms、`save` P95 不超过 50ms、`kafka_produce` P95 不超过 25ms、`realtime_fanout` P95 不超过 5ms；抽样覆盖后半段 575468 次 WS 投递，发送队列等待 P95 不超过 10ms、socket write P95 不超过 0.5ms，且没有发送队列满或 text write 失败。
|
||||
|
||||
现有 `realtime_fanout` 指标在 `pushForData` 之前结束。`pushForData` 位于 Topic 串行处理路径中，每条群消息遍历全部成员、构造推送收件人并调用 `sendPush`；即使成员全部在线，900 人规模下这段未计时工作仍可让后续发布在 `topic_client` 中排队。队列未达到容量上限并不代表没有排队，这与 ACK 延迟逐步增长到 19 秒、投递延迟增长到 55 秒的现象一致。下一步应先补充 `push_prepare`、`push_dispatch` 和 Topic client queue wait 指标，再将群推送准备移出 Topic 串行热路径或改为异步批处理。
|
||||
|
||||
900 人在 240 秒错峰下线后，群主 Pod 的 `topic_server full` 从 0 增至 379，说明 presence 离线扩散问题随群规模明显放大。压测机两个 agent 的峰值 CPU 分别约 39.5% 和 38.5% 单核，峰值 RSS 各约 76MB、FD 各 460，不是本轮瓶颈。
|
||||
|
||||
新增产物：
|
||||
|
||||
- 300 人精确群：`loadtest/im-pressure/results/s300-group-members-setup-0929/`
|
||||
- 300 人复测：`loadtest/im-pressure/results/s300m-group-r1-0930/`
|
||||
- 600 人精确群：`loadtest/im-pressure/results/s600-group-members-setup-0930/`
|
||||
- 600 人复测：`loadtest/im-pressure/results/s600m-group-r1-0930/`
|
||||
- 900 人精确群：`loadtest/im-pressure/results/s900-group-members-setup-0930/`
|
||||
- 900 人复测：`loadtest/im-pressure/results/s900m-group-r1-0930/`
|
||||
|
||||
## 13. 容量拐点修复（待发版复测）
|
||||
|
||||
针对精确 900 人群暴露的 Topic 串行积压和批量下线 presence 风暴，已完成以下代码改造：
|
||||
|
||||
1. `pushForData` 在 Topic goroutine 内只复制成员推送快照，不再逐成员同步查询 Redis，也不再执行跨 Pod 收件人拆分和 user updater 投递。
|
||||
2. 新增总容量 4096 的有界异步推送队列和 4 个固定分片 worker。同一 `tenant + topic` 固定进入同一分片，保证同一群的推送和未读更新顺序；不同群可并行处理。
|
||||
3. 离线成员 presence 使用一次 Redis pipeline 批量读取，单条消息的 Redis 网络往返由成员数 N 次降为 1 次。
|
||||
4. 群离线 presence 遇到 Topic server queue 满时不再直接丢弃。服务端按 `tenant + topic + source user` 合并为最新状态，并在 Topic 队列恢复后重投；待处理集合上限 16384。
|
||||
5. 新增 Topic client queue wait、push prepare、push dispatch queue、push dispatch duration、push recipient count、deferred presence 当前深度等指标。
|
||||
|
||||
新增重点指标：
|
||||
|
||||
- `im_topic_queue_wait_duration_seconds`
|
||||
- `im_message_publish_stage_duration_seconds{stage="push_prepare"}`
|
||||
- `im_push_dispatch_queue_enqueue_total`
|
||||
- `im_push_dispatch_queue_depth`
|
||||
- `im_push_dispatch_queue_wait_duration_seconds`
|
||||
- `im_push_dispatch_duration_seconds`
|
||||
- `im_push_recipient_count`
|
||||
- `im_internal_queue_current{queue="topic_presence_pending"}`
|
||||
- `im_internal_queue_enqueue_total{queue="topic_presence_deferred"}`
|
||||
|
||||
发版后先复测精确 600 人群，确认基线无回归；再复测精确 900 人群。900 人验收要求：900/900 ACK、810000/810000 实时投递、0 断连、0 持久化缺失，`topic_client/topic_server/push_dispatch` 无 full，Topic queue wait P95 不超过 500ms，ACK P95 不超过 500ms，投递 P95 不超过 1s。渐进下线结束后 deferred presence 必须回落到 0，且不得出现 `topic_server full`。
|
||||
|
||||
Reference in New Issue
Block a user