可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 netease.com/team/km_curve/article/27909 性能对比 并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 prefix + parentid + filename 作为 key , filename 直接和 fileInfo

软件生命周期内更好地为用户服务：  质量——向用户交付稳定可靠的软件；  监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ 测试方法论（单元测试、集成测试、系统测试） 监控 ✓ 监控架构 ✓ 指标采集、后端处理、可视化展示 运维 ✓ 运维特性 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动小）将实现思路记录到任务管理系统中（JIRA），即可进行开发；  大需求（新模块 大需求（新模块、复杂功能）需要输出独立设计文档，并进行评审；对于功能或 性能影响较大的功能，还需要进行POC验证；评审和验证通过后才能启动开发 工作。 小需求 实现思路 开发 大需求 设计文档 POC 开发 7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍  相关调研  架构  重要流程  关键算法  接口  数据库设计  非功能特性设计

• 大多数副本写完成返回客户端 • 延迟取决于所有副本中最快的大多数主要亮点 高性能 更稳定 跟各 更稳定 具备可视化的开发页面， 直观查看任务运行情况， 数据开发方便，系统运 维方便 易运维 具备可视化的开发页面， 直观查看任务运行情况， 数据开发方便，系统运 维方便 高质量 基于在架构上的选择和优秀的工程实践，Curve 在性能、运维、稳定性、工程实践质量上都优于Ceph主要亮点 为核心业务提供稳定的存储服务，单集群存数万个卷，储容量PB级别  网易集团内部业务： • 网易严选，网易云音乐 网易有道，网易游戏 网易Lofter，云信 在集团外有联合开发用户和测试用户  网易外部用户： • 超聚变，创云融达信息技术 • 扬州万方电子技术，思谋科技分布式存储介绍 01 存储的发展 | 分布式存储的分类 | 分布式存储的要素 02 03

curve在上物理pool之上又引入逻辑pool的概念，以实现统一存储系统的需求，即在单个存储系统中多副 本PageFile支持块设备、三副本AppendFile（待开发）支持在线对象存储、AppendECFile（待开发）支持 近线对象存储可以共存。 如上所示LogicalPool与pool为多对一的关系，一个物理pool可以存放各种类型的file。当然由于curve支持 多个poo 多个pool，可以选择一个logicalPool独享一个pool。 通过结合curve的用户系统，LogicalPool可以通过配置限定特定user使用的方式，实现多个租户数据物理 隔离（待开发）。TOPOLOGY Topology的实际例子，右侧是topo配置文件： 集群有一个物理pool，由3个zone组成，每个zone有1台server。 在物理pool上，还创建了一个逻辑pool，逻辑pool使用3个zone，采用

• 云起实验室 接入云端销售 数据价值放大 • 基础设施 • 安全 • 管理维护 • 数据集成 • 开发协同 • ISV • 培训育人 • 商业服务 • ... 2022S1: 3500W曝光 150W学习人次 2万+实践体验 2K+持证人才 PolarDB开发大赛: 230+参赛选手 21K+ 社区用户 • 全面开源 • 兼容PG&MySQL • 透明分布式 •

dentry manager：负责管理元数据的内存结构 heartbeat：定期获取copyset的信息 模块 估算工作量（开发 + ci完成） client 10d mds 15d metaserver 10d 考虑到partition和copyset的多对一关系会带来开发商的复杂性，是否考虑先只实现partition和copyset一对一的情况。等下一个版本，再实现的多对一的场景。 接口设计：https://github

可能会出现边删除边整理的状态(出现概率较小) 可以在实际删除前检查当前整理的inode列表, 如果在列表里就暂时跳过(同步删除)/重新丢进删除队列(异步删除) 或者就不管, 处理一下报错, 让后续的应该会开发的数据清理工具来删除, 因为出现这个冲突的概率比较小 truncate: 只进行元数据里len的改变, 触发一下compact就行, shrink的部分compact会进行处理

对多个socket connection，在单线程里做event loop多路复用。 • 多个target时，如果挂的设备多，一旦客户端请求量大，就会忙不过来。 • 开源界有尝试修改 • 例如sheepdog的开发者提交过一个patch，但是测试效果不理想，分析 原因，event loop依然是瓶颈对TGT的性能优化 • IO是使用多个epoll 线程，充分发挥多CPU能力 • 当前策略是每个target

《PostgreSQL修炼之道：从小工到专家》的作者，中 启乘数科技联合创始人，PostgreSQL中国用户会常委。 从业近20年，拥有20年数据库、操作系统、存储领 域的工作经验，历任过阿里巴巴高级数据库专家、 网易研究院开发专家，从事过阿里巴巴Greenplum、 PostgreSQL、 MySQL数据库的架构设计和运维。 既熟悉数据库的，是最早的Oracle 9i的OCP，又懂开 发，精通C、python。 唐成（网名osdba）-3-

02 03 04 总体设计 系统特性 近期规划• 性能优化 • 满足数据库性能要求 • 大io吞吐优化 • muti raft 性能优化 • 开源 • 系列技术分享 • 参与开发人员线上议题讨论会 近期规划欢 迎 大 家 参 与 C U R V E 项 目 ！ • github主页： https://opencurve.github.io/ • github代码仓库：