一次失败能不能不“崩盘”？鸿蒙分布式系统的容错与回滚机制深度剖析

作者｜Echo_Wish（一个在分布式世界里修 bug 越修越冷静的人）

引子：一次失败，不该让整个系统陪葬

不知道你有没有遇到过这种时刻：
你点了一下“支付”，网络转圈转半天，然后——黑屏、卡顿、重试、甚至订单重复。

当时你是不是有一种“我的钱是不是没了”的心虚感？

其实在分布式系统里，这种失败几乎每天都在发生：

• 某个服务突然超时
• 某个节点突然不响应
• 某台设备掉线
• 某个跨端协同动作卡住

尤其是在 分布式鸿蒙生态 里，设备更多、边缘节点更多、协同动作更复杂，不容错就像骑自行车不装刹车——迟早出现高能事故。

所以，容错 与 回滚 是分布式系统的生命安全绳。

今天我就用最通俗的方式，把鸿蒙分布式系统中的容错与回滚，讲到你能回去就带着同事一起改代码。

原理讲解：容错与回滚到底是为了保什么？

很多人以为容错只是“别报错”，但其实它解决两个关键问题：

① 系统不要挂

无论多少节点失败、多少服务抖动，都不能让整个系统瘫痪。

② 数据不能乱

你不希望同一个支付动作执行两遍，也不希望跨设备协同时出现“一半成功，一半失败”。

所以容错（Fault Tolerance）和回滚（Rollback）是为了解决这两个核心诉求：

核心概念拆一下：

1. 失败隔离（Failure Isolation）

一个服务失败，不影响其他服务。
鸿蒙分布式架构里大量采用服务粒度拆分与独立调度让失败能被“隔离”。

2. 重试（Retry）与超时（Timeout）

简单粗暴但超级有效。
分布式系统里很多“失败”其实都是暂时不可用。

3. 回滚（Rollback）

指的是“撤销已经执行的动作”，最典型的如：

• 支付失败 → 撤销库存
• 跨设备协同失败 → 撤销已执行的子任务

4. 补偿（Compensation）

补偿是一种“逻辑回滚”，特别适合跨设备、跨场景、跨服务场景。
鸿蒙分布式任务经常用补偿动作保证一致性。

5. Saga 模式（分布式事务界的扛把子）

你可以理解为：

一系列动作 + 一系列补偿动作
只要任意一步失败 → 就执行对应补偿。

适合鸿蒙分布式业务那种“多设备协同 + 多服务串联”的复杂系统。

实战代码：以鸿蒙分布式任务为例，带你看看真实落地

下面用一个典型场景：
手机照片 → 平板编辑 → 电视展示
三个设备协同，一旦某一步失败，就需要回滚动作。

【示意：分布式任务的 Saga 模式】

// TypeScript 示例（简化版）
type Action = () => Promise<void>;
type Compensation = () => Promise<void>;

interface SagaStep {
  action: Action;
  compensation: Compensation;
}

class SagaExecutor {
  async execute(steps: SagaStep[]) {
    const executedCompensations: Compensation[] = [];

    try {
      for (const step of steps) {
        await step.action();
        executedCompensations.push(step.compensation);
      }
    } catch (error) {
      console.error("Action failed:", error);
      for (const compensate of executedCompensations.reverse()) {
        await compensate();
      }
    }
  }
}

// ====== 定义分布式协同动作 =======
const steps: SagaStep[] = [
  {
    action: async () => {
      console.log("① 同步照片到平板");
      // 分布式文件传输
    },
    compensation: async () => {
      console.log("回滚①：删除平板上的照片缓存");
    }
  },
  {
    action: async () => {
      console.log("② 平板开始编辑");
      // 调用平板编辑能力
    },
    compensation: async () => {
      console.log("回滚②：撤销编辑操作");
    }
  },
  {
    action: async () => {
      console.log("③ 发送到电视展示");
      // 分布式投屏能力
    },
    compensation: async () => {
      console.log("回滚③：关闭电视展示");
    }
  }
];

// ====== 执行分布式 Saga 协同 =======
const executor = new SagaExecutor();
executor.execute(steps);

你会看到：
只要任意一步失败，该步骤之前完成的动作都会被对应的补偿依次撤销。

即便分布式系统再复杂，也能保持一致性。

场景应用：鸿蒙设备协同里具体怎么用？

场景 1：跨设备文件协同失败

比如手机 → 平板传大文件时掉线：

• 已创建的目标文件 → 删除
• 已预留的存储空间 → 释放
• 出现半截文件 → 清理

避免出现“垃圾文件”或“进度错乱”。

场景 2：跨设备流转失败（例如应用接续）

手机接续到平板，如果平板运行失败：

• 恢复原设备会话
• 释放对平板端能力的调用
• 回滚 UI 状态

否则用户会感觉“系统卡住了”。

场景 3：分布式任务链路任意节点失败

例如智能家居（扫地机、空气净化器、灯光协同场景）：

灯开 → 启动净化器 → 启动扫地机
如果扫地机报错：

• 停掉净化器
• 灯光恢复为“默认亮度”
• 系统恢复到初始状态

让整个场景稳定一致，不出现“一半成功，一半失败”的玄学体验。

Echo_Wish 的思考：分布式世界的哲学——不要相信任何节点永远稳定

以前我也觉得系统要做得稳，就要让每个节点强壮、服务可用率拉满。后来做了多年分布式系统，我逐渐明白：

真正的稳定不是“不会失败”，而是“失败了也不怕”。

鸿蒙的分布式生态更是如此：
设备数越多，可控性越弱；协同链越长，失败概率越大。

你指望所有设备、所有服务、所有节点都永远健康？
那不是分布式，是做梦。

真正强大的系统是这样的：

• 每一步都能失败
• 每一步失败都有补偿
• 每一个补偿都是可验证的
• 每一个失败都是可恢复的