serial控制分批执行整个play（逻辑串行），实现滚动更新；forks控制单task在目标主机上的并行连接数（物理并发），默认5。二者作用层级不同，可配合使用，但不可混淆：serial保障业务连续性，forks提升执行效率。
在 Ansible Playbook 中控制任务执行的串行与并发，核心靠两个配置项：serial 控制分批执行（逻辑串行），forks 控制并行连接数（物理并发）。两者作用层级不同，常配合使用。
用 serial 实现滚动式串行执行
当需要避免所有主机同时升级或重启服务导致业务中断时，serial 是首选。它让 playbook 按指定数量分组执行整个 play（含所有 tasks），前一批完成后再启动下一批。
- 值可为整数（如
serial: 3）表示每批处理 3 台主机 - 也可为百分比（如
serial: "25%"）按目标主机总数动态计算批次大小 - 适用于滚动更新、服务平滑重启、数据库迁移等需强顺序保障的场景
- 注意：serial 是 play 级别设置，写在
hosts下方、tasks上方
用 forks 调整默认并发连接数
forks 决定 Ansible 控制节点同一时刻最多建立多少个 SSH 连接，默认为 5。它影响的是单个 task 在所有目标主机上的并行度，不改变执行顺序逻辑。
- 可在 ansible.cfg 中全局设置：
forks = 20 - 也可在命令行临时指定：
ansible-playbook site.yml -f 15 - 值过大可能压垮控制节点或触发目标端连接限制；过小则效率低下
- 与 serial 不冲突——例如
serial: 4+forks: 10表示：每次只对 4 台主机执行当前 play，但在这 4 台上，每个 task 最多并发 10 个连接（实际取决于主机数，此处上限即 4）
结合策略选择强化控制效果
Ansible 默认使用 linear 执行策略（等待本 task 在全部当前批次主机完成后，才进下一个 task），适合多数运维场景。若需更灵活调度，可显式声明：
-
strategy: free：某台主机完成一个 task 后立即执行下一个 task，不等其他主机——适合各主机状态差异大、任务耗时不均的情况 -
strategy: debug：用于逐 task 调试，配合--step或--start-at-task更精准定位问题 - 策略需在 play 级设置，且不能与 serial 同时用于同一 play 的某些特殊组合（如 free + serial 可能行为不可预期，建议避免）
常见误用提醒
serial 和 forks 容易混淆，关键区别在于：
- serial 是“分批跑完一整套任务”，关注的是执行节奏和业务连续性
- forks 是“同一时刻最多连几台”，关注的是资源占用和执行速度
- 不要试图用 forks 实现滚动更新——它无法保证 task 间顺序，也无法防止所有主机同时触发 handler
- serial=1 虽然最“串行”，但性能极低，仅用于极端敏感操作（如主库切换）
