2. 回滚策略设计：全量回滚 vs 增量回滚、快速回滚 vs 精准回滚、回滚的原子性与一致性
回滚策略，说白了就是「出事了怎么把系统拉回来」。很多团队只准备了「一键回滚」，结果真出事时发现——要么回滚太慢，要么回滚不干净，要么回滚到一半卡住了。
我经历过一次惨痛的教训。某次数据库迁移，我们用了全量回滚，结果数据量太大，回滚跑了 40 分钟。这 40 分钟里，业务完全不可用。老板在群里问：「还要多久？」我答不上来。嗯，从那以后，我开始认真研究回滚策略的选型。
2.1 全量回滚 vs 增量回滚
这是最基础的选择题。全量回滚，就是把整个服务或数据恢复到上一个稳定版本。增量回滚，只回滚变更过的部分。
| 对比维度 | 全量回滚 | 增量回滚 |
|---|---|---|
| 回滚范围 | 整个服务/数据集 | 仅变更部分 |
| 回滚速度 | 慢（依赖数据量） | 快（只处理差异） |
| 实现复杂度 | 低（全量替换即可） | 高（需要记录变更清单） |
| 风险点 | 回滚期间服务不可用 | 部分回滚可能残留脏数据 |
| 适用场景 | 无状态服务、静态资源 | 数据库迁移、配置变更 |
举个例子。你部署了一个 Nginx 配置，发现新配置导致 502。全量回滚就是直接把旧的 nginx.conf 覆盖回去，然后 reload。增量回滚呢？你得知道改了哪几行，只把那几行改回来。显然，全量回滚更省心。
但数据库就不一样了。全量回滚意味着把整个库恢复到备份点，这期间所有新写入的数据都会丢失。增量回滚只撤销本次迁移的 DDL 或 DML，其他数据不受影响。
2.2 快速回滚 vs 精准回滚
这两个维度，其实是在「速度」和「精度」之间做 trade-off。
快速回滚，追求的是「最短时间恢复服务」。哪怕恢复后的状态不完全一致，只要业务能跑就行。典型做法：切流量到旧版本集群、切换 DNS、回退负载均衡权重。
精准回滚，追求的是「恢复到变更前的精确状态」。每条数据、每个配置、每个文件都必须和变更前一模一样。典型做法：逐条执行逆向操作、校验 checksum、比对快照。
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 线上 P0 故障 | 快速回滚 | 先恢复服务，再慢慢修数据 |
| 数据库 schema 变更 | 精准回滚 | 数据一致性比速度重要 |
| 配置中心推送 | 快速回滚 | 配置回退通常秒级生效 |
| 灰度发布异常 | 精准回滚 | 只回滚灰度节点，不影响全量 |
我个人习惯：先快后准。出故障时，第一优先级永远是「让用户能用」。哪怕回滚后数据有偏差，也比系统挂掉强。等服务恢复了，再慢慢做精准修复。
2.3 回滚的原子性与一致性
这是最容易被忽略的点。很多人以为回滚就是「把旧版本部署上去」，但分布式系统里，回滚操作本身也需要满足 ACID 特性。
原子性：回滚要么全部成功，要么全部失败。不能出现「A 节点回滚了，B 节点没回滚」的情况。
一致性：回滚完成后，系统状态必须和变更前一致。不能出现「配置回滚了，但缓存里还是新配置」的情况。
我遇到过最典型的案例：某次配置推送，回滚脚本只改了数据库里的配置项，但没清理本地缓存。结果服务 reload 后，读到的还是旧缓存里的新配置。嗯，这就是「回滚不一致」的典型表现。
实现原子性回滚，我推荐用「两阶段提交」的思路：
- 准备阶段：记录回滚前的快照，锁定资源，校验回滚条件是否满足。
- 执行阶段：执行回滚操作，更新状态。
- 确认阶段：校验回滚结果，释放锁。如果校验失败，触发补偿机制。
当然，两阶段提交有性能开销。对于高频低风险的变更（比如配置推送），可以用「一阶段回滚 + 异步校验」来折中。
2.4 回滚策略选择矩阵
说了这么多，到底怎么选？我整理了一个决策矩阵，你可以直接套用：
| 变更类型 | 推荐策略 | 原子性要求 | 一致性要求 |
|---|---|---|---|
| 无状态服务部署 | 全量 + 快速 | 低 | 低 |
| 数据库 DDL | 增量 + 精准 | 高 | 高 |
| 配置中心推送 | 全量 + 快速 | 中 | 中 |
| 灰度发布 | 增量 + 精准 | 高 | 中 |
| 缓存刷新 | 全量 + 快速 | 低 | 低 |
| 数据迁移 | 增量 + 精准 | 高 | 高 |
你想想看，如果每次变更都按这个矩阵来设计回滚策略，出问题的概率会低很多。至少，你不会在数据库迁移时用全量回滚，也不会在配置推送时搞两阶段提交。
下面这张图，是我总结的回滚策略决策流程，你可以参考：
最后说一句：回滚策略不是写文档用的，是要真能跑起来的。我见过太多团队，回滚方案写得天花乱坠，真到用的时候脚本报错、权限不够、依赖缺失。所以，每次变更上线前，我要求团队必须做一次回滚演练。哪怕只是跑个 dry-run，也比纸上谈兵强。