2、回滚机制基础：回滚的定义、回滚与重启的关系、回滚的触发条件

聊AB分区，绕不开回滚。说白了，回滚就是系统出问题后，能快速退回到上一个可用状态的能力。我见过不少团队，分区方案做得漂漂亮亮，结果回滚逻辑一塌糊涂，上线后出问题只能干瞪眼。这一节，咱们把回滚的底裤扒干净。

2.1 回滚到底是个什么东西？

回滚，英文叫 Rollback。在AB分区的语境下，它的定义很明确：当系统检测到当前运行的分区（比如新版本 B 分区）出现不可接受的故障时，主动将系统切换回另一个已知正常的分区（比如旧版本 A 分区）的过程。

注意几个关键词：

• 主动：不是系统崩溃后被动重启，而是有预谋、有检测、有执行步骤的切换。
• 已知正常：回滚的目标分区必须是之前验证过的、确认能正常工作的版本。
• 过程：回滚不是瞬间完成的，它包含检测、决策、执行、验证四个阶段。

我个人习惯把回滚比作「后悔药」。你想想看，做嵌入式开发，OTA升级失败是家常便饭。没有回滚机制，设备变砖就只能返厂。有了回滚，最多就是版本没升上去，功能不受影响。

2.2 回滚 vs 重启：别搞混了

这个问题我每次培训都要强调。很多新手把回滚和重启混为一谈，觉得「出问题了重启一下不就行了？」——还真不行。

对比维度	回滚（Rollback）	重启（Reboot）
本质	切换运行分区	重新加载当前分区
版本变化	版本降级（新→旧）	版本不变
触发原因	新版本功能异常	系统卡死、内存泄漏等
数据影响	可能回退数据状态	数据通常保留
执行时间	秒级到分钟级	秒级
风险等级	中（涉及分区切换）	低（仅重启进程）

我在项目中遇到过一种情况：设备升级后Wi-Fi连不上，运维人员远程重启了三次，问题依旧。为什么？因为重启后还是跑的新版本，bug还在那里。最后通过回滚切回旧分区，问题秒解。这就是回滚和重启的本质区别——重启治标，回滚治本。

2.3 回滚的触发条件：什么时候该跑？

回滚不能乱触发。触发太灵敏，用户天天回滚，新版本永远推不上去。触发太迟钝，设备带病运行，用户体验极差。我总结了一套触发条件的分级体系，供你参考。

2.3.1 致命级触发条件（必须回滚）

• 系统无法启动：新分区在启动阶段卡死、panic、看门狗超时。
• 核心功能失效：比如通信模块完全无法初始化，传感器无响应。
• 安全漏洞：新版本引入了严重的安全风险（比如私钥泄露）。
• 连续崩溃：系统在短时间内（比如5分钟内）崩溃超过3次。

2.3.2 严重级触发条件（建议回滚）

• 关键功能降级：功能能用，但性能下降超过50%（比如帧率从60fps掉到20fps）。
• 内存泄漏：内存占用持续增长，无法稳定。
• 数据损坏：检测到文件系统错误或关键配置数据校验失败。
• 外设异常：某个外设（如屏幕、触摸）间歇性失灵。

2.3.3 提示级触发条件（记录但不回滚）

• 偶发告警：单个非关键模块报错，但系统整体正常。
• 性能波动：CPU占用偶尔飙高，但能自行恢复。
• 日志异常：出现非预期的日志输出，但功能未受影响。

2.4 回滚触发流程：从检测到执行

光有触发条件还不够，你得有一套完整的执行流程。我画了一张图，把回滚触发的完整链路展示出来。

这张图展示了回滚触发的完整链路。核心在于「异常判定与分级」这一步——不是所有异常都要回滚，你得根据严重程度做决策。我习惯在判定模块里加一个「计数器」，连续异常才触发，避免偶发抖动导致误回滚。

2.5 回滚触发的最佳实践

最后，分享几个我在实际项目中踩过的坑和总结的经验。

1. 触发条件要分层：致命级自动回滚，严重级可配置（建议自动），提示级只记录。别一刀切。
2. 加个延迟：检测到异常后，别立刻回滚。等几秒钟，确认不是瞬态故障。我一般设3-5秒的延迟窗口。
3. 保留手动触发接口：自动回滚再智能，也架不住特殊情况。给运维留一个手动触发回滚的通道，关键时刻能救命。
4. 记录回滚日志：每次回滚都要写日志，写清楚触发原因、触发时间、回滚前后版本号。这是事后排查问题的关键证据。
5. 限制回滚次数：防止系统在AB分区之间来回震荡。我一般设一个「1小时内最多回滚2次」的限制，超过则锁定当前分区。