4. 本地持久化方案：文件系统、数据库、键值存储的选型与权衡

4.1 边界定义

本地持久化层位于 Bundle状态机 与 物理存储介质 之间，负责将内存中的会话快照、增量变更日志、元数据索引写入非易失性存储。该层的上边界接收来自状态机的序列化字节流；下边界对接操作系统文件 I/O 或嵌入式数据库引擎。其核心职责是保证数据在进程崩溃或设备断电后不丢失，并在恢复阶段提供高效的随机读取与范围扫描能力。

4.2 分层与组件职责

本地持久化方案可拆解为三层：序列化适配层、存储引擎层、文件管理层。

4.3 数据流 / 控制流 / 信任链路

• 写放大路径： 状态机 → 序列化适配 → 存储引擎 → 文件同步（fsync / flush）→ 磁盘。
• 读恢复路径： 加载快照文件 → 反序列化 → 重放增量日志 → 重建最新 Bundle 状态。
• 信任链路： 只有 存储引擎的写入确认 才视为持久化成功；应用层不可跳过 fsync 或事务提交来换取性能。

4.4 选型权衡

三种方案的取舍可归纳为 性能 / 一致性 / 易用性 三角。以下对比基于 Bundle 会话恢复场景，状态大小通常在 1KB ~ 100MB 之间，读写比为 1:3。

4.5 落地步骤

1. 评估规模：统计 Bundle 数量、平均大小、写入峰值 QPS、恢复时间目标（RTO）。
2. 原型对比：在目标硬件上用相同负载对文件（mmap+fsync）、SQLite、RocksDB 压测，记录 P99 延迟与磁盘带宽。
3. 选定引擎：根据上一步数据匹配 4.4 选型权衡 中的适用场景。
4. 定义序列化契约：编写 BundleFormat 头结构，包含魔数、版本、校验和、快照/增量标记。
5. 实现存储适配器：封装统一接口 LocalStore，下层可切换实现而无需修改状态机。
6. 集成恢复流程：启动时检测本地缓存中的最新快照，按时间戳重放所有增量日志。
7. 添加监控：暴露磁盘 I/O 速率、WAL 大小、Compaction 延迟等指标。

// 统一存储适配器接口示例（Go 伪代码）
type LocalStore interface {
    SaveSnapshot(ctx context.Context, bundleID string, data []byte) error
    LoadSnapshot(ctx context.Context, bundleID string) ([]byte, error)
    AppendDelta(ctx context.Context, bundleID string, delta []byte) error
    ScanDeltas(ctx context.Context, bundleID string, since time.Time) ([][]byte, error)
    Compact(ctx context.Context, bundleID string) error
}

4.6 验收标准