FastCFS性能碾压Ceph之技术揭晓

FastCFS性能碾压Ceph之技术揭秘

本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。

FastCFS 已发布了版本 2.2.0，IOPS 全面超越 Ceph：顺序写是Ceph 的 6.x 倍，顺序读是 Ceph 的 2.x 倍，随机写大约是 Ceph 的 2 倍。

具体的性能测试数据参见：https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark.md

相信有很多朋友会好奇 FastCFS 是如何做到的，接下来将为你揭晓 FastCFS IOPS 完胜 Ceph 的秘诀。

我不打算探讨架构和实现细节上的差异，直接为大家揭晓有效提升 IOPS 的关键做法。

FastCFS 基于 trunk 文件（默认大小为 256MB）存储数据，在一个trunk 文件内采用顺序写方式。顺序写可以做到数据批量落盘，能够有效解决写放大问题，决定了 FastCFS 的写入性能相比传统的落盘方式有着明显优势，这就解释了 FastCFS 的随机写大约是 Ceph 的 2 倍。

为啥 FastCFS 顺序写可以秒杀 Ceph 呢？

除了 FastCFS 服务端特有的顺序写机制外，还有一个关键因素是 FastCFS 客户端默认开启合并写特性。分布式存储系统核心性能指标是 IOPS，受制于另外两个IO 能力：磁盘IO 和 网络IO。合并写可以大大提升 网络IO 效率，有效消除 网络IO 瓶颈。

接下来说一下 读性能。

在 v2.2.0 之前，FastCFS 采用传统的同步模型，随机读性能比 Ceph 略差。v2.2.0 采用基于 Linux libaio 的异步模型，随机读性能有所提升，性能比 Ceph 略强。

使用 libaio 异步模型的两大优势：

1. CPU 占用较低，一个 异步读线程 处理能力约等于 8~16 个 同步读线程；
2. 随机读 IOPS 更好。其代价是实现门槛较高，需要使用 Direct IO，read buffer、文件偏移量 和 读取字节数 都需要按设备块大小对齐（注：块设备大小通常为 512 字节，而不是 4 KB）。

read 使用 异步IO（Direct IO）后，Linux 内核不再缓存读出来的文件内容，需要自己实现预读机制。为了提升顺序读效率，FastCFS 借鉴了 Linux 内核的预读策略，在客户端实现了简洁高效的预读机制。

对于非多节点共享数据（即单节点专享数据）的场景，FastCFS 精心设计和实现的合并写和预读机制不存在数据一致性（比如读到脏数据）问题，故此这两个特性默认是开启的。

更详细的对比测试报告，参见文档【希望有条件的朋友也做一下性能测试】：
https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark-20210621.pdf

在测试和使用过程中，有任何问题，请及时反馈，我们随时准备着与你交流。

友情提示，gitee官网 可以找到我们的联系方式：
https://gitee.com/fastdfs100/FastCFS。