🔌 连接池台账：backend 视角（内存盘 6 图）

场景 1 · 下午三点接口集体变慢，第一个该看的图

症状：好几个不相关的接口 P99 同时抬头。常规做法是挨个翻接口日志——错，先看 DB 池：所有请求共用书架，书架借空是「集体变慢」最常见的公共原因。

# 第 1 步：看哪个 worker 的哪格书架在贴 100%（先定位再开药）
max_over_time(siliang_db_pool_connections{state="checked_out"}[1m])
  / on(instance,pool)
  max_over_time(siliang_db_pool_capacity[1m])
# → 每条线 = 一个 worker 的一格书架；贴 1.0 的就是打满点

# 第 2 步：打满通常是「占着书不还」的慢查询/锁，顺手对一眼锁冲突哨兵
sum(increase(siliang_db_lock_errors_total{job="siliang_backend_worker"}[1h]))
# → > 0：去锁冲突率面板按 operation, code 定位（1205=等太久，1213=死锁）

判读：使用率回落且锁冲突为 0，是流量高峰的正常挤压；使用率钉死 100% 不动，去日志找那条占着 80 条 async 连接的慢查询。

场景 2 · 「你画我看不见」：广播池打满事故

症状：用户反馈画布协作不同步。协作消息跨机器全靠 Redis 的 broadcaster_pubsub 广播池——它打满，消息就发不出去。

# 广播池使用率（pool 取值以图例为准：shared / broadcaster_pubsub）
max_over_time(siliang_redis_pool_connections{state="in_use",pool="broadcaster_pubsub"}[1m])
  / on(instance,pool)
  max_over_time(siliang_redis_pool_capacity{pool="broadcaster_pubsub"}[1m])

# 互证：核心盘 WS 错误类型里 redis_pubsub > 0 = 广播失明
sum(rate(siliang_ws_errors_total[5m])) by (error_type)

判读：池贴 100% 且 redis_pubsub 错误出现 = 实锤；广播池是专线，被业务池挤到的可能性低，优先查广播 subscriber 是不是堆积了。

场景 3 · 给 DB 池配上 80% 黄 / 95% 红两级告警

池打满到排队只是几秒的事，等人工发现就晚了。把通用阈值固化成两级告警（阈值为口径卡通用口径，for 时长按业务调整）。

# 示例告警规则（Prometheus rule YAML，阈值=主图谱通用口径）
groups:
- name: db-pool
  rules:
  - alert: DbPoolUsageHigh
    expr: max_over_time(siliang_db_pool_connections{state="checked_out"}[1m])
        / on(instance,pool) max_over_time(siliang_db_pool_capacity[1m]) > 0.80
    labels: {severity: warning}   # 黄：开始找慢查询
    annotations: {summary: "DB 池使用率 > 80%（{{ $labels.instance }} / {{ $labels.pool }}）"}
  - alert: DbPoolSaturated
    expr: max_over_time(siliang_db_pool_connections{state="checked_out"}[1m])
        / on(instance,pool) max_over_time(siliang_db_pool_capacity[1m]) > 0.95
    labels: {severity: critical}  # 红：贴 100% 就开始排队，P99 跟着起飞
    annotations: {summary: "DB 池使用率 > 95%，即将打满排队"}

场景 4 · 发布后确认「连接复用」没被改没了

背景：有人优化代码时把共享 client 换成了「每次请求 new 一个」——功能全对，性能悄悄劣化。m113 就是抓这种回退的哨兵。

# 有聊天流量的时段，每个 provider 的总机都应该是 1
max by (provider) (max_over_time(siliang_shared_http_client_alive[1m]))
# → 出现 0：连接复用被回退，退回每次新建连接（TCP 握手+TLS）

# 旁证：FD 与内存抖动会同步出现（对照内存盘线程/FD 面板）
max_over_time(siliang_process_open_file_descriptors[1m])
max_over_time(siliang_process_resident_memory_bytes[1m])

判读：alive 恒 1 且 FD 平稳 = 复用健在；alive 掉 0 且 FD 锯齿变粗 = 实锤回退，回查该时段的发布。

场景 5 · Redis 池莫名偏高，先问「是不是别人在用」

shared 池是和 Agent 服务合用的借书证——对方用得多，你的使用率也会高。看到 Redis 池高就重启 Redis，十有八九是打错靶子。

# shared 池使用率（与 Agent 服务共用，上限 50）
max_over_time(siliang_redis_pool_connections{state="in_use",pool="shared"}[1m])
  / on(instance,pool)
  max_over_time(siliang_redis_pool_capacity{pool="shared"}[1m])
# → 高但本服务没加流量：先对 Agent 侧用量与发布，别急着重启 Redis

# 对照：biz 仪表盘 b7/b8 是同一口径（上限 50，max_connections）
max_over_time(siliang_biz_redis_pool_connections{state="in_use"}[1m])

判读：两边同时抬高 = 共用方挤占或 Redis 本身变慢（借出去还得慢）；只有一边高 = 查那边的流量来源。

场景 6 · checkpointer 池要单独看，别埋进「业务池」里

checkpointer（检查点）走的是独立书架（容量 30），和业务查询互不抢书——所以它的使用率波动节奏和 sync / async 不同步属正常，巡检时单独过一眼。

# 单独看 checkpointer 格的使用率（业务高峰它不跟涨是正常的）
max_over_time(siliang_db_pool_connections{state="checked_out",pool="checkpointer"}[1m])
  / on(instance,pool)
  max_over_time(siliang_db_pool_capacity{pool="checkpointer"}[1m])
# → 天花板 30：贴 100% = 检查点写库排队，和业务池打满是两种病

# 三格书架一屏总览（巡检收尾）
max by (pool) (max_over_time(siliang_db_pool_connections{state="checked_out"}[1m]))
  / on(pool) max by (pool) (max_over_time(siliang_db_pool_capacity[1m]))

判读：sync / async 随业务同步起伏、checkpointer 独立波动 = 三格书架各司其职；三格一起贴 100% = 数据库本身变慢（借了还不上），去查 DB 侧。