FastCFS性能碾压Ceph之技术揭秘

    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字节，而不是4KB）。

    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。

本文分享自微信公众号 - FastDFS分享与交流（fastdfs100）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。