pro/im_server

Fork 0

Files

T

richjohnrambo 0cf88e6e97 docs: add staged dual-machine pressure test runbook

2026-09-27 17:10:01 +08:00

39 KiB

Raw Blame History

IM 006 商户双机消息压力测试方案

日期：2026-09-25

1. 测试目标

双机实际操作以 loadtest/im-pressure/README.md 为准。当前开发机固定为机器 A，负责数据准备、协调器、agent A、集中采集和最终报告；另一台机器固定为机器 B，只运行 agent B 并回传结果。

当前测试环境实际企业码为 allrich，沿用本方案最初为 006 商户定义的账号规模、场景和统计口径。已完成的 200 对复测、故障根因和修复证据见 docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md。

本次测试使用 006 商户的 2000 个账号，在两台压测机上各运行 1000 个在线 WebSocket 用户，验证多 Pod 场景下：

1000 对 P2P 会话同时收发时，消息是否被接受、实时投递并最终持久化。
2000 人大群中 1000 个成员轮流发言时，跨 Pod 群广播的丢失率、重复率、乱序率和延迟。
300 对 P2P 与 500 个群发送者同时工作时，混合负载是否相互影响。
Tinode 原生 Cluster、Kafka 消息持久化、数据库分表和 WebSocket 下行是否出现容量瓶颈。

本轮不在正式发压窗口内注册账号、加好友或建群。所有数据准备完成并核验后，再开始消息压力测试。

2. 本方案对需求的精确定义

2.1 账号与机器分片

账号使用只包含小写字母和数字、且不超过 10 个字符的用户名，以满足当前注册校验：

压测机	账号	数量	用户名示例
Machine A	A0001-A1000	1000	`lta0001`、`lta1000`
Machine B	B0001-B1000	1000	`ltb0001`、`ltb1000`

固定配对关系为 A0001 <-> B0001，依此类推到 A1000 <-> B1000。“号码相同”指账号序号相同，不使用相同手机号。

每个账号最终记录：username、user_id、token、token_expires、machine、pair_no、p2p_topic、group_topic。密码只从环境变量读取，不写入结果文件或日志。

2.2 群聊需求解释

“1000 个人间隔 0.1 秒发消息，2 轮合计 2000 条”按全局调度解释：

每 100ms 只安排一个发送者发送一条消息。
每轮 1000 个发送者各发送 1 条，共 1000 条，持续约 100 秒。
连续执行 2 轮，共 2000 条，正式发压约 200 秒。
不是每个发送者每 100ms 发一条；后一种解释会产生 10000 条/秒和 100 万条/100 秒，与“合计 2000 条”矛盾。

2.3 P2P 场景默认强度

原需求未指定每对消息数。本方案默认每对双方各发 10 条：

1000 对同时开始。
每个用户每秒发送 1 条，共 10 秒；每次加 0-200ms 确定性抖动，避免所有请求落在同一毫秒。
总发布量：1000 × 2 × 10 = 20000 条。
主要期望投递量：20000 次对端投递；发送方自身回显单独统计，不混入对端丢失率。

消息数、间隔和抖动必须可通过命令行参数修改，但每轮结果必须记录实际参数。

3. 协议与接口契约

3.1 WebSocket 建连与账号注册

WebSocket 地址为 /v0/channels，Upgrade 携带普通 API Key。每个连接严格执行：

Upgrade
-> hi(tenant="006")
-> acc 或 login
-> sub(me)
-> sub(目标 P2P/群 Topic)
-> READY

006 是企业商户，注册使用 registration_type: 0 和 tenant_code: "006"：

{
  "acc": {
    "id": "prep-acc-lta0001",
    "user": "new",
    "scheme": "basic",
    "username": "lta0001",
    "registration_type": 0,
    "tenant_code": "006",
    "secret": "base64(lta0001:password)",
    "login": true,
    "desc": {"public": {"fn": "LT A0001"}}
  }
}

当前 006 环境必须确认未强制手机号或邀请码注册。准备程序应先尝试 basic 登录：已存在且密码正确则复用；仅在账号不存在时注册。账号存在但密码不匹配必须停止，禁止覆盖真实账号。

3.2 HTTP 公共请求头

好友、隐私和群接口使用登录返回的同一 Token：

X-MeetingIM-APIKey: <ordinary api key>
X-IM-Schema: 1
X-Request-ID: <unique request id>
Authorization: Bearer <token>
Idempotency-Key: <unique key for write requests>

所有密钥和 Token 通过环境变量或权限受控文件传入，日志只记录账号索引和脱敏 ID。

3.3 好友准备

对每个序号执行：

A 调用 POST /v1/im/friend-requests，Body 为 {"target_user_id":"usr_b","message":"loadtest","source":"search","source_topic":""}。
若返回 pending，B 调用 POST /v1/im/friend-requests/{request_id}/accept。
若已经是好友，读取好友列表或会话 context 并复用关系。
保存响应中的 P2P topic；必要时调用 POST /v1/im/conversations/p2p，Body 为 {"peer_user_id":"usr_b"}。
最终核验 1000 对关系均为 friend，且双方能订阅同一个 P2P Topic。

好友创建会产生 friend_added 系统消息，因此正式统计只识别本轮 run_id 对应的 x-im-client-mid，不能把 Topic 的初始 seq 当成 0。

3.4 2000 人群准备

使用 A0001 调用 POST /v1/im/groups 创建群。创建接口最多附带 99 个成员，建议只创建群主。
先确认所有账号的 group_invite_verification=false，避免进入当前尚未完整开放的邀请确认链路。
调用 POST /v1/im/groups/{topic}/invitations 分批邀请，每批不超过 100 人，每批使用独立 Idempotency-Key。
邀请完成后分页调用 GET /v1/im/groups/{topic}/members，核验去重后的有效成员恰好为 2000。
2000 个 WebSocket 全部订阅该群，并完成屏障消息验证后才允许发压。

直接邀请会产生群业务事件和系统消息。准备结束后至少静默 30 秒，并记录正式测试前的群 baseline_seq；统计时仍以 run_id/client_mid 为准。

4. 环境硬门槛

任一门槛不满足，本轮标记为 INVALID，不能把结果当作服务端性能结论：

max_subscriber_count >= 2500。仓库配置默认是 128，必须在所有 Pod 上统一调高并滚动重启。
006 商户 max_group_members 为 0（不限）或不小于 2000；目标群 max_member_count 同样满足要求。
IM Server 所有 Pod 版本和配置一致，原生 Cluster 成员数与 Running Pod 数一致。
Kafka 的 P2P、群消息持久化 Topic 可写，消费组无持续积压，死信在基线时为 0；测试环境的 im.message.persist 和 im.group.message.persist 均为 3 分区、3 副本。
两台压测机到目标入口网络稳定，文件描述符上限、临时端口和 NAT 容量足够。
两台压测机使用 chrony/NTP，同一时刻的时钟偏差绝对值小于 5ms，否则跨机器单向延迟无效。
每台压测机至少预留 2 CPU、4GB 内存和稳定的 100Mbps 网络；测试进程自身 CPU 不应长期超过 70%。
2000 个连接全部 READY；正式阶段不允许把连接失败用户从分母中静默删除。

5. 多 Pod 拓扑

仅通过同一个负载均衡入口连接，不能证明消息确实跨 Pod。推荐提供仅供压测使用的三个直连入口，并保持业务数据路径不变：

Machine A: A0001-A0500 -> Pod 0
           A0501-A1000 -> Pod 1
Machine B: B0001-B1000 -> Pod 2

这样 1000 对 P2P 的双方一定不在同一个 Pod；群成员也覆盖全部 3 个 Pod。若只能提供两个直连入口，则 Machine A 固定 Pod 0、Machine B 固定 Pod 1，并在另一轮把 Machine B 切到 Pod 2 重跑。

入口必须能明确确认实际 Pod，例如握手诊断日志或反向代理访问日志能关联 session -> pod。不要依赖负载均衡概率分布。

Topic 消息在启用 Tinode 原生 Cluster 时由 Cluster 路由；此时 Redis realtime 指标中的 publish/skip_native_cluster 是预期状态，不代表丢失。Redis 仍需观察用户级业务事件和 Session 控制类 fanout。

6. 统一消息格式

所有正式测试消息都使用 JSON 文本消息，并设置 noecho:false：

{
  "pub": {
    "id": "s1-a0001-00001",
    "topic": "p2p_or_grp",
    "noecho": false,
    "head": {
      "mime": "application/json",
      "x-im-schema": 1,
      "x-im-type": "text",
      "x-im-client-mid": "lt-20260925-s1-a0001-00001"
    },
    "content": {
      "text": "loadtest",
      "run_id": "lt-20260925-s1",
      "scenario": "p2p",
      "sender_index": 1,
      "message_index": 1,
      "sent_at_unix_nano": 0
    }
  }
}

x-im-client-mid 在 tenant + topic + sender 范围内必须唯一，重试时必须复用原值。发送程序用 {ctrl.id} 关联请求，用 ctrl.params.seq 记录服务端分配的 Topic 序号。

7. 执行阶段

7.1 阶段 P0：预检与热身

两台机器各以 50 连接/秒建立 1000 条连接，总建连时间约 20 秒。
每个用户订阅 me、自己的 P2P Topic 和群 Topic。
群主发送 1 条不计入正式结果的群屏障消息；必须在 10 秒内被 2000 个连接全部收到。
每个 P2P Topic 发送 1 条不计入正式结果的屏障消息；双方必须收到，且对端投递为 1000/1000。
等待 30 秒，确认错误计数、Kafka lag、CPU、内存和连接数回到稳定状态。

7.2 阶段 S1：1000 对 P2P 同时聊天

参与者：全部 2000 人，1000 个 P2P Topic。

默认调度：

A、B 双方各发送 10 条，每用户 1 条/秒，持续 10 秒。
每个用户使用由账号索引计算的 0-200ms 固定抖动，确保可复现。
总发布量 20000，平均发布速率约 2000 条/秒。
发布完成后保留连接并等待 30 秒排空，再进行历史核对。

主要期望：每条被服务端接受的消息恰好被对应的另一方实时收到一次。发送方回显也应收到一次，但作为独立指标。

7.3 阶段 S2：2000 人群、1000 人发言

参与者：2000 个在线订阅者。发送者选择 A0001-A0500 与 B0001-B0500，共 1000 人，避免所有发布压力只落在一台压测机上。

默认调度：

Machine A 每 200ms 发 1 条，Machine B 在其后错开 100ms 发 1 条，合并后全局间隔为 100ms。
每轮每个发送者恰好发送 1 条，共 1000 条、约 100 秒。
连续 2 轮，共 2000 条、约 200 秒。
noecho:false，因此每条被接受的消息期望投递到 2000 个在线连接。
理论实时投递总量：2000 × 2000 = 4000000 次，平均约 20000 次/秒。
发布结束后等待 60 秒排空，然后由多个校验账号分页拉取历史。

7.4 阶段 S3：P2P 与群聊混合

正式窗口为 100 秒：

P2P：A0001-A0300 与 B0001-B0300，共 300 对；双方各发 5 条，总发布量 300 × 2 × 5 = 3000。在第 0、20、40、60、80 秒附近发送，并加入固定抖动。
群聊：A0301-A0550 与 B0301-B0550，共 500 个发送者；每人发 2 条。两台机器错峰形成全局 100ms 间隔，两轮共 1000 条，持续约 100 秒。
其余用户保持在线并接收群消息。
群实时理论投递总量：1000 × 2000 = 2000000 次。
P2P 主要理论对端投递总量：3000 次；发送方回显另计 3000 次。
发布结束后等待 60 秒排空，再做 P2P 和群历史核对。

混合场景的群发送者与 P2P 发送者故意分开，便于判断瓶颈来自连接写队列、群广播还是同一连接并发写。通过后可增加一轮“发送者重叠”增强测试。

8. 丢失率与正确性口径

不能只统计压测端成功调用 WriteJSON 的数量。每轮必须同时输出以下四层结果。

8.1 发送接受率

publish_accept_rate = ctrl_202_with_seq / publish_attempted
publish_reject_rate = (ctrl_4xx + ctrl_5xx + ctrl_timeout + write_error) / publish_attempted

只有收到 ctrl.code=202 且包含有效 params.seq 的消息，才进入后续“期望投递”分母。

8.2 实时投递丢失率

实时到达率必须由 2000 个 WebSocket 连接实际监听得到，不能使用发送 ACK、Kafka offset 或数据库行数代替。每个连接建立后启动一个常驻 read loop，全量读取服务端下行，并把 {ctrl}、{data}、{meta}、{pres}、{info} 分流处理。

监听器要求：

每个 WebSocket 只能有一个 goroutine 调用 ReadMessage/ReadJSON，避免多个读取者争抢数据；ctrl 通过 id 分发给等待中的发布请求。
只统计 head.x-im-client-mid 前缀和 content.run_id 都匹配本轮的 {data}，忽略准备阶段系统消息、其他业务消息和历史噪声。
记录 receiver_index + client_mid + seq + first_received_at。相同接收者再次收到同一 client_mid 计为重复，不增加到达数。
服务端允许 {data} 早于对应 {ctrl 202} 到达，因此监听器先保存观测事实，最终再与 ACK ledger 对账，不能因为 ACK 尚未到达而丢弃该 {data}。
P2P 以配对的另一方为主要期望接收者；发送者自身回显单独统计。
群消息以发压开始时的 2000 个 READY 成员为固定分母。因为 noecho:false，发送者本人也属于期望接收者。
正式窗口内连接断开时不得从分母中删除。记录断开时间、所属机器和 Pod；服务端导致的断开计入结果，压测机自身饱和导致的断开则将整轮标记为无效。
P2P 发布结束后继续监听 30 秒，群聊和混合场景继续监听 60 秒。窗口内未收到计为实时丢失；窗口后到达另记 late_delivery，不能把它改写为正常实时到达。

期望投递账本由成功 ACK 生成：

P2P expected key   = run_id + client_mid + peer_receiver_index
Group expected key = run_id + client_mid + each_ready_receiver_index

群场景 2000 条消息对应 400 万个期望键。实现时为每个接收者维护按消息序号索引的 bitset，不保存 400 万份完整 JSON；延迟使用 HDR Histogram 或固定桶，缺失和重复才输出逐条明细。

P2P 主要口径：

p2p_realtime_loss =
  (accepted_messages - unique_peer_data_received_within_drain_window)
  / accepted_messages

群聊口径：

group_expected_deliveries = accepted_group_messages × ready_group_subscribers
group_realtime_loss =
  (group_expected_deliveries - unique_group_deliveries_within_drain_window)
  / group_expected_deliveries

每个接收者按 run_id + x-im-client-mid 去重。重复到达不用于抵消其他消息的缺失。

同时输出：

arrival_rate = unique_deliveries_within_drain_window / expected_deliveries
loss_rate = 1 - arrival_rate
late_rate = unique_late_deliveries / expected_deliveries
duplicate_rate = duplicate_deliveries / expected_deliveries

实时监听结束后继续执行历史回查，将缺失分为：

realtime_lost_but_persisted：WS 窗口内没收到，但历史中存在，说明实时投递链路丢失，客户端可通过重连补偿。
persisted_but_late：超过实时排空窗口才由 WS 收到，同时历史中存在。
durable_lost：WS 未收到且最长等待后历史也不存在，属于真正的持久化消息丢失。
receiver_disconnected：期望接收者在消息窗口内断线，单独统计并保留在实时丢失分母中。

8.3 持久化丢失率

Kafka 持久化是异步链路，ctrl 202 不等于数据库已经可查。排空后通过 {get what:"data"} 分页回查：

persistence_loss =
  (accepted_unique_messages - unique_messages_found_in_history)
  / accepted_unique_messages

P2P：1000 个 Topic 各由一侧账号回查。
群聊：至少使用分别连接不同 Pod 的 3 个成员回查，三份结果应完全一致。
最长等待 120 秒，每 5 秒重试一次；超时仍不存在才记为持久化丢失。

8.4 重复与乱序

duplicate_rate = duplicate_deliveries / expected_deliveries
out_of_order_rate = receivers_observing_seq_regression / ready_receivers

同时记录：同一 client_mid 对应多个 seq、同一 seq 对应多个测试消息、接收端 Topic seq 回退、ACK seq 与下行 seq 不一致。这些都必须单独报错，不能归入普通丢失。

9. 延迟口径

记录以下时间点：

t_write：压测端开始写 {pub}。
t_ack：收到对应 {ctrl 202}。
t_data：接收者收到并完成 JSON 解析。

输出：

ack_latency = t_ack - t_write
e2e_realtime_latency = t_data - sent_at

每个场景输出 p50、p95、p99、p99.9 和 max。跨机器延迟仅在 NTP 偏差达标时有效；否则仍可统计 ACK 延迟，但端到端单向延迟标记为无效。

群聊 400 万次投递不应把所有延迟样本常驻内存。使用固定桶直方图或 HDR Histogram，并按接收端机器和 Pod 分组。

10. 建议通过标准

第一轮基线建议使用：

指标	标准
READY 连接	2000/2000
发布接受率	100%
持久化丢失率	0
同一 `client_mid` 多 `seq`	0
P2P 对端实时丢失率	<= 0.001%，且任何丢失都要输出明细
群实时投递丢失率	<= 0.001%，发布版本验收目标为 0
重复投递率	0
Topic `seq` 回退	0
ACK p95 / p99	<= 500ms / <= 1s；必须用原始 ACK 时间戳计算，不能用直方图桶上界代替
实时投递 p95 / p99	<= 1s / <= 2s；跨机器时要求时钟偏差达标
`deliver/hub_full`、WS 写队列满	0
Kafka producer/commit 错误	0
Kafka 消费重试、单条降级、死信新增	0
Kafka 排空	发布结束后 60 秒内 lag 回到基线/0
Kafka 到 MySQL 落库 p95 / p99	< 200ms / < 500ms
MySQL 实际落库数	与 `ctrl 202` 唯一消息数完全一致
MySQL deadlock、lock timeout、连接池耗尽	0
Redis 操作错误、淘汰、拒绝连接	0
Redis command p95 / p99	< 5ms / < 10ms
Pod CPU throttling ratio	< 10%
Pod CPU、内存峰值	< limit 的 80%
容器/节点网络 drop、error	0 新增或不高于基线噪声
压测机 CPU、内存、网络	< 70%，无 read-loop backlog
Pod 重启、OOM、持续 GC/内存增长	0

如果实时有缺失但历史回查完整，结论应写“实时链路丢失、可由历史恢复”，不能写成“消息未丢失”。如果历史也缺失，则属于持久化消息丢失，直接判失败。

11. 全链路观测与资源采集

11.1 观测目标与时间窗口

监控必须能把同一轮测试拆成以下链路：

压测机 WriteJSON
-> IM Pod 收到 pub
-> Redis 分配消息 seq / 幂等 claim
-> Kafka producer 写入消息持久化 Topic
-> IM Pod 返回 ctrl 202 并实时广播
-> Kafka consumer 拉取与组批
-> MySQL 批量提交
-> Kafka offset commit
-> WebSocket 历史查询可见

每轮采集窗口为：正式 start_at 前 10 分钟、正式测试全程、排空与历史核对结束后 10 分钟。Prometheus 在压测期间建议使用 5 秒抓取周期，重要 counter 以 increase 计算，不使用瞬时值推算总量。

每轮在 Grafana 或结果文件中记录四个时间点：

baseline_start：基线开始。
load_start：正式发送开始。
load_end：最后一次发布结束。
reconcile_end：历史核对完成。

所有图表使用相同 UTC 时间轴，并标注 run_id、scenario、Git commit、Pod 镜像版本和压测参数。

11.2 采集组件

推荐最小采集栈：

对象	采集方式	主要用途
IM Server	`/metrics`、`/debug/vars`	WS、HTTP、DB、fanout、Go runtime、连接池
Kubernetes Pod/Container	kube-state-metrics + kubelet/cAdvisor	CPU、内存、磁盘 IO、网络、重启、限流
Kubernetes Node	node-exporter	节点 CPU、内存、磁盘、网络、conntrack
Kafka	kafka-exporter + Broker JMX Exporter	consumer lag、吞吐、ISR、请求队列、磁盘
Redis	redis-exporter	OPS、延迟、内存、连接、命中率、淘汰、网络
MySQL	mysqld-exporter + performance_schema	QPS、事务、锁、Buffer Pool、慢 SQL、IO
两台压测机	node-exporter + 压测 agent `/metrics`	生成端 CPU/网络/连接和客户端统计
链路探测	blackbox-exporter 或压测 agent 主动探测	DNS、TCP、HTTP、依赖 RTT

如果环境没有完整 Prometheus 栈，压测前至少以 5 秒周期抓取上述 HTTP 指标，并同步保存 kubectl top、Pod 日志、Kafka consumer group、Redis INFO 和 MySQL status。手工快照只能作为兜底，不能替代连续时间序列。

11.3 当前已有与必须补充的应用指标

当前 IM Server 已经提供：

指标	状态	用途
`ws_connections_active`	已有	当前 Pod/实例的活跃 WS 数
`http_requests_total`	已有	HTTP 请求量和错误码
`http_request_duration_seconds`	已有	HTTP 延迟
`db_query_duration_seconds`	已有	MySQL query/exec/commit 等通用耗时
`realtime_fanout_events_total`	已有	Redis realtime 发布、接收和本地投递结果
`realtime_fanout_delivery_duration_seconds`	已有	Redis realtime 消息年龄
`/debug/vars` 中 `DbStats`	已有	Go SQL 连接池状态
`/debug/vars` 中 Cluster/Session/Topic 计数	已有	Cluster 节点、会话和活跃 Topic

为准确测量 Kafka 落库速度，压测版本必须再补以下低基数指标。严禁把 topic、user_id、client_mid、run_id 或 tenant ID 放入 Prometheus label：

message_persist_events_total{stage,kind,status}
message_persist_duration_seconds{stage,kind,status}
message_persist_end_to_end_seconds{kind,status}
message_persist_batch_size{kind}
message_persist_inflight{kind}
kafka_consumer_commit_total{topic_kind,status}
redis_operation_duration_seconds{operation,status}
redis_operation_errors_total{operation}
mysql_pool_connections{state}
mysql_pool_wait_total
mysql_pool_wait_duration_seconds_total
cluster_route_events_total{operation,status}
cluster_route_duration_seconds{operation,status}
ws_outbound_events_total{status}
ws_outbound_queue_depth

标签约定：

kind：仅允许 p2p、group。
stage：producer_write、consumer_fetch、db_batch、consume_finish。
status：ok、error、duplicate、retry、dead。
operation：Redis 使用 seq_reserve、unique_claim、hot_cache、fanout_publish、fanout_receive；Cluster 使用 route、proxy_join、proxy_leave。

message_persist_end_to_end_seconds 从 Kafka envelope 的 occurred_at 计算到 MySQL 提交并标记消费成功的时刻。它是回答“消息从服务端接受到真正落库用了多久”的核心指标。

另外应在自定义 Prometheus Registry 中注册 Go collector 和 process collector，提供标准 go_*、process_* 指标；在完成前从 /debug/vars 采集对应 runtime 数据。

11.4 Kafka 处理速度与积压

Kafka 需要同时观察应用层和 Broker 层，至少包含：

P2P Topic im.message.persist 的生产/消费条数与字节数。
群 Topic im.group.message.persist 的生产/消费条数与字节数。
对应 consumer group 每个 partition 的 lag、总 lag 和 lag 恢复到 0 的时间。
producer 写入延迟、错误、重试和 timeout。
consumer fetch 速率、批量大小、DB 批次耗时、offset commit 延迟和失败。
批量落库失败后降级为单条写入的次数。
消费重试、Redis 幂等 claim 失败和死信新增数。
Broker request queue、network processor idle、request handler idle、ISR shrink、under-replicated/offline partition 和磁盘使用率。

不同 exporter 的 lag 指标名可能是 kafka_consumergroup_lag 或 kafka_consumergroup_group_lag，部署时必须以实际 /metrics 为准建立 dashboard，不允许直接照抄不存在的指标名。

典型查询：

sum by (kind, stage, status) (
  rate(message_persist_events_total[1m])
)

histogram_quantile(
  0.99,
  sum by (le, kind) (
    rate(message_persist_end_to_end_seconds_bucket[5m])
  )
)

sum by (consumergroup, topic) (
  kafka_consumergroup_lag{
    topic=~"im.message.persist|im.group.message.persist"
  }
)

每轮报告必须给出：峰值生产速度、峰值消费速度、峰值 lag、lag 清零耗时、平均/最大 batch size、DB batch p95/p99、端到端落库 p95/p99/max、重试数和死信数。

11.5 数据库落库正确性与速度

006 商户使用默认库 meeting_im，但消息表名按数据库中的数值 tenant_id 生成，不能直接把企业码字符串当表后缀。准备阶段先从租户注册信息解析并记录 006 的真实 tenant_id，再生成只读核对 SQL。

当前消息存储位置：

P2P：im_<tenant_id三位补零>_messages，例如真实 tenant ID 为 6 时是 im_006_messages。
群聊：im_<tenant_id三位补零>_group_messages_YYYYMM。
群消息分片注册：im_group_message_shards。
Kafka 消费幂等状态：Redis kafka_consume namespace，TTL 7 天。
Kafka 死信：MySQL im_kafka_dead_letters。

正式核对优先使用 WebSocket 历史接口，SQL 作为服务端审计证据。SQL 由核对程序使用白名单表名生成，不允许把外部输入直接拼入表名。

P2P 落库数量示例：

SELECT
  COUNT(*) AS rows_written,
  COUNT(DISTINCT client_msg_id) AS unique_client_mid,
  MIN(createdat) AS first_persisted_at,
  MAX(createdat) AS last_persisted_at
FROM im_006_messages
WHERE client_msg_id LIKE 'lt-20260925-s1-%';

群消息落库数量示例：

SELECT
  COUNT(*) AS rows_written,
  COUNT(DISTINCT client_msg_id) AS unique_client_mid,
  MIN(created_at) AS first_persisted_at,
  MAX(created_at) AS last_persisted_at
FROM im_006_group_messages_202609
WHERE client_msg_id LIKE 'lt-20260925-s2-%';

重复检查：

SELECT client_msg_id, COUNT(*) AS cnt, MIN(seqid), MAX(seqid)
FROM im_006_messages
WHERE client_msg_id LIKE 'lt-20260925-s1-%'
GROUP BY client_msg_id
HAVING COUNT(*) <> 1;

群表执行同样检查。P2P 有 1000 个 Topic，不能用整张表的 MAX(seq)-MIN(seq)+1 判断丢失；必须以压测端保存的 client_mid -> topic -> ack_seq manifest 与数据库逐条比对。

MySQL 性能至少采集：

Threads_connected、Threads_running、连接使用率和连接池 wait count/duration。
QPS、Com_insert、事务提交/回滚、行写入速度。
InnoDB Buffer Pool 命中率、dirty pages、checkpoint age、log waits。
row lock waits/time、deadlock、慢 SQL、临时磁盘表。
data/log fsync、读写 IOPS、吞吐、磁盘 await、util 和剩余空间。
P2P 批量 INSERT、群月表批量 INSERT 的 p95/p99。
主从架构下的 replication lag；压测历史回查必须明确读主还是读从。

数据库落库速度报告包含两个值：

db_write_throughput = 测试消息成功落库数 / 首次到最后一次 DB commit 时间
drain_time = 最后一条 ctrl 202 到 Kafka lag=0 且全部历史可见的时间

11.6 Redis 观测

Redis 在当前消息链路中承担 seq 分配、client_mid 幂等 claim、群热消息缓存、Kafka 消费幂等状态和用户级 realtime fanout。需要采集：

instantaneous_ops_per_sec、命令总量与各命令耗时。
connected/blocked clients、连接拒绝和连接创建速度。
used memory、RSS、碎片率、maxmemory 使用率。
evicted/expired keys、keyspace hit/miss。
network input/output bytes、Pub/Sub channel/pattern/subscriber 数。
Redis 主线程 CPU、事件循环延迟、slowlog 数量。
Sentinel/主从环境的 role、replication offset、replication lag、failover。
seq_reserve、unique_claim、hot_cache、kafka_consume 操作错误和 p95/p99。

压测期间禁止使用无界 KEYS 或全库 SCAN 做统计，这会污染结果。Kafka 消费状态只通过应用指标抽样统计，不逐条扫描 Redis key。

常见异常判定：

evicted keys 或 rejected connections 增加：直接判失败。
used memory 持续增长且排空后不回落：检查 hot message、幂等 key TTL 和消费记录泄漏。
p99 command latency 超过 10ms：标记风险；超过 50ms 且与消息延迟尖刺相关时判失败。
replication lag 持续扩大或发生 failover：本轮单独标记，不与无故障基线混合。

11.7 Pod、容器与节点资源

每个 IM Pod 单独展示，不只看 namespace 汇总：

sum by (pod) (
  rate(container_cpu_usage_seconds_total{namespace="im-server-system",container="im-server"}[1m])
)

sum by (pod) (
  container_memory_working_set_bytes{namespace="im-server-system",container="im-server"}
)

sum by (pod) (
  rate(container_network_receive_bytes_total{namespace="im-server-system",pod=~"im-server-.*"}[1m])
)

sum by (pod) (
  rate(container_network_transmit_bytes_total{namespace="im-server-system",pod=~"im-server-.*"}[1m])
)

必须采集：

CPU 使用核数、CPU limit 使用率、CFS throttled seconds/periods。
memory working set、RSS、cache、limit 使用率、OOM 和 page fault。
容器文件系统 read/write bytes、IOPS、IO wait；若根文件系统不承载业务数据，也要观察日志写入压力。
网络接收/发送 bytes、packets、errors、drops、TCP retransmit。
Pod restart、readiness、liveness、Pending/NotReady 时间。
Go goroutine、heap、stack、GC 次数、GC pause、进程文件描述符。
LiveSessions、LiveTopics、LiveClusterNodes、Cluster leader 和代理 Topic 数。
Node CPU steal/iowait、内存压力、磁盘压力、网络错误、conntrack 使用率。

资源报告既要给峰值，也要给排空后是否回落。单个 Pod 明显高于其他 Pod 时，结合连接分布、Topic master 位置和网络流量判断是否发生热点。

建议风险线：

Pod CPU 持续超过 limit 的 80%，或 throttling ratio 超过 10%。
memory working set 超过 limit 的 80%，或排空 10 分钟后仍持续增长。
节点磁盘 util 持续超过 80%，await 持续超过 20ms。
网络 drop/error 或 TCP retransmit 明显增长。
任一 Pod restart/OOM/NotReady，直接判本轮失败。

11.8 网络时延与压测机资源

两台压测机分别持续测量：

到各 Pod 直连入口和负载均衡入口的 DNS、TCP connect、TLS handshake、HTTP /healthz RTT。
WebSocket Ping/Pong RTT p50/p95/p99/max，每 5 秒一次，不能用业务 note kp 代替协议 Ping。
到 Kafka、Redis、MySQL 服务地址的 TCP connect RTT；只做低频只读探测，不绕过业务链路写数据。
两台压测机之间的 RTT、丢包和 NTP offset。
压测进程 CPU、RSS、GC、goroutine、FD、socket、send/receive bytes、read-loop queue depth。

压力生成端出现 CPU > 70%、网卡 > 70%、FD 接近上限、read-loop backlog 或 GC 尖刺时，本轮标记 LOAD_GENERATOR_SATURATED，不能把客户端处理不过来算成服务端丢消息。

11.9 现有 fanout 与 Cluster 查询

每轮开始前记录 counter 快照，结束后记录增量：

sum by (stage, kind, target_type, status) (
  increase(realtime_fanout_events_total[10m])
)

histogram_quantile(
  0.99,
  sum by (le, kind, target_type) (
    rate(realtime_fanout_delivery_duration_seconds_bucket[5m])
  )
)

Topic 消息使用原生 Cluster 时，publish/skip_native_cluster 增加属于正常现象。重点检查 Cluster 连接数、route/proxy 错误、node for topic not found、gob 编解码错误、Hub 队列满和 WS 写失败。

11.10 日志、快照与关联规则

压测日志统一带 run_id、scenario、machine、account_index 和脱敏 Topic hash。服务端日志不新增用户 ID 或 client_mid 的高基数 Prometheus label；需要定位时通过压测端保存的 manifest 关联。

每轮保存：

Prometheus 查询结果或 Grafana dashboard snapshot。
IM Pod、Kafka、Redis、MySQL 在测试窗口内的错误日志。
Kafka consumer group 压测前、峰值、结束、排空后的 offset/lag 快照。
Redis INFO、SLOWLOG 摘要和 exporter 指标快照。
MySQL GLOBAL STATUS、InnoDB status 摘要、慢 SQL 摘要和表行数核对。
kubectl top pod/node、Pod restart/condition/event 和容器日志摘要。
两台压测机 node/process 指标及 agent summary。

日志采集必须过滤 Token、密码、API Key、Kafka/Redis/MySQL 凭证和完整消息正文。

11.11 建议仪表盘布局

一张压测 dashboard 分为六行：

业务结果：attempt、ACK、实时接收、历史可见、丢失、重复、乱序、p95/p99。
IM Pod：连接数、发布/下行速率、Cluster route、CPU、内存、GC、goroutine。
Kafka：producer/consumer rate、lag、batch、commit、retry、dead letter、broker health。
Redis：OPS、command latency、memory、clients、network、eviction、replication。
MySQL：insert/transaction rate、DB batch latency、pool wait、locks、Buffer Pool、IO。
基础设施：Pod/Node CPU、memory、disk IO、network、压测机资源和网络 RTT。

所有面板至少按 Pod、Kafka Topic/consumer group、Redis instance、MySQL instance 和压测机分组；不得只展示总和。

12. 压测程序结构

现有 loadtest/realtime_fanout_probe.go 只支持单群和单进程，不能直接用于本方案。新工具使用 Go 实现并提供六个子命令：

im-pressure prepare   注册、好友、群和 manifest
im-pressure verify    只读核验 2000 账号、1000 对关系和 2000 群成员
im-pressure coordinator 协调双机 READY、统一起跑时间、ACK 台账与结果上报
im-pressure agent     在每台压测机运行连接与场景
im-pressure collect   抓取 Prometheus、K8s 和依赖组件快照
im-pressure merge     合并两台机器结果并生成报告

推荐文件：

loadtest/im-pressure/config.example.yaml
loadtest/im-pressure/cmd/im-pressure/
loadtest/im-pressure/internal/protocol/
loadtest/im-pressure/internal/prepare/
loadtest/im-pressure/internal/runner/
loadtest/im-pressure/internal/collector/
loadtest/im-pressure/internal/report/

协调方式：Machine A 启动 coordinator，等待 A/B 两个 agent 都上报 1000 个 READY，然后发布一个至少晚于当前时间 30 秒的 UTC start_at。两台机器按相同 run_id 和确定性调度执行。任何 agent 失联都将本轮标记为 INVALID。

agent 自身暴露 /metrics，提供连接状态、发布、接收、重复、乱序、断连及 Go/process 指标；ACK 和投递延迟分布写入最终 summary。collect 只执行只读查询，并把各数据源的原始快照与查询时间一起保存；连接凭证通过环境变量传入，不写入结果目录。

13. 结果文件

每轮保留以下文件：

results/<run_id>/config.redacted.json
results/<run_id>/manifest.sha256
results/<run_id>/agent-a-summary.json
results/<run_id>/agent-b-summary.json
results/<run_id>/publish.jsonl
results/<run_id>/missing.jsonl
results/<run_id>/duplicate.jsonl
results/<run_id>/history-reconcile.json
results/<run_id>/db-reconcile-p2p.json
results/<run_id>/db-reconcile-group.json
results/<run_id>/timeline.json
results/<run_id>/metrics/im-server.prom
results/<run_id>/metrics/load-agent.prom
results/<run_id>/metrics/kafka.json
results/<run_id>/metrics/redis.json
results/<run_id>/metrics/mysql.json
results/<run_id>/metrics/kubernetes.json
results/<run_id>/metrics/network.json
results/<run_id>/logs/im-server-errors.log
results/<run_id>/logs/kafka-errors.log
results/<run_id>/logs/mysql-slow-summary.log
results/<run_id>/grafana-snapshot.json
results/<run_id>/report.md

缺失明细至少包含 run_id、场景、Topic 脱敏哈希、发送者索引、接收者索引、client_mid、ACK seq、发送时间、最后等待时间、发送 Pod 和接收 Pod。不得写入 Token、密码、API Key 或完整手机号。

最终 report.md 必须分别给出：

压测业务量和消息正确性结论。
实时投递与历史恢复结论。
Kafka 生产、消费、lag、排空和死信结论。
MySQL 落库数量、吞吐、耗时、锁与 IO 结论。
Redis OPS、耗时、内存、幂等/seq 错误和 fanout 结论。
每个 Pod/Node 以及两台压测机的资源峰值和瓶颈判断。
测试是否有效、是否通过，以及所有未通过项的原始证据路径。

14. 推荐执行顺序

在测试窗口前完成环境门槛检查和 2000 账号准备。
完成 1000 对好友关系与 2000 人群，运行 verify 直到全部通过。
先用 20 对 P2P、100 人群做冒烟测试，验证统计口径。
执行 P0 热身。
P2P 按 200 对、500 对、1000 对逐级执行；每一级通过后才能进入下一级。
执行 S2 群聊，等待恢复基线至少 10 分钟。
执行 S3 混合场景。
合并结果，按实时链路与持久化链路分别给出结论。
全部稳定后再单独进行 Pod 重启、断网或 Kafka/Redis 故障注入，不与本轮无故障基线混跑。

14.1 P2P 容量阶梯

三个档位复用同一批账号和好友关系，只裁剪 runtime manifest，不重新注册或重复加好友。每档至少执行两轮；发布验收档建议执行三轮。任何一轮出现消息丢失、重复、乱序、非预期拒绝、数据库不一致或 Pod 重启，都必须停止升级并先定位。

档位	A/B 用户	WS 总数	每用户消息	Publish 总数	目标
P2P-200	各 200	400	10	4000	验证正确性、指标和基础延迟
P2P-500	各 500	1000	10	10000	验证 Kafka 三分区、MySQL 和 Cluster 中档容量
P2P-1000	各 1000	2000	10	20000	单聊发布验收

每档的执行流程固定为：生成唯一 run_id；开始前采集至少 2 分钟基线；启动 coordinator；A/B agent 全部 READY；统一时间发压；P2P 发送结束后继续监听至少 30 秒；等待 Kafka lag 归零；执行历史回查与 MySQL client_mid 精确核验；发送结束后继续采集至少 5 分钟；最后合并报告。

每档升级门槛：Ready、Publish ACK、实时到达、历史查询和 MySQL 精确匹配全部达到期望数；丢失、重复、乱序、断连、403/502/503、Cluster queue overflow、Kafka retry/dead letter、MySQL deadlock、Pod 重启均为 0；Kafka lag 在发送结束后 60 秒内归零；Pod 无持续 CPU throttling。ACK P95 超标时必须按压测机分别报告，并先排除 DNS、TCP、TLS、WebSocket RTT 和时钟偏差。

14.2 P2P 通过后的业务场景

GROUP-2000：2000 条 WS 全部加入同一群，A/B 各 500 个发送者；每人发送 2 条，两轮合计 2000 条。实时投递期望量按每条消息的实际 Ready 接收者计算，并保留 60 秒 drain。
MIXED：300 对私聊用户双方各发 5 条，共 3000 条私聊 Publish；同时 A/B 各 250 个群发送者每人发 2 条，共 1000 条群 Publish。
稳定性复跑：GROUP 和 MIXED 至少各两轮，确认无冷启动偶然性。
故障注入：分别执行单 Pod 滚动重启、Kafka 短暂不可用与恢复、Redis 短暂不可用与恢复；故障轮只验证恢复能力，不与无故障性能基线混合统计。

14.3 当前下一步

当前已通过 P2P-200 的消息正确性、Kafka 60 秒排空、MySQL 精确落库、零乱序、零审计死锁和零 CPU throttling。下一步执行 P2P-500：A/B 各取账号索引 1..500，共 1000 条 WS、10000 条 Publish。若连续两轮满足上述升级门槛，再进入 P2P-1000。

39 KiB Raw Blame History Unescape Escape