master-worker架构需兼顾任务划分、动态负载均衡与可靠结果合并：任务须无依赖可聚合，负载按节点能力动态分配，结果通过唯一id、版本号和超时重试保障不丢、有序、容错。

Master-Worker 架构在并发执行中，核心在于“怎么分任务”“怎么让各 Worker 跑得差不多快”“最后结果怎么不乱、不丢”，三者缺一不可。负载均衡不是平均分配，结果合并也不是简单拼接——关键看任务特性、节点能力和通信机制。

负载均衡不能只靠轮询

轮询法最直观：1号任务给 Worker A，2号给 B，3号再给 A……但它忽略了一个事实：不同子任务实际耗时可能差几倍。比如图像缩放里，一张纯白图解码快，一张高噪点图解码慢，硬轮询会导致部分 Worker 长期空转。

• 推荐用动态反馈式分配：Worker 完成一个子任务后，主动上报耗时和当前负载（如 CPU 使用率、待处理队列长度），Master 据此调整下一批任务的去向
• 对计算量差异大的任务，提前做细粒度拆分：把一个大任务切为 100 个更小单元，而非 10 个粗粒度块，提升调度灵活性
• 可引入加权策略：给高性能 Worker 设定更高权重（如 2.0），普通 Worker 权重 1.0，任务按权重比例分发，避免“好马驮轻货”

任务划分必须满足无依赖与可聚合

如果子任务之间要互相等结果，就破坏了并行前提。Master 分发前需确认：每个子任务是否能独立输入、独立输出、无需跨 Worker 通信。

• 适合场景举例：日志清洗（按文件分）、模型推理（按 batch 分）、矩阵乘法（按行列块分）
• 不适合场景：带状态的流式处理、需要全局排序的归并、存在强数据依赖的图遍历——这类任务得换架构，或先做预处理剥离依赖
• 建议在任务描述中嵌入元信息，比如“id=task-442, type=filter, input_range=[1000–1999], requires_no_other_output=true”，方便 Master 校验可分发性

结果合并要防丢失、保顺序、容失败

Worker 返回结果不是发完就完事。网络可能丢包，节点可能宕机，结果可能重复返回——合并环节得有兜底逻辑。

• 每个结果附带唯一 task_id 和 version 号，Master 用哈希表缓存，收到重复 id 时比对 version，只留最新版
• 对要求输出顺序的任务（如分片日志按时间戳合并），不在 Worker 端排序，而由 Master 拿到全部结果后统一 sort-by-key 再组装
• 设置超时重试：Worker 超过阈值未响应，Master 标记该子任务为 failed，并重新分发给其他空闲 Worker（需确保任务幂等）

不复杂但容易忽略