配置回滚如何保证所有实例最终一致？
简化版
回滚通过创建新的发布版本，把目标内容指向已验证的历史配置；它不是删除记录，也不是要求所有实例瞬间同时切换。 服务端持久化唯一的当前期望版本，通知客户端尽快拉取，并以周期校准补偿丢消息。 客户端校验后原子应用并上报实际版本，平台持续重试、隔离失败实例，直到目标集合全部收敛或被明确处置。
详细版
回滚记录携带新发布序列、历史内容引用、目标作用域和 changeId。 客户端不直接接受通知中的旧内容，而是查询自己的当前期望版本，避免乱序通知把状态再次覆盖。 加载失败时保留最后正确配置并报告原因。
平台明确分母，展示成功、失败、未知、离线和已缩容实例。 未追平实例可摘流、重启或人工修复；离线实例重连时主动拉当前版本。 若配置已经触发数据写入或外部调用，版本收敛只保证后续行为一致，历史副作用还需要补偿。
完整版教学
一、先理解“最终一致”
分布式客户端受网络、进程暂停和重启影响，不可能在同一时刻完成切换。 合理保证是：在服务端当前版本不再变化且故障恢复后，所有可达目标最终使用同一配置。 业务若不能容忍混合窗口，要额外采用兼容协议、流量暂停或栅栏。
回滚恢复的是配置期望状态；它不会自动撤销已经发生的业务副作用。
二、回滚应形成新版本
release 210 -> content C
release 211 -> content D
release 212 -> content C (rollback of 211)发布序列继续递增，内容可引用历史版本。 这样能处理通知顺序并完整审计谁在何时因何回滚。 直接把版本号从 211 改回 210 会使一些只接受新序列的客户端忽略回滚。
三、唯一期望状态
服务端为每个环境、租户、命名空间和灰度目标计算当前期望版本。 通知只告诉客户端状态可能变化，客户端随后读取当前真值。 即使先收到 release 212 再迟到收到 211，重新读取仍得到 212。 发布指针更新必须与回滚记录在可靠存储中一致提交。
四、客户端原子应用
客户端下载完整内容，验证身份、摘要、schema、范围和跨字段约束。 成功后构建不可变对象并原子交换；失败则继续使用旧快照。 连接池等资源需要先创建新池、健康验证、切流，再排空旧池。 最后上报 appliedVersion 和结果码，而不是只上报 receivedVersion。
五、收敛状态与分母
| 状态 | 含义 | 处置 |
|---|---|---|
| applied | 已应用回滚版本 | 继续观察 |
| failed | 下载或应用失败 | 重试/摘流 |
| unknown | 无近期心跳 | 核对实例状态 |
| offline | 已知离线 | 重连后追平 |
| removed | 已缩容 | 移出目标集合 |
100 个目标中 98 个成功、1 个失败、1 个未知时，收敛率是 98%，不能宣布完成。
六、重试和反熵
通知失败不应阻止服务端提交回滚。 客户端长轮询或周期校准发现差异，并采用有上限的指数退避重试下载。 重试带随机抖动，防止全量回滚造成服务端洪峰。 平台也可对失败实例下发重新校准命令，但操作必须幂等。
七、业务副作用与多键关系
若错误配置已经以错误价格创建订单，恢复旧价格只影响新订单，旧订单要按业务规则补偿。 数据库 schema、消息格式等不兼容变更不能只靠配置回滚。 有关联的多个键应组成不可变配置集一次切换。 回滚前确认旧内容仍与当前代码兼容，历史正确不等于现在仍安全。
八、常见误区与追问
- 误区：点击回滚后所有实例瞬间一致。 网络和应用耗时决定存在收敛窗口。
- 误区：回滚就是把版本号减一。 应创建新的单调发布序列。
- 误区：通知可靠就不需要校准。 离线与进程故障仍会漏通知。
- 误区：配置恢复会撤销业务数据。 已产生副作用需要独立补偿。
- 追问：如何处理一直失败的实例？ 摘流、定位、修复或重建，不能从分母中静默删除。
- 追问：旧通知晚到怎么办？ 客户端重新读取当前期望状态，而非盲目应用事件。
- 追问：何时可宣布完成？ 目标集合收敛、业务指标恢复且未知实例已明确处置。
九、加强记忆
- 回滚以新发布序列引用旧内容。
- 服务端保存唯一当前期望状态。
- 通知加速，周期校准补漏。
- 客户端校验、原子切换并上报实际版本。
- 版本收敛不等于副作用撤销，失败实例必须显式处置。