seaweedfs/sw-block/design/v2-algorithm-overview.zh.md

# V2 算法综述

日期：2026-03-27
状态：战略级设计综述
读者：CEO / owner / 技术管理层

## 文档目的

本文用于说明 `sw-block` 当前 `V2` 方向背后的核心判断：

- `V2` 到底想解决什么问题
- 为什么 `V1` / `V1.5` 不足以作为长期架构
- 为什么我们仍然认为基于 `WAL` 的方向值得继续走
- `V2` 与主要市场方案 / 论文路线相比的取舍是什么
- `simulation` 与真实 `test runner` 如何形成系统化验证闭环

这不是 phase 汇报，也不是对生产可用性的承诺文档。

它是对 `V2` 这条架构线的高层技术解释。

## 与其他文档的关系

| 文档 | 作用 |
|------|------|
| `v1-v15-v2-comparison.md` | 三条技术线的详细比较 |
| `v2-acceptance-criteria.md` | V2 协议验证下限 |
| `v2_scenarios.md` | 场景清单与 simulator 覆盖 |
| `v2-open-questions.md` | 仍未关闭的算法问题 |
| `protocol-development-process.md` | 协议开发方法论 |
| `learn/projects/sw-block/algorithm_overview.md` | 当前 V1/V1.5 系统级算法综述 |
| `learn/projects/sw-block/design/algorithm_survey.md` | 论文 / vendor 调研与借鉴项 |
| `learn/projects/sw-block/test/README.md` | 真实测试系统入口 |
| `learn/projects/sw-block/test/test-platform-review.md` | test runner 的平台化方向 |

## 1. 执行摘要

当前最准确的结论是：

- `V1` 证明了基于 `WAL` 的复制块存储基本路径是可行的。
- `V1.5` 在真实恢复场景上已经比 `V1` 明显更强，并且有真实硬件上的运行证据。
- `V2` 的意义，不是在已有逻辑上继续打补丁，而是把最关键的恢复与一致性问题直接上升为协议对象。

`V2` 的核心想法可以概括为：

- 短间隙恢复要显式
- 过期 authority 要显式 fencing
- `catch-up` 与 `rebuild` 的边界要显式
- 恢复 ownership 要成为协议的一部分，而不是实现细节里的偶然行为

所以今天正确的策略是：

- 继续用 `V1.5` 作为当前生产线
- 继续用 `V2` 作为长期架构线
- 继续认真研究 `WAL` 路线，因为现在我们已经具备了可信的验证框架
- 如果后续 prototype 证明 `V2` 有结构性缺陷，就应当先演进到 `V2.5`，而不是硬着头皮直接实现

## 2. V2 真正要解决的问题

从前端看，块存储似乎只有几个简单动作：

- `write`
- `flush` / `sync`
- failover
- recovery

但真正难的，不是这些前端动作本身，而是异步分布式边界：

- primary 本地 WAL 追加
- replica 端 durable progress
- client 可见的 sync / commit 真值
- failover / promote 时的数据边界
- lag、restart、address change、timeout 后的恢复正确性

这才是 `V2` 存在的根因。

项目已经反复验证过：块存储真正的 bug 通常不出在 happy path，而出在：

- replica 短暂掉线又回来
- replica 重启后地址变化
- 延迟到达的 stale barrier / stale reconnect 结果
- 一个 lagging replica 看起来“差一点点就能恢复”
- failover 时基于错误 lineage 做了 promote

`V2` 就是要把这些情况变成协议的第一公民，而不是上线后再继续被动修补。

## 3. 为什么 V1 / V1.5 不够

这份综述不需要长篇回顾 `V1` 和 `V1.5` 的所有细节。

只需要讲清它们为什么不足以作为长期架构。

### `V1` 做对了什么

`V1` 建立了最重要的基础：

- 严格有序的 `WAL`
- primary-replica 复制
- 基于 `epoch + lease` 的初步 fencing
- 以 `extent` 作为稳定数据面，而不是一开始就做全日志结构

### `V1` 的不足

它的关键短板主要在恢复与退化场景：

- 短 outage 很容易演化成 rebuild 或长期 degraded
- 恢复结构过于隐式
- changed-address restart 脆弱
- stale authority / stale result 还不是协议层的显式对象
- 系统没有足够清晰地区分：
  - 当前 head
  - committed prefix
  - recoverable retained range
  - stale / divergent tail

### `V1.5` 的不足

`V1.5` 已经解决了不少真实问题：

- retained-WAL catch-up
- same-address reconnect
- `sync_all` 的真实行为
- catch-up 失败后的 rebuild fallback
- changed-address restart 之后的 control-plane 刷新

所以它今天是更强的生产线。

但它仍然不是长期架构，因为它本质上仍然是增量修复：

- reconnect 逻辑仍然附着在旧 shipper 模型上
- 恢复 ownership 是先作为 bug 暴露出来，再逐步被抽象
- `catch-up` vs `rebuild` 更清楚了，但还不够成为协议顶层契约
- 整体感觉仍然更像“继续修 V1”，而不是“定义下一代复制协议”

### `V2` 的变化

`V2` 不是重新发明一个完全不同的存储模型。

它的目标是把最关键的东西显式化：

- recovery ownership
- lineage-safe recovery boundary
- `catch-up` / `rebuild` 分类
- per-replica sender authority
- stale-result rejection
- 明确的 recovery orchestration

因此最诚实的比较是：

- `V1.5` 今天在运行证据上更强
- `V2` 今天在架构质量上更强

这不是矛盾，而是“当前生产线”和“下一代架构线”应有的分工。

```mermaid
flowchart TD
    V1[V1]
    V15[V1_5]
    V2[V2]
    realFailures[真实故障]
    realTests[真实硬件验证]
    simAndProto[仿真与原型]

    V1 --> V15
    V15 --> V2
    realFailures --> V15
    realFailures --> V2
    V15 --> realTests
    V2 --> simAndProto
```

## 4. V2 如何解决 WAL 与 Extent 的同步问题

`V2` 的核心问题不是“还要不要 WAL”。

真正的问题是：

**primary 与 replica 之间，WAL 和 extent 如何保持同步，同时还能兼顾稳定性与性能。**

这才是 `V2` 的中心。

### 4.1 基本分工

`V2` 把数据路径拆成两个既分离又协作的层：

- **WAL**：近期历史的有序真相
- **extent**：稳定的物化数据镜像

WAL 负责：

- 严格写入顺序
- 本地崩溃恢复
- 短间隙 replica catch-up
- 基于 `LSN` 的 durable progress 计量

Extent 负责：

- 稳定读镜像
- 长期存储
- checkpoint / base image 生成
- 长间隙恢复时作为真正 base image 的来源

第一条稳定性原则就是：

- 不要让当前 extent 冒充历史状态
- 不要让 WAL 永远承担所有长距离恢复责任

### 4.2 Primary-replica 同步模型

`V2` 理想中的 steady-state 同步模型是：

1. primary 分配单调递增的 `LSN`
2. primary 本地顺序追加 `WAL`
3. primary 把记录放入 per-replica sender loop
4. replica 按顺序接收并推进显式 progress
5. `barrier/sync` 依赖 replica 的 durable progress，而不是 optimistic send progress
6. flusher 再把 WAL-backed dirty state 物化到 extent

本地 `WAL -> extent` 生命周期可以理解为：

```mermaid
stateDiagram-v2
    [*] --> WalAppended
    WalAppended --> SenderQueued
    SenderQueued --> ReplicaReceived
    ReplicaReceived --> ReplicaDurable
    ReplicaDurable --> SyncEligible
    SyncEligible --> ExtentMaterialized
    ExtentMaterialized --> CheckpointAdvanced
```

这里最关键的规则是：

- **client 可见的 sync 真值必须跟随 durable replica progress**
- 不能跟随 send progress
- 不能跟随 local WAL head
- 不能跟随“看起来 replica 应该已经收到了”

这也是为什么 `V2` 使用像 `CommittedLSN` 这样的 lineage-safe 边界，而不是松散的“当前 primary head”。

### 4.2.1 不同 sync mode 如何判断结果

`V2` 让不同 sync mode 的成功条件变得更明确：

- `best_effort`：primary 达到本地 durability point 后即可成功，replica 可以后台恢复
- `sync_all`：所有 required replica 都要在目标边界上 durable
- `sync_quorum`：必须存在真实 durable quorum

其判断路径可以表示为：

```mermaid
flowchart TD
    writeReq[WriteAndSyncRequest]
    localDurable[PrimaryLocalDurable]
    barrierEval[EvaluateReplicaDurableProgress]
    bestEffortAck[best_effort成功]
    syncAllAck[sync_all成功]
    syncQuorumAck[sync_quorum成功]
    rejectOrBlock[阻塞或失败]

    writeReq --> localDurable
    localDurable --> bestEffortAck
    localDurable --> barrierEval

    barrierEval -->|"allRequiredReplicasDurable"| syncAllAck
    barrierEval -->|"durableQuorumExists"| syncQuorumAck
    barrierEval -->|"notEnoughDurableReplicas"| rejectOrBlock
```

这意味着 sync 结果不再依赖：

- socket 看起来还活着
- sender 好像还在发
- replica 似乎“差不多收到了”

而是依赖显式 durable progress。

### 4.3 为什么这个设计应该更稳定

它试图把最危险的模糊边界拆开：

- **写入顺序** 由 `WAL + LSN` 表达
- **durability truth** 由 barrier / flushed progress 表达
- **recovery ownership** 由 sender + recovery attempt identity 表达
- **catch-up vs rebuild** 由显式分类表达
- **promotion safety** 由 committed prefix 与 lineage 表达

也就是说，`V2` 的稳定性来自于减少隐式耦合。

### 4.4 为什么它仍然可以有高性能

这里不能夸大说 `V2` 一定在所有情况下都更快。

更准确的性能论点是：

- 保持 primary 前台写路径简单：
  - 本地顺序 `WAL append`
  - 投递到 per-replica sender loop
  - 不把复杂恢复逻辑塞进前台写路径
- 把复杂度主要放在健康热路径之外：
  - sender ownership
  - reconnect classification
  - catch-up / rebuild decision
  - timeout 和 stale-result fencing
  主要都在 recovery / control path
- 让 WAL 只承担它擅长的工作：
  - 近期 ordered delta
  - 短间隙 replay
- 不再让 WAL 承担所有长距离恢复：
  - 长间隙恢复转向 checkpoint/snapshot base + tail replay

所以 `V2` 的性能论点应该是：

- **健康 steady-state 应该尽量接近 `V1.5`**
- **退化与恢复路径会更干净**
- **短间隙恢复会比 rebuild 更便宜**
- **长间隙恢复不再逼迫系统支付无上限的 WAL retention 税**

这比“V2 天然更快”要可信得多。

### 4.5 为什么仍然选择 WAL

之所以还继续走 WAL，是因为它仍然是解决这个同步问题最有力的基础：

- 显式顺序
- 显式历史
- 显式 committed prefix
- 显式短间隙 replay
- 显式 failover reasoning

只有当设计把以下概念混淆时，WAL 才会变得危险：

- 本地写入接受
- replica durable progress
- committed boundary
- recoverable retained history

而 `V2` 的存在，正是为了不再混淆这些东西。

## 5. 与市场和论文路线的比较

选择 `V2` 这条路线，并不是因为别的 vendor 都错了，而是因为他们解决的是不同问题，也承担了不同复杂度。

### Ceph / RBD 路线

Ceph/RBD 避开了这种 per-volume replicated WAL 形态。

它获得的是：

- 对象存储深度一体化
- 成熟的 placement 与 recovery 体系
- 更强的集群级分布能力

但代价是：

- 系统层次更多
- object-store / peering 复杂度更重
- 运维与概念模型更重

所以这不是“更简单”，而是把复杂度迁移到了别处。

对 `sw-block` 而言，当前选择是：

- 保持更窄的软件块服务模型
- 用更显式的 per-volume correctness 来换取更可控的复杂度

### PolarFS / ParallelRaft 路线

这类系统探索更激进的顺序与并行策略：

- conflict-aware 或乱序并行
- 更深的日志并行
- 更复杂的 apply / replay 机制

它们在未来仍然值得借鉴：

- LBA conflict reasoning
- replay 成本与恢复成本
- flusher 并行优化

但它们也明显扩大了正确性边界。

在当前阶段，项目不应该在还没彻底证明严格顺序模型之前，就过早买入这类复杂度。

### AWS 链式复制 / EBS 类经验

链式复制之类的路线吸引人，是因为它们能解决真实问题：

- Primary NIC 压力
- forward 拓扑
- RF=3 时更好的扩展性

这是后续较有希望借鉴的方向。

但它会改变：

- 延迟画像
- 失败处理方式
- barrier 语义
- 运维拓扑

所以它属于更后面的架构阶段，而不是当前 V2 核心证明。

### 当前的真实选择

项目当前选择的是：

- 更窄的软件优先 block 设计
- 明确的 per-volume correctness
- 在性能英雄主义之前先把逻辑讲清
- 在功能扩张之前先建立验证闭环

这不是保守，而是为了让这个 block 产品未来真的值得信任。

## 6. 为什么这条方向适合 SeaweedFS 与未来独立 sw-block

`sw-block` 起步于 SeaweedFS，但 `V2` 已经在按下一代独立 block service 的方向成形。

这意味着架构上要同时保留两类东西：

### 需要保持兼容的部分

- placement / topology 这些概念
- 可解释的 control-plane contract
- 与 SeaweedFS 生态的运维连续性

### 应该更 block-specific 的部分

- replication correctness
- recovery ownership
- recoverability classification
- block 特有的 test / evidence 体系

因此当前方向不是“继续把 V2 当成 weed 里的一个 patch”，而是：

- 以 SeaweedFS 作为经验与生态基础
- 同时把 `V2` 逐步塑造成真正独立的块服务架构

## 7. 系统化验证方法

当前方向之所以合理，另一个重要原因是验证方法本身已经系统化。

项目不再依赖：

- 先实现
- 再观察
- 出 bug 再修

而是依赖如下层次：

- contract / invariants
- scenario backlog
- simulator
- timer/race simulator
- standalone prototype
- real engine test runner

```mermaid
flowchart TD
    contract[ContractAndInvariants]
    scenarios[ScenarioBacklog]
    distsim[distsim]
    eventsim[eventsim]
    prototype[enginev2Prototype]
    runner[RealTestRunner]
    confidence[SystemAndProductConfidence]

    contract --> scenarios
    scenarios --> distsim
    scenarios --> eventsim
    distsim --> prototype
    eventsim --> prototype
    prototype --> runner
    runner --> confidence
```

这对于一个高风险块存储算法是非常正确的结构：

- simulation 用来证明协议逻辑
- prototype 用来证明执行语义
- 真实 runner 用来证明系统与产品行为

## 8. Simulation 系统证明什么

simulation 系统的目标是回答：

- 应该发生什么
- 绝不能发生什么
- 为什么旧设计会失败
- 为什么 V2 更好

### `distsim`

`distsim` 是主协议仿真器，主要用于：

- 协议正确性
- 状态迁移
- stale authority fencing
- promotion / lineage safety
- catch-up vs rebuild
- changed-address restart
- candidate safety
- reference-state checking

### `eventsim`

`eventsim` 是时间 / race 层，主要用于：

- barrier timeout
- catch-up timeout
- reservation timeout
- 同 tick / 延迟事件顺序
- stale timeout 的影响

### simulation 擅长证明什么

它特别擅长证明：

- stale traffic rejection
- recovery boundary 的显式性
- timeout/race 语义
- committed prefix 下的 failover 正确性
- 旧 authority 不能修改新 lineage

### simulation 不证明什么

它不证明：

- 真实 TCP 行为
- 真实 OS 调度
- 磁盘时序
- 真正的 `WALShipper` 集成
- iSCSI / NVMe 前端的真实行为

因此 simulation 不是全部真相。

它是 **算法 / 协议真相层**。

## 9. 真实 test runner 证明什么

`learn/projects/sw-block/test/` 下的真实 test runner 是系统与产品验证层。

它不只是 QA 工具，而是设计是否可信的重要组成部分。

### 它覆盖什么

当前 runner 与周边测试体系已经覆盖：

- unit
- component
- integration
- distributed scenario
- 真实硬件 workflow

而且环境已经包含：

- 真实节点
- 真实 block target
- 真实 fault injection
- benchmark 与结果采集
- run bundle 与 scenario traceability

### 为什么它重要

它帮助我们判断：

- 实际引擎是否按设计运行
- 产品在真实 restart / failover / rejoin 场景下是否可靠
- operator workflow 是否可信
- benchmark 结果是不是有效而非偶然

所以 test runner 最好被理解为：

- implementation truth
- system truth
- product truth

而不只是“测试脚本框架”。

## 10. Simulation 与 test runner 如何系统性推进

理想的反馈闭环是：

1. `V1` / `V1.5` 出现真实故障
2. 这些故障被转化为设计要求
3. 再被提炼为 simulator 场景
4. simulator 关闭协议歧义
5. standalone prototype 关闭执行歧义
6. 真实 test runner 在硬件与分布式环境中验证系统行为
7. 新故障或新偏差再反哺设计

这就形成了两类互补真相：

- `simulation -> algorithm / protocol correctness`
- `test runner -> implementation / system / product correctness`

这种分层是健康的，因为它避免了两种常见错误：

- 只相信设计推导，却没有真实行为
- 只相信系统测试全绿，却没有真正理解协议本身

## 11. 当前状态与诚实边界

### 现在已经比较强的部分

- `V1.5` 相比 `V1` 的恢复能力已经明显增强，并且有真实运行证据
- `V2` 的架构清晰度已经明显强于 `V1.5`
- simulator 已经有较强的 acceptance 覆盖
- prototype 已经开始关闭 ownership 与 orchestration 风险
- 真实 test runner 已经足够大，可以支撑严肃的系统验证

### 现在还没有完成的部分

- `V2` 还不是生产引擎
- prototype 仍处于早中期
- historical-data / recovery-boundary prototype 还没有闭合
- `V2` steady-state 性能还没有真实证明
- `V2` 还没有真实硬件上的运行验证

所以最准确的话不是：

- “V2 现在已经在生产上更强”

而是：

- “V2 是长期更好的架构，但今天还不是更强的已部署引擎”

## 12. 为什么当前方向是理性的

当前方向之所以理性，是因为它保持了正确的分工：

- `V1.5` 继续作为今天的生产线
- `V2` 继续作为下一代架构线

这样项目就可以：

- 在已有可运行系统上继续交付和加固
- 在不扰动生产线的前提下认真验证更强的架构
- 用 simulation、prototype 和真实 runner 来决定 `V2` 是否真能成为下一代引擎

最终的战略规则应当保持不变：

- 继续研究 WAL，因为现在我们已经有可信的验证框架
- 继续推进 V2，因为架构证据已经很强
- 如果 prototype 证明 V2 有结构性缺陷，就先演进到 `V2.5`，不要急于重实现

## 结论

如果按当前生产证据选择：

- 选择 `V1.5`

如果按长期协议质量选择：

- 选择 `V2`

如果问 WAL 是否还值得继续研究：

- 值得，因为现在项目已经拥有了足够严肃的验证体系，可以负责任地继续推进

这就是当前最合理的技术与战略判断。