现在来讨论一下后端处理并发多个任务的问题，假设我们的生意很好，假设20000人注册，按照计算同一时间最多可能多少人并发拍照上传生成场景？多少人同时导出视频？还有多少人浏览场
景？有没有最佳实践进行估算，并作出应对方案？

● 这是个很好的问题，让我先看一下当前系统的实际处理能力边界，再做估算。

Searched for 5 patterns (ctrl+o to expand)

● Bash(nproc && free -h | head -3 && df -h / | tail -1)
⎿ 4
total used free shared buff/cache available
Mem: 7.5Gi 2.4Gi 524Mi 18Mi 4.9Gi 5.1Gi
… +2 lines (ctrl+o to expand)

Searched for 2 patterns, read 1 file (ctrl+o to expand)

● Bash(pm2 show rust-backend 2>/dev/null | grep -E 'exec_mode|instances|script|cwd|node_args|exec_interpreter')
⎿ │ script path │ /www/wwwroot/stag.cps.vin/weixin-demo-01/backend-rust/target/release/backend-rust │
│ script args │ N/A │
│ script id │ 0 │
│ exec cwd │ /www/wwwroot/stag.cps.vin/weixin-demo-01/backend-rust │

Searched for 1 pattern (ctrl+o to expand)

● 现在信息够了。下面给你完整的分析和方案。

并发估算与应对方案

一、从 20,000 注册用户估算并发

业界通用的漏斗估算方法：

┌──────────────┬────────────────┬─────────────┬────────────────────────────┐
│ 层级 │ 比例 │ 人数 │ 说明 │
├──────────────┼────────────────┼─────────────┼────────────────────────────┤
│ 注册用户 │ 100% │ 20,000 │ 总量 │
├──────────────┼────────────────┼─────────────┼────────────────────────────┤
│ 月活 MAU │ 20-30% │ 4,000-6,000 │ 消费类小程序典型值 │
├──────────────┼────────────────┼─────────────┼────────────────────────────┤
│ 日活 DAU │ 10-20% of MAU │ 400-1,200 │ 学习类产品粘性较高，取 15% │
├──────────────┼────────────────┼─────────────┼────────────────────────────┤
│ 峰值在线 │ 10-20% of DAU │ 80-240 │ 晚间高峰 20:00-22:00 │
├──────────────┼────────────────┼─────────────┼────────────────────────────┤
│ 峰值并发请求 │ 10-20% of 在线 │ 8-48 │ 同时在发请求 │
└──────────────┴────────────────┴─────────────┴────────────────────────────┘

三种操作的并发拆分（按峰值在线 200 人估算）：

┌───────────────────┬──────────┬────────────┬──────────┬───────────────────────┐
│ 操作 │ 活跃比例 │ 峰值并发 │ 单次耗时 │ 瓶颈 │
├───────────────────┼──────────┼────────────┼──────────┼───────────────────────┤
│ 浏览场景 │ 70-80% │ 140-160 人 │ 50-200ms │ 数据库查询，最轻 │
├───────────────────┼──────────┼────────────┼──────────┼───────────────────────┤
│ 拍照上传+生成场景 │ 5-10% │ 10-20 人 │ 30-90s │ 智谱AI API 是外部瓶颈 │
├───────────────────┼──────────┼────────────┼──────────┼───────────────────────┤
│ 导出视频 │ 2-5% │ 4-10 人 │ 20-60s │ FFmpeg 是 CPU 瓶颈 │
└───────────────────┴──────────┴────────────┴──────────┴───────────────────────┘

二、当前系统的真实瓶颈

看代码后，当前架构有一个结构性风险：

用户请求 → API → tokio::spawn → 直接执行重任务

场景生成（task.rs:71）和视频导出（video.rs:45）都是用 tokio::spawn 直接无限制地并发。没有队列、没有信号量、没有并发上限。

在当前 4 核 7.5G 服务器上，这意味着：

┌───────────────────┬────────────────────────────────────┬──────────────────────────────┐
│ 瓶颈 │ 上限 │ 说明 │
├───────────────────┼────────────────────────────────────┼──────────────────────────────┤
│ 智谱AI API │ 看你的套餐 QPM，免费版约 60次/分钟 │ 10 个并发可能就触发限流 │
├───────────────────┼────────────────────────────────────┼──────────────────────────────┤
│ FFmpeg │ 4 核同时跑 4 个就满了 │ 10 个并发会 OOM 或 CPU 100% │
├───────────────────┼────────────────────────────────────┼──────────────────────────────┤
│ PostgreSQL 连接池 │ max_connections(10) │ 200 并发浏览会被连接池卡住 │
├───────────────────┼────────────────────────────────────┼──────────────────────────────┤
│ 内存 │ 7.5G 可用约 5G │ 每个 FFmpeg 进程约 200-500MB │
└───────────────────┴────────────────────────────────────┴──────────────────────────────┘

最危险的场景：如果某节课后 50 个学生同时上传图片生成场景 → 50 个 tokio::spawn 同时请求智谱AI → 触发限流 → 全部失败 → 用户重试 → 雪崩。

三、应对方案（按优先级排序）

P0 — 立即要做（防止雪崩）

场景生成加信号量限流

// 全局信号量，控制同时只有 N 个场景生成任务在跑
static SCENE_SEMAPHORE: Lazy<Semaphore> = Lazy::new(|| Semaphore::new(3));

// task.rs 里
let permit = SCENE_SEMAPHORE.acquire().await.unwrap();
scene_worker::process_scene_task(worker_state, worker_task_id).await;
drop(permit);

建议并发数：3（受智谱AI API QPM 限制，60/20 ≈ 3-5 个并发）
视频导出加信号量限流

static VIDEO_SEMAPHORE: Lazy<Semaphore> = Lazy::new(|| Semaphore::new(2));

// video.rs 里
let permit = VIDEO_SEMAPHORE.acquire().await.unwrap();
video_export::process_video_export(worker_state, worker_job_id).await;
drop(permit);
drop(permit);

建议并发数：2（4 核服务器，留 2 核给 API 服务）
增大数据库连接池

// main.rs: 把 10 改成 20-30
.max_connections(20)

P1 — 近期要做（提升体验）
排队反馈机制

被信号量拦住的任务不应该静默等待，应该：
任务状态设为 queued
前端轮询时展示"排队中，前面还有 N 人"
数据库加一个 queued 状态的计数查询
智谱AI 限流兜底

在 call_zhipuai_model 里加 429 状态码处理，触发指数退避重试，而不是直接失败。

P2 — 量起来后要做
分级架构

小程序 → Nginx → API 服务（轻量，可水平扩展）
↓ 任务队列（DB 表）
Worker 进程（独立，可单独扩容）
↓
智谱AI / FFmpeg

把重任务从 API 进程拆到独立 worker，API 只负责入队和返回，worker 从队列拉取执行。这样可以：
API 层水平扩展（负载均衡多个实例）
Worker 层独立扩容（加机器加 worker 数量）
数据库优化
浏览场景的查询加合适的索引（owner_id, scene_type, created_at）
热门公开场景加 Redis 缓存
连接池考虑 PgBouncer

四、容量估算总结

┌──────────┬──────────────────┬────────────────────┬──────────────────────┐
│ 场景 │ 当前能扛 │ 需要改进 │ 扛住 20000 用户 │
├──────────┼──────────────────┼────────────────────┼──────────────────────┤
│ 浏览场景 │ ₁₀₀ 并发 │ 连接池调大 │ 加缓存即可 │
├──────────┼──────────────────┼────────────────────┼──────────────────────┤
│ 上传生成 │ 无限制，可能雪崩 │ 加信号量(3) + 排队 │ 拆 worker │
├──────────┼──────────────────┼────────────────────┼──────────────────────┤
│ 导出视频 │ 无限制，可能 OOM │ 加信号量(2) + 排队 │ 拆 worker + 专用机器 │
└──────────┴──────────────────┴────────────────────┴─────────────────────┘

一句话：浏览层面这台 4C8G 服务器扛 20000 用户没问题。但场景生成和视频导出必须在代码层加并发限制，否则 20 个人同时操作就能把服务打挂。P0 的信号量方案改动量很小（每个加 3
行代码），建议尽快做。