在研究圖片服務器問題時，瞭解到現在很多大公司基本上都是用分佈式文件系統來存儲海量小文件，比如Facebook有haystack，淘寶有TFS，京東有JFS。最近在研究TFS，結合之前學習的linux下的inode相關知識，瞭解到在ext文件系統中，對一個文件的讀需要先從磁盤中讀取到文件對應的Inode，然後根據inode獲取到對應的block的位置信息，進行第二次磁盤讀取目標文件的內容，這樣就需要兩次磁盤IO。在系統中會有inode緩存，這樣可保證一些文件讀取只需要一次磁盤IO。
在存儲向圖片這樣的小文件時，一般不超過1M，一些可能之後幾kb，這樣就會是海量文件，總佔用容量不大。linux在格式化磁盤時，會默認每1kB或2KB就分配一個inode，inode table 和 數據區分開存儲，一個磁盤的大小爲1GB，inode按128B算，inode佔的總大小爲128MB，這樣在比較大的硬盤中，inode數會更多，佔用的空間也會更大。inode可以放到cache中，加快文件讀，當文件的數量少時，需要加入到內存中的inode數量少，可以全部緩存到內存中，減少一次磁盤IO，可以提升讀取文件的性能，但是當是海量的小文件時，對應的inode數就比較多，幾乎無法全部加載到內存中，那麼文件的讀可能是隨機的，不在一個block中，那麼會有很多文件inode無法在緩存中命中，需要兩次磁盤IO，讀文件性能會比較低。
先在應對海量小文件的優化策略，一般都會包括把小文件進行合併存儲，比如Facebook開源的haystack和淘寶的TFS都採用了這樣的優化策略，通過合併文件減少inode的數量，也就是原數據的大小減小，達到基本上可以全部加載到內存中，可以實現一次磁盤IO就可以讀取到文件，大大提升讀取文件的性能，解決了海量小文件的讀取性能問題。
下邊是TFS的官方文檔，我就直接搬到這裏了：
簡介
TFS（Taobao !FileSystem）是一個高可擴展、高可用、高性能、面向互聯網服務的分佈式文件系統，主要針對海量的非結構化數據，它構築在普通的Linux機器集羣上，可爲外部提供高可靠和高併發的存儲訪問。TFS爲淘寶提供海量小文件存儲，通常文件大小不超過1M，滿足了淘寶對小文件存儲的需求，被廣泛地應用在淘寶各項應用中。它採用了HA架構和平滑擴容，保證了整個文件系統的可用性和擴展性。同時扁平化的數據組織結構，可將文件名映射到文件的物理地址，簡化了文件的訪問流程，一定程度上爲TFS提供了良好的讀寫性能。
TFS的總體結構
一個TFS集羣由兩個!NameServer節點（一主一備）和多個!DataServer節點組成。這些服務程序都是作爲一個用戶級的程序運行在普通Linux機器上的。
在TFS中，將大量的小文件(實際數據文件)合併成爲一個大文件，這個大文件稱爲塊(Block), 每個Block擁有在集羣內唯一的編號(Block Id), Block Id在!NameServer在創建Block的時候分配, !NameServer維護block與!DataServer的關係。Block中的實際數據都存儲在!DataServer上。而一臺!DataServer服務器一般會有多個獨立!DataServer進程存在，每個進程負責管理一個掛載點，這個掛載點一般是一個獨立磁盤上的文件目錄，以降低單個磁盤損壞帶來的影響。
!NameServer主要功能是: 管理維護Block和!DataServer相關信息,包括!DataServer加入，退出, 心跳信息, block和!DataServer的對應關係建立，解除。正常情況下，一個塊會在!DataServer上存在， 主!NameServer負責Block的創建，刪除，複製，均衡，整理， !NameServer不負責實際數據的讀寫，實際數據的讀寫由!DataServer完成。
!DataServer主要功能是: 負責實際數據的存儲和讀寫。
同時爲了考慮容災，!NameServer採用了HA結構，即兩臺機器互爲熱備，同時運行，一臺爲主，一臺爲備，主機綁定到對外vip，提供服務；當主機器宕機後，迅速將vip綁定至備份!NameServer，將其切換爲主機，對外提供服務。圖中的HeartAgent就完成了此功能。
TFS的塊大小可以通過配置項來決定，通常使用的塊大小爲64M。TFS的設計目標是海量小文件的存儲，所以每個塊中會存儲許多不同的小文件。!DataServer進程會給Block中的每個文件分配一個ID(File ID，該ID在每個Block中唯一)，並將每個文件在Block中的信息存放在和Block對應的Index文件中。這個Index文件一般都會全部load在內存，除非出現!DataServer服務器內存和集羣中所存放文件平均大小不匹配的情況。
另外，還可以部署一個對等的TFS集羣，作爲當前集羣的輔集羣。輔集羣不提供來自應用的寫入，只接受來自主集羣的寫入。當前主集羣的每個數據變更操作都會重放至輔集羣。輔集羣也可以提供對外的讀，並且在主集羣出現故障的時候，可以接管主集羣的工作。
平滑擴容
原有TFS集羣運行一定時間後，集羣容量不足，此時需要對TFS集羣擴容。由於DataServer與NameServer之間使用心跳機制通信，如果系統擴容，只需要將相應數量的新!DataServer服務器部署好應用程序後啓動即可。這些!DataServer服務器會向!NameServer進行心跳彙報。!NameServer會根據!DataServer容量的比率和!DataServer的負載決定新數據寫往哪臺!DataServer的服務器。根據寫入策略，容量較小，負載較輕的服務器新數據寫入的概率會比較高。同時，在集羣負載比較輕的時候，!NameServer會對!DataServer上的Block進行均衡，使所有!DataServer的容量儘早達到均衡。
進行均衡計劃時，首先計算每臺機器應擁有的blocks平均數量，然後將機器劃分爲兩堆，一堆是超過平均數量的，作爲移動源；一類是低於平均數量的，作爲移動目的。
移動目的的選擇：首先一個block的移動的源和目的，應該保持在同一網段內，也就是要與另外的block不同網段；另外，在作爲目的的一定機器內，優先選擇同機器的源到目的之間移動，也就是同臺!DataServer服務器中的不同!DataServer進程。
當有服務器故障或者下線退出時（單個集羣內的不同網段機器不能同時退出），不影響TFS的服務。此時!NameServer會檢測到備份數減少的Block，對這些Block重新進行數據複製。
在創建複製計劃時，一次要複製多個block, 每個block的複製源和目的都要儘可能的不同，並且保證每個block在不同的子網段內。因此採用輪換選擇(roundrobin)算法，並結合加權平均。
由於DataServer之間的通信是主要發生在數據寫入轉發的時候和數據複製的時候，集羣擴容基本沒有影響。假設一個Block爲64M，數量級爲1PB。那麼NameServer上會有 1 * 1024 * 1024 * 1024 / 64 = 16.7M個block。假設每個Block的元數據大小爲0.1K，則佔用內存不到2G。
存儲機制
在TFS中，將大量的小文件(實際用戶文件)合併成爲一個大文件，這個大文件稱爲塊(Block)。TFS以Block的方式組織文件的存儲。每一個Block在整個集羣內擁有唯一的編號，這個編號是由NameServer進行分配的，而DataServer上實際存儲了該Block。在!NameServer節點中存儲了所有的Block的信息，一個Block存儲於多個!DataServer中以保證數據的冗餘。對於數據讀寫請求，均先由!NameServer選擇合適的!DataServer節點返回給客戶端，再在對應的!DataServer節點上進行數據操作。!NameServer需要維護Block信息列表，以及Block與!DataServer之間的映射關係，其存儲的元數據結構如下：
在!DataServer節點上，在掛載目錄上會有很多物理塊，物理塊以文件的形式存在磁盤上，並在!DataServer部署前預先分配，以保證後續的訪問速度和減少碎片產生。爲了滿足這個特性，!DataServer現一般在EXT4文件系統上運行。物理塊分爲主塊和擴展塊，一般主塊的大小會遠大於擴展塊，使用擴展塊是爲了滿足文件更新操作時文件大小的變化。每個Block在文件系統上以“主塊+擴展塊”的方式存儲。每一個Block可能對應於多個物理塊，其中包括一個主塊，多個擴展塊。
在DataServer端，每個Block可能會有多個實際的物理文件組成：一個主Physical Block文件，N個擴展Physical Block文件和一個與該Block對應的索引文件。Block中的每個小文件會用一個block內唯一的fileid來標識。!DataServer會在啓動的時候把自身所擁有的Block和對應的Index加載進來。
容錯機制
- 集羣容錯
TFS可以配置主輔集羣，一般主輔集羣會存放在兩個不同的機房。主集羣提供所有功能，輔集羣只提供讀。主集羣會把所有操作重放到輔集羣。這樣既提供了負載均衡，又可以在主集羣機房出現異常的情況不會中斷服務或者丟失數據。
- !NameServer容錯
Namserver主要管理了!DataServer和Block之間的關係。如每個!DataServer擁有哪些Block，每個Block存放在哪些!DataServer上等。同時，!NameServer採用了HA結構，一主一備，主NameServer上的操作會重放至備NameServer。如果主NameServer出現問題，可以實時切換到備NameServer。
另外!NameServer和!DataServer之間也會有定時的heartbeat，!DataServer會把自己擁有的Block發送給!NameServer。!NameServer會根據這些信息重建!DataServer和Block的關係。
- !DataServer容錯
TFS採用Block存儲多份的方式來實現!DataServer的容錯。每一個Block會在TFS中存在多份，一般爲3份，並且分佈在不同網段的不同!DataServer上。對於每一個寫入請求，必須在所有的Block寫入成功纔算成功。當出現磁盤損壞!DataServer宕機的時候，TFS啓動複製流程，把備份數未達到最小備份數的Block儘快複製到其他DataServer上去。 TFS對每一個文件會記錄校驗crc，當客戶端發現crc和文件內容不匹配時，會自動切換到一個好的block上讀取。此後客戶端將會實現自動修復單個文件損壞的情況。
併發機制
對於同一個文件來說，多個用戶可以併發讀。
現有TFS並不支持併發寫一個文件。一個文件只會有一個用戶在寫。這在TFS的設計裏面對應着是一個block同時只能有一個寫或者更新操作。
TFS文件名的結構
TFS的文件名由塊號和文件號通過某種對應關係組成，最大長度爲18字節。文件名固定以T開始，第二字節爲該集羣的編號(可以在配置項中指定，取值範圍 1~9)。餘下的字節由Block ID和File ID通過一定的編碼方式得到。文件名由客戶端程序進行編碼和解碼，它映射方式如下圖：
TFS客戶程序在讀文件的時候通過將文件名轉換爲BlockID和FileID信息，然後可以在!NameServer取得該塊所在!DataServer信息（如果客戶端有該Block與!DataServere的緩存，則直接從緩存中取），然後與!DataServer進行讀取操作。
TFS性能數據
- 軟件環境描述
【測試機軟件情況描述】
(1) Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
(2) gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11)
(3) 部署了TFS客戶端程序
【服務器軟件情況描述】
(1) Red Hat Enterprise Linux Server release 5.4 (Tikanga)
(2) gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9)
(3) 部署了2臺!DataServer程序。
【服務器軟件情況描述】
(1) Red Hat Enterprise Linux Server release 5.4 (Tikanga)
(2) gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
(3) 部署了2臺!NameServer（HA）程序。
- 硬件環境描述
【測試機硬件情況描述】
(1) 一枚八核Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
(2) 內存總數8299424 kB
【服務器硬件情況描述】cpu/memory等
(1) 一枚八核Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
(2) 內存總數8165616 kB
- 隨機讀取1K~50K大小的文件性能
Read的TPS隨着線程數的增加而增加，增長逐漸趨緩，到90線程的時候達到第一個高峯，此時再增加讀線程，則TPS不再穩定增長。
- 隨機寫入1K~50K大小的文件
Write的TPS在線程數60左右達到高峯，此時再增加寫入線程，TPS不再穩定增長。
- 在不同線程寫壓力下的讀文件性能
可以看出隨着寫壓力的增加，讀文件的TPS會大幅下滑。當寫壓力達到一定程度時讀文件TPS趨緩。
同時，對平均大小爲20K的文件進行了測試，測試中讀:寫：更新:刪除操作的比率爲100：18：1：1時，在!DataServer服務器磁盤util訪問達到80%以上時，響應時間如下：
| TYPE | SUCCCOUNT | FAILCOUNT | AVG(us) | MIN(us) | MAX(us) |
| read | 100000 | 0 | 20886 | 925 | 1170418 |
| write | 18000 | 0 | 17192 | 2495 | 1660686 |
| update | 1000 | 0 | 48489 | 5755 | 1205119 |
| delete | 1000 | 0 | 14221 | 382 | 591651 |
TYPE：操作類型
SUCCCOUNT：成功個數
FAILCOUNT：失敗個數
AVG：平均響應時間
MIN：最短響應時間
MAX: 最大響應時間