Flink 有状态任务怎么扩容？并行度和最大并行度有什么区别？
本文目录
面试怎么回答
我会先区分并行度和最大并行度。前者是当前子任务数，后者决定 Keyed State 的 Key Group 数并限制可用并行度。扩缩容时重新分配 Key Group，而不是任意拆开一个 Key 的状态。要保持算子身份和状态兼容，在既有上限内做恢复演练；更改最大并行度需要专门迁移方案。最后检查迁移时间和热点，单个热 Key 不会因加实例自动分散。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
资源已经扩好了，Flink 从 Savepoint 恢复时却提示并行度不兼容。Slot 不够只是扩容的一种阻碍；有状态任务还背着既有状态分片布局，不能把增加实例看成启动更多空进程。
当前并行度决定运行实例数，最大并行度关联 Key Group 数；有状态扩容是重新分配状态，不只是增加资源。
两个并行度，不是同一个旋钮
当前并行度决定算子运行多少个子任务；最大并行度与 Keyed State 的 Key Group 数相关，也约束可设置的并行度范围。本文按 Flink 2.1 的经典有状态恢复机制讨论。
Key Group 是状态重新分配的基本单元。它不是业务 Key 本身，一个组里可以包含许多 Key。每个 Key 通过确定的映射进入某个组，再由该组映射到具体子任务。
因此，“有一百万个用户，就需要一百万最大并行度”是误解。最大并行度也不是越大越好，状态后端可能为更多组维护额外结构，需要结合预期扩容空间评估。
扩容时，搬的是哪些状态？
假设某算子的最大并行度为 8，可以把它理解为有 8 个编号明确的 Key Group。当前并行度是 2 时，每个子任务分配一部分组；改成 4 后，组被重新分配给更多子任务。
这个示例只说明分配关系，不是推荐生产设置为 8。具体组范围由 Flink 算法决定，恢复还需要读取对应状态数据，而不只是修改一张逻辑映射表。
还要分开 Keyed State 与 Operator State。后者有自己的重分布方式，不能把所有状态都解释成 Key Group 重新划分；连接器的源分片、算子约束也可能影响最终扩容效果。
为什么不能随意改最大并行度？
既有快照中的 Keyed State 按原 Key Group 布局保存。随意改变最大并行度，会改变 Key 到组的映射关系，不能期待标准恢复过程把旧布局自动解释成新布局。
需要突破原上限时，应评估专门的状态迁移或重建方案，并核对目标版本与工具能力。不能在报错后连续试几个参数，直到任务能启动，就认定历史状态完整。
清空状态重新跑，属于另一种恢复方式，可能影响去重、窗口、聚合和外部输出。没有业务授权与补偿设计，不应把它当作普通扩容步骤。
一个典型场景：空状态测试给了错误信心
比如测试任务从并行度 2 改成 4，可以正常启动。上线时却要从已有状态恢复，而目标并行度超过了原先的最大并行度，恢复失败。
最初判断为资源调度问题，又增加了 Slot；随后直接修改最大并行度，仍无法按原状态布局恢复。根因不是算力不足，而是扩容计划没有尊重既有状态约束。
旧测试使用空状态，只证明代码能启动，没验证迁移。改进应读取现有算子配置，在上限内先做带状态恢复；若需突破上限，单独设计迁移与回滚，不能与普通参数扩容混在一起。
稳定 UID，是状态能找到归属的前提
从快照恢复时，算子身份用于匹配状态。调整链路、插入算子或升级代码时，应维护稳定的显式 UID，并检查状态名称、类型和序列化兼容性。
“允许跳过未恢复状态”也不能当作通用修复。任务虽然能运行，被跳过的可能正是关键业务状态。只有确认哪些状态可舍弃、影响如何处理后，才能作出这种选择。
恢复前记录快照位置、算子映射和配置；恢复后核对状态是否加载、业务结果是否连续。进程变绿，只代表运行状态，不代表历史逻辑已经恢复完整。
加实例，未必能拆开一个热 Key
同一个 Key 的状态和处理仍需集中在相应子任务。一个极热用户或订单分组，不会因为从 4 并行度扩到 8，就自动拆成两个并发处理单元。
如果瓶颈来自大量 Key 总体负载，扩容可能有效；如果来自单 Key，则需要按业务可分解性考虑预聚合、分层处理或键设计，且不能破坏原语义。
同时检查上游分片数、下游写入能力和外部服务限额，避免只把瓶颈搬到别处。
扩容完成，要看恢复全过程
验收包括停机或切换窗口、状态读取时间、恢复后积压消化速度、Checkpoint 稳定性与外部结果一致性。
还要保留可用的回退快照，并确认回退代码与状态兼容。提前演练真实规模，比上线时发现“资源有了、状态搬不动”更有价值。