FastCFS性能碾压Ceph之技术揭秘

happy_fish100

[color=rgb(38, 38, 3]    FastCFS刚发布了版本2.2.0，IOPS全面超越Ceph：顺序写是Ceph的6.x倍，顺序读是Ceph的2.x倍，随机写大约是Ceph的2倍。具体的性能测试数据参见：https://gitee.com/fastdfs100/Fas ... r/docs/benchmark.md。相信有很多朋友会好奇FastCFS是如何做到的，接下来将为你揭晓FastCFS IOPS完胜Ceph的秘诀。

[color=rgb(38, 38, 3]​

[color=rgb(38, 38, 3]    我不打算探讨架构和实现细节上的差异，直接为大家揭晓有效提升IOPS的关键做法。

[color=rgb(38, 38, 3]

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

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

[color=rgb(38, 38, 3]    接下来说一下读性能。在v2.2.0之前，FastCFS采用传统的同步模型，随机读性能比Ceph略差。v2.2.0采用基于Linux libaio的异步模型，随机读性能有所提升，性能比Ceph略强。使用libaio异步模型的两大优势：1. CPU占用较低，一个异步读线程处理能力约等于8~16个同步读线程；2. 随机读IOPS更好。其代价是实现门框较高，需要使用Direct IO，read buffer、文件偏移量和读取字节数都需要按设备块大小对齐（注：块设备大小通常为512字节，而不是4KB）。

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

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

[color=rgb(38, 38, 3]    更详细的对比测试报告，参见文档：https://gitee.com/fastdfs100/Fas ... chmark-20210621.pdf，希望有条件的朋友也做一下性能测试。

    在测试和使用过程中，有任何问题，请及时反馈，我们随时准备着与你交流。友情提示，gitee官网可以找到我们的联系方式：https://gitee.com/fastdfs100/FastCFS。