Curve文件系统元数据持久化方案设计

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/opencurve

摘要

文档详细阐述了Curve文件系统的元数据持久化方案设计，包括Raft Log和Raft Snapshot的持久化机制。Raft Log记录操作日志，包含类型、键值对及校验和等字段；Raft Snapshot将内存数据结构 dump 至文件，包含 CURVEFS 标识、版本号、键值对数量等部分。持久化文件采用小端序存储，利用 fork 子进程解决读写冲突。文档还探讨了Redis在持久化中的应用及其局限性，包括AOF和RDB的不足，以及 Redis Cluster与主从复制的高可用方案。最后提出了基于 multiraft 的持久化实现，并对 kodevs 和 Redis 的改造进行了权衡分析。

AI总结

《Curve文件系统元数据持久化方案设计》文档总结如下：

1. **持久化方案背景与需求**
- 元数据节点架构涉及两部分持久化内容：
- **Raft Log**: 记录操作日志（Op Log），包括SET和DEL两种操作类型。
- **Raft Snapshot**: 将内存数据结构以特定格式持久化为文件，用于快照备份。
- 持久化文件格式包括magic number、版本号、键值对数量、 EOF标记和校验和等字段，确保数据完整性和兼容性。

2. **Raft Log设计**
-每个日志条目包含操作类型、键长度、键值对及校验和，支持SET和DEL操作。
-DEL操作时，value字段为空，仅记录键信息。
-所有数字字段均采用小端序存储。

3. **Raft Snapshot设计**
- 快照文件格式包含 CURVEFS魔数、版本号、键值对数量、EOF标记和校验和。
- 键值对字段由键长度、键、值长度和值组成，值支持可选。
- 持久化过程中使用fork子进程（COW）解决读写冲突问题。

4. **实现与优化**
- **序列化实现**：
- 采用顺序编码或protobuf序列化，优先选择顺序编码以减少存储空间。
-针对inode和entry增加编码函数，确保高效存储。
- **KVStore实现**：
- 提供SET、GET、DELETE和SAVE接口，支持Raft快照功能。
-采用map存储键值对，支持WAL（Write-Ahead Logging）机制，文件路径为curvefs.wal和curvefs.dump。

5. **技术选型与对比**
- 单独使用Redis的持久化机制（AOF/RDB）无法保证数据100%不丢失，且不满足元数据持久化的需求。
- Redis的高可用和高扩展方案可通过 Redis Cluster + 主从复制或第三方工具（如Codis + 哨兵）实现，主要解决扩展性和可用性问题。
- Redis + MultiRaft方案存在问题，如每个Raft实例需要独立快照，而 Redis目前不支持单独持久化特定DB或数据结构。
- 对比后决定不改造Redis，而选择自行实现持久化逻辑，主要因为：
- Redis改造工作量较大，且需要动多个模块（如主从复制）。
- 自行实现更符合MultiRaft场景下的独立快照需求。

6. **总结**
- 本文设计了一套针对Curve文件系统元数据的持久化方案，通过Raft Log和Snapshot双重机制保证数据持久性和可靠性。
-方案采用小端序存储和顺序编码优化空间占用，通过KVStore接口实现键值对管理，并结合fork子进程解决读写冲突问题。
-最终决定自行实现持久化逻辑，以满足MultiRaft场景下的独立快照需求，避免Redis改造的高复杂性和耦合问题。