3、映射策略总览：静态映射 vs 动态映射
好，咱们直接切入正题。算子映射，说白了就是决定「哪个算子跑在哪台机器上」。这个问题看似简单，但在高吞吐压测下，选错策略的代价往往是灾难性的。
我记得刚带团队那会儿，有个线上服务压测到 2000 QPS 就扛不住了，CPU 利用率却只有 40%。排查了半天，发现是映射策略太死板——所有计算密集型的算子全挤在了一台机器上。嗯，这就是典型的静态映射踩坑案例。
3.1 静态映射：简单但僵硬
静态映射，就是在任务启动前，把算子到物理节点的对应关系固定死。运行期间不再改变。
核心特征：
- 映射关系在部署时确定
- 运行期间不感知负载变化
- 资源分配是「一次性」的
举个例子，假设你有 4 个算子（A、B、C、D）和 2 台机器（Node1、Node2）。静态映射可能是这样：
// 伪代码示意
mapping = {
"A" -> "Node1",
"B" -> "Node1",
"C" -> "Node2",
"D" -> "Node2"
}
// 运行期间，这个映射不会变静态映射的优势很明显：零运行时开销，没有调度器在中间折腾，延迟极低。我在做实时风控系统时，就偏爱这种方案——因为每一微秒的抖动都可能让一笔交易误判。
但它的缺点同样致命：扛不住突发流量。你想想看，如果 Node1 上的算子 A 突然收到 10 倍流量，而 Node2 上的算子 D 却在摸鱼，静态映射只能干瞪眼。
我曾经踩过的坑： 有一次做离线批处理，用了静态映射。结果某个分区的数据量是其他分区的 5 倍，导致那个节点 OOM，整个任务重跑。后来我学乖了——数据倾斜严重的场景，千万别用纯静态映射。
3.2 动态映射：灵活但有代价
动态映射正好相反。它会在运行时根据集群状态，实时调整算子与节点的绑定关系。
说白了，就是加了一个「调度大脑」。这个大脑会持续收集：
- 各节点的 CPU / 内存 / 网络 IO
- 各算子的处理延迟和队列深度
- 数据流的倾斜程度
然后做出决策：把重负载的算子挪到空闲节点上。
// 动态映射的决策逻辑（简化版）
while (true) {
load = collectLoadMetrics()
if (load.node1 > THRESHOLD_HIGH) {
migrate("算子A", "Node1", "Node3") // 迁移
}
sleep(100) // 每 100ms 检查一次
}动态映射的好处是能自适应。我参与过一个直播弹幕系统，晚高峰流量波动极大。用了动态映射后，系统能自动把弹幕过滤算子分散到多台机器上，吞吐量提升了 3 倍。
但代价也很实在：
- 调度延迟：每次迁移需要序列化状态、传输数据、重建连接
- 抖动风险：迁移过程中，部分请求可能超时
- 复杂度飙升：你需要一个可靠的调度器，它本身可能成为瓶颈
我的个人习惯： 如果业务允许秒级延迟抖动，我会优先考虑动态映射。但如果要求 P99 延迟在 10ms 以内，我倾向于用静态映射 + 预分片，而不是动态调度。
3.3 映射策略的评估维度
选静态还是动态，不能拍脑袋。我一般从三个维度来评估：
| 维度 | 静态映射 | 动态映射 |
|---|---|---|
| 负载均衡 | 依赖预分配，容易倾斜 | 实时调整，均衡性好 |
| 资源利用率 | 可能有闲置节点 | 能压榨每台机器的潜力 |
| 稳定性 | 高，无运行时抖动 | 中等，迁移过程有风险 |
3.3.1 负载均衡
负载均衡不是简单的「每个节点跑一样多的算子」。你得看算子的实际消耗。我见过有人把 10 个轻量算子均匀分布，结果一个重量级算子把整台机器打满——这叫「假均衡」。
动态映射在这方面有天然优势。它能根据实时 CPU 使用率做调整。但要注意：频繁迁移反而会恶化负载。我曾经见过一个系统，调度器每 5 秒就迁移一次，结果 30% 的 CPU 都花在了序列化和网络传输上。
3.3.2 资源利用率
资源利用率，说白了就是「你花了多少钱，用出了多少活」。静态映射下，你得按峰值来预留资源。比如某个算子峰值需要 8 核，你就得给它配 8 核，哪怕平时只用 2 核。
动态映射可以超配。它允许你给 10 个算子总共分配 40 核，但实际物理只有 32 核。因为不是所有算子同时高峰。嗯，这里要注意：超配比例要控制好，否则一旦并发高峰，系统就雪崩。
一个实用的经验值： 对于 CPU 密集型算子，超配比例建议在 1.2~1.5 倍之间。对于 IO 密集型，可以到 2~3 倍。这是我压测了十几个项目后总结出来的。
3.3.3 稳定性
稳定性是我最看重的维度。你想想看，一个系统吞吐再高，如果每 10 分钟抖一次，生产上谁敢用？
静态映射的稳定性是「硬」的——没有调度动作，就没有抖动。适合金融交易、工业控制这类场景。
动态映射的稳定性是「软」的——它通过迁移来换取均衡，但迁移本身会引入短暂的不稳定。我一般会加一个「冷却期」：迁移完成后，至少 30 秒内不再对该算子做新的调度决策。
避坑指南： 动态映射一定要设置「迁移上限」。我曾经没加这个限制，结果一次大规模重调度导致集群网络被打满，所有节点都开始超时——典型的「调度风暴」。后来我规定：单次最多迁移 5 个算子，且间隔至少 10 秒。
3.4 知识体系总览
下面这张图，是我梳理的映射策略核心逻辑。你可以把它当作决策参考：
这张图的核心逻辑很简单：先看稳定性要求，再看负载特征，最后决定用静态还是动态。没有银弹，只有权衡。
好了，这一节就到这里。映射策略是后续所有优化的基础——你选错了，后面再怎么调参都是白费力气。
想要更多资料，联系可可