feat: add global semaphore to limit concurrent snapshot builds

2026-10-11 06:39:59 +08:00 · 2025-12-29 16:35:12 +08:00
parent cd2fd77789
commit 94939d4665
2 changed files with 77 additions and 20 deletions
@@ -233,12 +233,35 @@ zhenxun/

 ## 风险与缓解

-| 风险         | 缓解措施                        |
-| ------------ | ------------------------------- |
-| 快照数据过期 | 合理的 TTL + 主动失效机制       |
-| 快照构建延迟 | 异步构建 + 首次访问降级到旧流程 |
-| 内存占用增加 | 监控内存使用 + 合理的缓存清理   |
-| 数据一致性   | 写操作后立即失效缓存            |
+| 风险              | 缓解措施                                     |
+| ----------------- | -------------------------------------------- |
+| 快照数据过期      | 合理的 TTL + 主动失效机制                    |
+| 快照构建延迟      | 异步构建 + 首次访问降级到旧流程              |
+| 内存占用增加      | 监控内存使用 + 合理的缓存清理                |
+| 数据一致性        | 写操作后立即失效缓存                         |
+| **DB 过载风险**   | **全局 Semaphore 限制并发构建数量 (50)**     |
+| **并发构建重复**  | **按 cache_key 的 asyncio.Lock**             |
+| **构建等待超时**  | **3 秒超时后返回默认快照，允许请求继续处理** |
+
+### 并发控制机制
+
+```
+大量消息同时进入时:
+
+1. 同一 user:group:bot 组合
+   - 使用 asyncio.Lock 保证只构建一次
+   - 其他等待的协程复用同一个 Future 结果
+
+2. 不同 user:group:bot 组合
+   - 使用全局 Semaphore 限制最多 50 个并发构建
+   - 超过限制的请求排队等待（最多 3 秒）
+   - 等待超时则返回默认快照，避免请求阻塞
+
+这样即使 1000 个不同用户同时发消息:
+- 最多只有 50 个并发 DB 查询
+- 每个构建 5-7 次查询 = 最多 350 次并发 DB 查询
+- 远低于直接查询的 6000 次
+```

 ---