Fan-out（扇出）介绍（一个分布式系统 / 消息队列中的常见模式，指一条消息触发后，自动派生出多条并行的下游调用）fan out
本地栈是 platform 模式 + 真实 DashScope key——每次上传简历会真调 embedding，一次 discovery run 会对每个职位 fan-out LLM 分析（历史事故：143 职位 ≈ 300 次调用清空预算）。触发任何流程前先追查 MQ 消费者的下游 fan-out。
验证 LLM 逻辑用 mock；活体验证最多单条 smoke。
fan-out 是什么？
文章目录
- Fan-out 解释
- 用你这段上下文来理解：
- 为什么它是"事故元凶"
- 这段笔记的核心警告
Fan-out 解释
Fan-out（扇出）是一个分布式系统 / 消息队列中的常见模式，指的是：
一条消息触发后，自动派生出多条并行的下游调用。
用你这段上下文来理解：
MQ 收到一条消息："请对这批职位做 discovery 分析" │ ▼ Consumer 消费这条消息 │ ├──▶ 职位 1 → 调 1 次 LLM ├──▶ 职位 2 → 调 1 次 LLM ├──▶ 职位 3 → 调 1 次 LLM │ ... └──▶ 职位 143 → 调 1 次 LLM一条消息进来，143 条 LLM 调用散出去—— 这就是 fan-out。
为什么它是"事故元凶"
| 因素 | 说明 |
|---|---|
| 放大倍数不可控 | 职位数量决定调用次数，开发者很容易低估 |
| 用的是真 key | 每次 fan-out 都在烧真金白银 |
| 看起来只是"跑了一下" | 你以为触发了一次流程，实际触发了 300 次 API 调用 |
这段笔记的核心警告
在执行任何流程之前，先搞清楚 MQ 消费者下游会 fan-out 出多少次真实 API 调用。
换句话说：一条消息 ≠ 一次调用，一条消息可能 = N 次调用（N = 职位数）。这就是预算被"清空"的根本原因。