FastDFS原理系列文章

基於FastDFS 5.03/5.04

2014-12-19

一、概述

FastDFS文檔極少，僅僅能找到一些寬泛的架構文檔，以及ChinaUnix論壇上作者對網友提問的一些回答。對於要將FastDFS應用到生產系統來說，這點了解絕對是不夠的。

這段時間研究FastDFS源代碼，而且做了大量的性能測試。中間也做了大量的筆記。基本上把程序的結構與基本的操作摸索清楚，因此寫了一些文章即是對前段工作的總結，同一時候也分享給想很多其它了解FastDFS內部的同行們。

這裏對每篇文章做個介紹。

1、機器之間的同步

《FastDFS之Binlog同步》 http://blog.csdn.net/hfty290/article/details/42041155

2、加入新機器同步

大家可能不怎麽會註意到這部分。可是事實上非常重要。

在實際的生產系統。壞掉一臺機器，或者為了讀壓力而添加機器，等都是非常正常的。在一個執行的系統上加入一臺機器涉及到存量文件的同步與融入到系統中。以下這篇文章做了具體的回答。

《FastDFS之加入機器同步》 http://blog.csdn.net/hfty290/article/details/42041953

3、磁盤恢復

線上機器壞個磁盤算是個大概率事件了，換了一個新磁盤。問題來了，數據怎麽恢復啊。不用急，重新啟動下Storaged。他會檢測到並進行恢復，盡管恢復時間可能要非常長（數據量大時），這篇文章對這個功能做了說明。

《FastDFS之磁盤恢復過程》 http://blog.csdn.net/hfty290/article/details/42032817

4、Storaged程序結構

到此處Storaged基本的功能點已經講述了。或者你還想知道程序內部是怎樣組織的，線程之間的協調等信息，請看這篇文章。

《FastDFS之Storage程序框架》 http://blog.csdn.net/hfty290/article/details/42048001

5、Client與Tracker的通訊

如今是時候從client角度來端詳下Tracker了。由於無論是上傳、下載、刪除等操作都須要先查詢Tracker。那麽這些查詢Tracker是怎樣計算。並返回的呢？請看本篇。

《FastDFS之client與Tracker通訊》http://blog.csdn.net/hfty290/article/details/42064429

6、合並存儲

海量小文件導致性能下降，可能大家都聽說過。福音是FastDFS通過合並小文件成大文件的方式來規避這個問題。FastDFS是怎樣實現這個功能的，具體請看這裏。

《FastDFS合並存儲原理分析》 http://blog.csdn.net/hfty290/article/details/42026215

7、Tracker-Leader選舉

看過了《FastDFS合並存儲原理分析》這篇文章後。對於當中提到的Tracker-Leader怎樣選舉可能會好奇，通過這篇文章你會看到Leader的選舉過程。

《FastDFS之Tracker-Leader選擇》 http://blog.csdn.net/hfty290/article/details/42030339

8、合並存儲設計缺陷

對於FastDFS合並存儲功能不得不面對一個問題，在某些情況下會導致數據錯誤或丟失。

你在看《FastDFS合並存儲原理分析》這篇文章時可能已經發現了，如今讓我們完完整整地重現下這樣的錯誤的出現，請看。

《FastDFS之合並存儲缺陷導致數據丟失或錯誤》 http://blog.csdn.net/hfty290/article/details/42030481

FastDFS原理系列文章