---
title: "更新策略"
description: "配置副本更新顺序、并行度、观察窗口和失败动作，并评估容量与业务影响。"
---

> Documentation Index
> Fetch the complete documentation index at: https://cdelivery.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 更新策略

更新策略决定运行副本如何替换。Operator 或 Admin 在应用配置中设置这些字段；它会影响配置更新和重启等需要重新创建容器的操作。

## 字段与默认值

| 字段 | 默认值 | 作用 |
| --- | --- | --- |
| 并行度 | 全部 | 每轮同时更新的副本数量 |
| 顺序 | StopFirst | 先停止旧副本，再启动新副本 |
| 观察时间 | 60 秒 | 判断新任务失败的观察窗口 |
| 最大失败比例 | 0% | 超过阈值时触发失败动作 |
| 失败动作 | Rollback | 更新失败后尝试回到上一份配置 |

观察时间不是两批更新之间固定等待的延迟，也不是业务就绪检查。应用需要业务响应验证时配置 XHealth 或 Guardian。

## 选择更新顺序

**StopFirst** 先停止旧实例，额外容量需求较低，但单副本应用可能中断服务。

**StartFirst** 先启动新实例，新旧副本可能短暂重叠。它需要足够资源和可用调度位置，应用本身也必须允许并行运行。仅选择 StartFirst 并不能保证零停机，尤其当进程运行后仍需要较长初始化时间时。

使用本地数据的数据库应特别注意同一数据目录的并发访问。不要未经确认让新旧数据库进程同时操作同一份数据。

## 选择并行度与失败动作

多个无状态副本可使用较小并行度，逐批替换并观察业务。并行处理全部副本会扩大一次变更的影响范围。

| 失败动作 | 含义 |
| --- | --- |
| Continue | 继续更新，需要操作者持续观察 |
| Pause | 暂停更新，等待人工判断 |
| Rollback | 尝试恢复可用的上一份配置 |

回滚不恢复业务数据，也不提供任意历史版本选择。当前回滚执行时并行处理全部副本，失败动作是继续，继承更新顺序、观察时间和失败比例；不能假定回滚与正向更新的并行度完全相同。

## 修改策略前检查

1. 当前应用是否有足够副本承担业务。
2. 服务器是否能容纳新旧实例重叠。
3. 每台服务器副本上限和标签是否允许更新。
4. 应用启动、连接排空和数据兼容是否满足所选方式。
5. 是否需要启用[发布验证](/docs/zh-cn/guides/release-safety/guardian/)。

保存后先在可控环境验证一次版本更新，观察副本替换、请求错误和日志。出现等待时检查[资源](/docs/zh-cn/guides/apps/resources/)与[调度](/docs/zh-cn/guides/apps/placement/)，不要只修改并行度。

Source: https://cdelivery.dev/docs/zh-cn/guides/release-safety/update-strategy/index.mdx