对比同步与异步的失败类别：基于第一性原理

Source: Dev.to

请提供您希望翻译的正文内容（除代码块和 URL 之外），我将按照要求保持原有的 Markdown 格式并翻译成简体中文。

1. 从第一原理出发：什么是“失败类”？

failure class 不是：

• 一个 bug
• 超时
• 停机

失败类是：

由于责任、时间和状态的结构方式而可能出错的事物的类别

因此我们要问：

• 正确性必须满足什么条件？
• 模型默认的假设是什么？
• 当这些假设不成立时会出现什么问题？

2. Core Difference (One Sentence)

• Synchronous systems 通过 阻塞 和 级联 失败。
• Asynchronous systems 通过 复制、重新排序 和 不可见性 失败。

其他一切都是其结果。

3. 同步系统 — 故障类别

定义（第一原理）

同步系统的假设是：

“调用者在被调用者完成工作之前会等待。”

这将 时间、可用性 与 正确性 绑定在一起。

故障类别 1：阻塞放大

问题： 系统等待期间会发生什么？

现实：

• 线程被阻塞
• 连接被占用
• 内存被占用

故障模式： 负载 ↑ → 延迟 ↑ → 吞吐量崩溃。
这是一种 非线性故障，不仅仅是“慢”。

故障类别 2：级联故障

问题： 如果某个依赖变慢会怎样？

由于所有操作都在等待：

• 代理变慢 → 后端变慢
• 后端变慢 → 前端重试
• 重试放大负载

故障模式： 一个慢速依赖可能导致整个系统瘫痪。

故障类别 3：可用性耦合

问题： 如果依赖宕机，系统还能运行吗？

答案（同步）： 不能。

故障模式： 部分宕机会演变为全局宕机。

小结：同步故障类别

4. 异步系统 — 故障类别

定义（第一性原理）

异步系统假设：

“工作可以稍后完成，可能会多次完成，可能顺序错乱。”

这解耦了时间，但移除了保证。

故障类别 1：重复执行

问题： 如果工作被重试会怎样？

现实：

• 至少一次交付
• 工作进程崩溃
• 消息被重新处理

故障模式： 同一逻辑操作会多次发生，破坏一次性语义和幂等性假设。

故障类别 2：顺序违规

问题： 什么定义了顺序？

现实：

• 队列不知道业务顺序
• 工作进程独立处理

故障模式： 效果出现的顺序与逻辑顺序不一致。
示例（聊天系统）： 基于未来消息的响应 → 上下文损坏。

故障类别 3：完成不可见性

问题： 用户如何知道工作何时完成？

现实：

• 没有直接信号
• 轮询或猜测

故障模式： 用户盲目等待或看到过时的状态。

故障类别 4：孤立工作

问题： 如果用户消失会怎样？

现实：

• 作业继续运行
• 响应被存储但从未被消费

故障模式： 计算资源浪费，状态泄漏。

小结：异步故障类别

5. Side‑by‑Side Contrast (Mental Model)

6. Deep Insight (Interview Gold)

• 同步系统 会 大声且立即 失败（超时、错误）。
• 异步系统 会 悄悄且稍后 失败（双写、顺序错误）。

7. 为什么两者都不是“更好”

从第一原理：

• Sync systems 保护 causality，但牺牲 availability。
• Async systems 保护 availability，但牺牲 causality。

真实系统重新引入失去的属性：

• Async systems 添加 idempotency、ordering、state machines。
• Sync systems 添加 timeouts、circuit breakers、fallbacks。

8. 记住的一行规则

• 同步在负载下会崩溃。
• 异步在模糊性下会崩溃。

下一步：

• 将这些故障类别映射到真实的宕机。
• 展示流式处理如何结合两种故障类型。
• 练习在全新系统上识别故障类别。