YashanDB ｜自研 YFS，为共享集群打造专属“高性能存储引擎”

在构建 YashanDB 共享集群的过程中，我们面临一个关键抉择：底层存储服务到底是选择通用现成方案，还是自研一套更贴合需求的组件?

经过多轮实测、权衡和落地实践，我们选择了“自研 YFS 文件系统”这条更具挑战但更具潜力的道路。本文就来讲讲我们为何这么做，又具体做了哪些“重工”来支撑共享集群的存储性能与高可用。

为什么要自研共享存储系统？

在共享集群中，多节点需要同时读写同一存储资源，这对底层存储提出了更高的要求：

要求节点之间访问一致、数据正确;

要求能绕过操作系统缓存，充分利用集群整体内存;

要求具备极高的 IO 并发能力;

更要在任何故障场景下，保证数据安全与服务可用。

市面上的传统文件系统，比如 Ext3/4.并不支持共享存储;而 GFS、NFS 等通用方案又存在性能瓶颈、通信开销大、DB 场景适配性不足等问题。面对核心交易级的稳定性和性能要求，我们最终决定自研 YFS(Yashan File System)组件，直接面向裸设备，实现更精细的存储调度和管理能力。

YFS 设计思路：用户态、灵活、稳定

YFS 被设计为一个运行在用户态的存储服务进程，具备以下优势：

出错不拖系统：用户态进程出现异常不会影响操作系统稳定性;

不依赖内核版本：更易在复杂环境部署;

开发调试灵活：支持丰富库调用，易于迭代和维护;

简化服务逻辑：可针对 YashanDB 场景做深度优化。

YFS 在逻辑上管理元数据与磁盘空间，在物理结构上通过 block、AU、Extent 三层架构，实现 PB 级别的单盘支持，同时提升数据连续性与读取效率。

高可用机制，全链路保障数据安全

YFS 从设计之初就承载了部分数据库高可用能力，其核心在于：

1.支持多副本机制与快速副本切换;

2.使用内部 Redo 系统保障元数据的原子性与一致性;

3.引入“故障组”概念，感知磁盘间故障关联性，科学分布冗余数据;

4.具备灾备级别的“快速恢复区”，在元数据损坏时自动还原;

5.提供磁盘组隔离机制，单磁盘组故障不影响整体系统运行。

这一套机制，让 YFS 在面对节点异常、硬盘损坏、链路中断等极端情况下，依然能保障数据库业务不中断、数据不丢失。

IO 性能，最大化释放集群优势

为了追求极致性能，YFS 在多方面做了深度优化：

直接管理裸设备，减少中间层开销;

支持 AU 级条带化，IO 自动分发至多磁盘并行;

IO 操作中不引入额外通信，各节点独立执行，扩展性极强;

可定制 AU size，匹配顺序/随机读写场景，性能可调优;

搭配 YashanDB 聚合内存机制，减少磁盘读写次数。

这使得 YFS 成为支撑 YashanDB 多项性能测试“夺冠”的关键幕后角色。

架构与技术细节亮点

支持 500PB 单文件容量;

二级索引 + 阶梯式变长 Extent 机制，提升大文件管理能力;

元数据与用户数据统一为“文件”，统一冗余策略、扩展能力强;

全套管理逻辑内置 Redo、版本号、事务控制，增强元数据安全;

提供标准 open/read/write 接口，开发者无需学习新模型。

此外，YFS 还配备专用管理客户端，兼容常见 Linux Shell 操作，方便管理员日常维护。

最后总结

YFS 不是对传统文件系统的“简单包装”，而是从底层重新出发，为共享集群量身打造的一套高性能、高可用、高扩展性的文件服务组件。正是有了它，YashanDB 才能在集群场景下跑出不输传统分布式架构的性能与稳定性。

未来，YFS 将持续演进，适配更多应用场景，支持更丰富的存储形态，成为 YashanDB 全生态架构中的坚实支撑。