3.2 WAL：评估 Value Log 先 fsync 再 WAL fsync 对写吞吐的影响 #3

New Issue

dailz · 2026-06-09T10:31:52+08:00

dailz commented

2026-06-09 10:31:52 +08:00

背景

第 3.2 和 3.9 节要求 Always 策略下，如果 WAL Entry 引用 Value Log record，发布 WAL Batch 前被引用对象也必须已持久化。大值写入流程是先 append + fsync Value Log record，再写入并 fsync WAL Batch。

问题

该顺序能避免恢复后出现悬空 Value Log pointer，但大 value 写入会引入至少两次 fsync：

Value Log record fsync
WAL Batch fsync

这与项目“写吞吐极致”的核心目标存在潜在冲突。

风险

在大 value 或混合负载下，默认 Always 策略可能因双 fsync 显著降低写吞吐，并削弱 group commit 的收益。

建议

在设计文档中明确这是有意取舍，或评估替代方案：

明确写入语义优先级：Always 下优先保证无悬空指针
说明大值写入吞吐主要通过 group commit / 非 Always 策略弥补
评估是否需要 Value Log group commit
评估统一 durable barrier 或 WAL 承载大值数据的替代方案

参考

docs/design.md:130 WAL Entry 引用外部持久化对象的发布要求
docs/design.md:746 Value Log 写入流程
docs/design.md:760 Value Log 与 WAL 的崩溃一致性

## 背景第 3.2 和 3.9 节要求 `Always` 策略下，如果 WAL Entry 引用 Value Log record，发布 WAL Batch 前被引用对象也必须已持久化。大值写入流程是先 append + fsync Value Log record，再写入并 fsync WAL Batch。 ## 问题该顺序能避免恢复后出现悬空 Value Log pointer，但大 value 写入会引入至少两次 fsync： 1. Value Log record fsync 2. WAL Batch fsync 这与项目“写吞吐极致”的核心目标存在潜在冲突。 ## 风险在大 value 或混合负载下，默认 `Always` 策略可能因双 fsync 显著降低写吞吐，并削弱 group commit 的收益。 ## 建议在设计文档中明确这是有意取舍，或评估替代方案： - 明确写入语义优先级：`Always` 下优先保证无悬空指针 - 说明大值写入吞吐主要通过 group commit / 非 Always 策略弥补 - 评估是否需要 Value Log group commit - 评估统一 durable barrier 或 WAL 承载大值数据的替代方案 ## 参考 - `docs/design.md:130` WAL Entry 引用外部持久化对象的发布要求 - `docs/design.md:746` Value Log 写入流程 - `docs/design.md:760` Value Log 与 WAL 的崩溃一致性

dailz closed this issue

2026-06-09 11:39:14 +08:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dailz/go-kv#3