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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。