前語

今天給咱們介紹的是FastDFS，一個(gè)開源的分布式文件體系，也是入職之后觸摸到的一個(gè)技能，因?yàn)楣卷?xiàng)目事務(wù)需求，服務(wù)器里存了上億量級的文件，所以運(yùn)用了這么一項(xiàng)技能來存儲(chǔ)這些文件，我也就隨之開端了解這項(xiàng)技能，并且在這兒和咱們一同從0到1地開端了解它。

FastDFS介紹

FastDFS是一個(gè)以C言語開發(fā)的開源輕量級分布式文件體系，由阿里巴巴開發(fā)并開源。它對文件進(jìn)行辦理，功用包含：文件存儲(chǔ)、文件同步、文件拜訪（上傳、下載）等。處理了大容量存儲(chǔ)和負(fù)載均衡的問題。特別合適以文件為載體的在線服務(wù)，如相冊網(wǎng)站、視頻網(wǎng)站等等。

FastDFS為互聯(lián)網(wǎng)量身定制，充分考慮了冗余備份、負(fù)載均衡、線性擴(kuò)容等機(jī)制，并注重高可用、高性能等目標(biāo)，運(yùn)用FastDFS很容易建立一套高性能的文件服務(wù)器集群供給文件上傳、下載等服務(wù)。

從0，自己的一些疑問：FastDFS過期了嗎？

信任這也是許多同學(xué)想要問的一些問題，我還沒有了解這個(gè)技能的時(shí)分，也相同有這樣的疑問。

首要，現(xiàn)在有許多文件存儲(chǔ)都會(huì)挑選像七牛云、阿里云OSS等云服務(wù)，為什么要自己搭一套文件服務(wù)器添加維護(hù)本錢呢？

其次，這并不是面試的熱點(diǎn)，乃至在入職之前自己都沒有觸摸過，乃至乃至，沒有聽說過，反倒是那些搶手的技能，就算自己不主動(dòng)去了解，當(dāng)遇到的時(shí)分，大致也能知道是用來干嘛的。

那么我來說說我的理解，首要這個(gè)技能一定是還沒有過期的，因?yàn)橛行┨貏e的文件，因?yàn)樾畔踩櫦傻仍?，不?huì)挑選公有云服務(wù)器，還有依據(jù)本錢考慮，還有許多的中型互聯(lián)網(wǎng)公司仍然是依據(jù)FastDFS來做自己的文件服務(wù)器的。別的，F(xiàn)astDFS作為一個(gè)分布式服務(wù)器，對輕量級、橫向擴(kuò)展、容災(zāi)備份、高可用、高性能、負(fù)載均衡都有著充分的考慮，依舊是一個(gè)文件服務(wù)器的不貳之選。

那么為什么這樣一項(xiàng)技能在現(xiàn)在卻很少有人了解呢？

榜首，我以為是需求所致，與其它事務(wù)相比，需求存儲(chǔ)許多文件的事務(wù)相對之下仍是比較少。假如文件存儲(chǔ)量不大，依照傳統(tǒng)的文件存儲(chǔ)方法也不會(huì)有什么大的問題。

第二，現(xiàn)在有七牛云、阿里云OSS等公司供給對象存儲(chǔ)，加之國內(nèi)關(guān)于”上云“的追捧，就很少有人樂意自己搭服務(wù)器來做文件存儲(chǔ)服務(wù)了。

當(dāng)然關(guān)于一個(gè)技能人來說，各式各樣的技能都得去學(xué)習(xí)，去適應(yīng)，所以這篇文章期望能夠協(xié)助到感興趣的同學(xué)，或是在作業(yè)中遇到高量級文件存儲(chǔ)的同學(xué)，F(xiàn)astDFS是不錯(cuò)的挑選。

傳統(tǒng)文件存儲(chǔ)方法

這是傳統(tǒng)文件存儲(chǔ)的方法，服務(wù)器上乃至不需求裝任何的應(yīng)用，只需求有SFTP服務(wù)，咱們就能夠?qū)憣?yīng)的代碼，完結(jié)文件的CRUD。

這樣的優(yōu)點(diǎn)便是很便利，只需求一臺(tái)機(jī)器，幾行代碼就能搞定文件的存儲(chǔ)，可是這種方法的瓶頸和缺點(diǎn)是很明顯的。

首要，關(guān)于單體服務(wù)器來說，不考慮宕機(jī)的情況，單體文件服務(wù)器的帶寬、磁盤容量是有上限的，那么當(dāng)文件的體積占滿了整個(gè)磁盤，咱們只能挑選擴(kuò)展，可是這種單體服務(wù)器的方法，關(guān)于擴(kuò)容就不太友好了，咱們能夠想想，難道咱們要將原有的硬盤數(shù)據(jù)拷到一個(gè)更大的硬盤里，然后替換硬盤嗎？

除了擴(kuò)展以外，咱們還需求面對一個(gè)問題，便是文件的查找，假如咱們將一切文件都寄存到一同，文件的數(shù)量假如到了一定的數(shù)量，就會(huì)面對磁盤IO速度瓶頸，不知道咱們有沒有遇到過下圖中這種場景：

假如咱們需求在一個(gè)磁盤中找到某個(gè)文件，假如沒有一個(gè)途徑，或許途徑下有許多文件，那么體系就會(huì)掃描磁盤，咱們都知道，計(jì)算機(jī)體系結(jié)構(gòu)中，關(guān)于速度，CPU>內(nèi)存>硬盤，假如在出產(chǎn)環(huán)境下，真的需求存儲(chǔ)許多的文件，假定存儲(chǔ)的是用戶的頭像，那么用戶每次打開APP，就需求等待個(gè)十幾秒，自己的頭像才會(huì)顯示，那這個(gè)app估計(jì)沒有人會(huì)運(yùn)用吧。

有同學(xué)可能會(huì)說，那咱們能夠運(yùn)用緩存啊，Redis的String類型是能夠存儲(chǔ)二進(jìn)制數(shù)據(jù)的，并且Redis的String類型是一個(gè)Key對應(yīng)一個(gè)值，查詢功率會(huì)很高。確實(shí)這樣在查詢功率上能夠到達(dá)，可是咱們依照一張圖片1M來計(jì)算，緩存又能存多少張圖片呢？很顯然這是一個(gè)十分貴重的方法。

方才咱們考慮的都是服務(wù)器不宕機(jī)的狀況，那么假定服務(wù)器宕機(jī)，那么咱們就無法再供給數(shù)據(jù)存儲(chǔ)服務(wù)；假如硬盤損壞，那么一切的數(shù)據(jù)都將丟掉。

分布式文件體系

上文中說了傳統(tǒng)文件存儲(chǔ)方法的一些缺點(diǎn)和壞處，這其實(shí)也是一切“單點(diǎn)“的壞處，無論是單點(diǎn)數(shù)據(jù)庫、或許單點(diǎn)緩存、又或許是單點(diǎn)網(wǎng)關(guān)、單點(diǎn)注冊中心，都在往分布式集群的方向開展。

總結(jié)一下，單點(diǎn)文件體系大致有這些缺點(diǎn)：

1. 磁盤容量存在瓶頸

2. IO速度存在瓶頸

3. 宕機(jī)、硬盤損壞數(shù)據(jù)丟掉的危險(xiǎn)

那么關(guān)于文件體系，咱們怎么運(yùn)用分布式的方法來處理上述的缺點(diǎn)呢？

• 處理磁盤容量瓶頸
  上文中說到，單服務(wù)器文件體系存在磁盤容量瓶頸的原因是磁盤無法很便利的進(jìn)行擴(kuò)容，咱們一般需求從硬件的層面來考慮擴(kuò)容硬盤，如：替換大容量硬盤。

這種方法顯然是不現(xiàn)實(shí)的，因?yàn)樘鎿Q硬盤意味著咱們需求關(guān)服務(wù)器，出產(chǎn)環(huán)境服務(wù)器關(guān)停三十秒都是很嚴(yán)重的出產(chǎn)事故，所以咱們只能運(yùn)用服務(wù)器橫向擴(kuò)展的方法，假如不能替換硬盤，那么咱們就加服務(wù)器。

• 這樣咱們就能夠運(yùn)用多臺(tái)服務(wù)器共同來構(gòu)成咱們的文件體系了，每個(gè)文件服務(wù)器都是一個(gè)獨(dú)立的節(jié)點(diǎn)，來存儲(chǔ)不同的文件，依據(jù)特定的邏輯（這兒需求自己寫），來決議文件需求存儲(chǔ)到哪個(gè)文件服務(wù)器中。這樣即便服務(wù)器容量滿了，咱們也還能夠持續(xù)橫向擴(kuò)展，理論上這樣咱們的文件體系是沒有容量上限的。

• 處理IO速度瓶頸
  方才咱們處理了單點(diǎn)文件服務(wù)器容量瓶頸，可是假如某臺(tái)或許某幾臺(tái)服務(wù)器上的文件數(shù)量過多（查詢功率降低），或許有許多的用戶拜訪某一臺(tái)服務(wù)器，仍是會(huì)形成IO速度瓶頸。那么要怎么處理這個(gè)問題。
  咱們能夠想一想相似的事例——MySQL數(shù)據(jù)庫。
  眾所周知，MySQL的數(shù)據(jù)也是存在硬盤中的，而咱們在寫SQL句子的時(shí)分，為了保證查詢功率，一般會(huì)避免全表掃描，而是通過索引讓其找到咱們對應(yīng)的那條數(shù)據(jù)。
  所以咱們也能夠通過這種方法，避免全盤掃描或許大范圍掃描，而咱們都知道，操作體系關(guān)于文件是有一個(gè)天然的索引的，便是咱們的多級目錄。FastDFS也正是利用了這個(gè)來添加咱們文件IO的功率的，這個(gè)暫且不提，下文中會(huì)展示。

• 處理宕機(jī)、硬盤損壞數(shù)據(jù)丟掉的危險(xiǎn)
  能否處理這個(gè)問題才是分布式文件體系和單機(jī)文件體系最底子的區(qū)別，因?yàn)闊o論是單機(jī)磁盤容量瓶頸仍是IO速度瓶頸，咱們都能夠通過添加硬件裝備來處理，只不過不太便利且本錢太高罷了。而單機(jī)形式是絕對無法處理宕機(jī)形成的文件服務(wù)失效，或許硬盤損壞形成的數(shù)據(jù)丟掉的，因?yàn)閿?shù)據(jù)只存在一份。

那么咱們思考一下分布式文件體系是怎么來處理這些問題的。

• 首要咱們需求處理宕機(jī)的問題，如上圖，咱們有多個(gè)文件服務(wù)器節(jié)點(diǎn)，可是假如咱們自己寫邏輯來決議某個(gè)文件應(yīng)該存哪個(gè)服務(wù)器上，假定那個(gè)服務(wù)器此時(shí)宕機(jī)了，文件依舊是無法存入的，當(dāng)然咱們能夠持續(xù)寫邏輯來決議假如宕機(jī)了之后應(yīng)該怎么辦，可是FastDFS中現(xiàn)已替咱們實(shí)現(xiàn)了，Tracker節(jié)點(diǎn)能夠協(xié)助咱們挑選文件應(yīng)該上傳到哪個(gè)服務(wù)器上，并且還能夠在某個(gè)節(jié)點(diǎn)宕機(jī)的時(shí)分挑選其從節(jié)點(diǎn)（備份節(jié)點(diǎn)）進(jìn)行文件上傳，防止因?yàn)殄礄C(jī)形成的無法操作文件。

那么依據(jù)上面這幅圖，第二個(gè)問題也就很好理解了，假定某臺(tái)服務(wù)器硬盤損壞了，那么數(shù)據(jù)依舊會(huì)存在備份，即便備份服務(wù)器也損壞了，數(shù)據(jù)也只會(huì)丟掉一部分，而不會(huì)全部丟掉。

FastDFS

上面說了這么多的關(guān)于分布式文件體系能夠處理的一些實(shí)際問題，那么就直接切入今天的主題——FastDFS。

• 全體架構(gòu)

FastDFS文件體系由兩大部分組成，客戶端和服務(wù)端。
客戶端一般指咱們寫的程序（當(dāng)然FastDFS也供給了客戶端測試程序），例如咱們運(yùn)用Java去銜接FastDFS、操作文件，那么咱們的Java程序便是一個(gè)客戶端，F(xiàn)astDFS供給專有API拜訪，目前供給了C、Java和PHP等編程言語的API，用來拜訪FastDFS文件體系。

服務(wù)端由兩個(gè)部分組成，分別是跟蹤器（Tracker）和存儲(chǔ)節(jié)點(diǎn)（Storage）。
跟蹤器（Tracker）：主要做調(diào)度作業(yè)，相似微服務(wù)注冊中心，在內(nèi)存中記載集群存儲(chǔ)節(jié)點(diǎn)的storage的狀況信息，是客戶端和服務(wù)端存儲(chǔ)節(jié)點(diǎn)storage的樞紐，因?yàn)橄嚓P(guān)信息全部在內(nèi)存中，每個(gè)Storage在發(fā)動(dòng)后會(huì)銜接Tracker，奉告自己所屬的group等信息，并周期性發(fā)送心跳，TrackerServer的性能十分高，假定咱們有上百個(gè)Storage節(jié)點(diǎn)，咱們只需求3臺(tái)左右的Tracker就足夠了。

存儲(chǔ)節(jié)點(diǎn)（Storage）用于存儲(chǔ)文件，包含文件和文件屬性（metaData）都保存到服務(wù)器磁盤上，完結(jié)文件辦理的一切功用：文件存儲(chǔ)、文件同步和文件拜訪等。

Storage以group為組織單位，一個(gè)group內(nèi)能夠包含多臺(tái)Storage機(jī)器，數(shù)據(jù)互為備份，總存儲(chǔ)空間以group內(nèi)容量最小的storage為準(zhǔn)（木桶），所以主張一個(gè)group內(nèi)的機(jī)器存儲(chǔ)空間巨細(xì)應(yīng)該盡量相同，以免形成空間的糟蹋。Storage在榜首次發(fā)動(dòng)時(shí)，會(huì)在每一個(gè)存儲(chǔ)目錄里創(chuàng)立二級目錄，合計(jì)256 * 256個(gè)目錄，咱們上傳的文件會(huì)以Hash的方法被路由到其間某個(gè)子目錄下。

• 作業(yè)流程

• 上傳

下載

1. 客戶端發(fā)送下載懇求，Tracker依據(jù)文件信息，回來Storage地址和端口（客戶端也能夠通過自己存儲(chǔ)的文件方位直接拜訪Storage）。

1. 客戶端拜訪Storage，Storage依據(jù)file_id（組名、虛擬磁盤、二級目錄、文件名）查找到文件，回來文件數(shù)據(jù)。

1. 當(dāng)客戶端建議上傳懇求時(shí)，會(huì)先拜訪Tracker，因?yàn)镾torage定時(shí)向Tracker發(fā)送狀況信息，所以Tracker中存有一切Storage Group的信息。

1. Tracker依據(jù)本地的Storage Group信息，為客戶端上傳的文件分配Storage Group，并回來給客戶端。

1. 客戶端拿到Storage Group地址和端口后，上傳文件到指定的Storage Group中。

1. Storage回來文件的途徑信息和文件名。

1. Client將文件信息存儲(chǔ)到本地。

• 單機(jī)裝置

• 裝置前準(zhǔn)備
  
• 裝置
  裝置FastDFS需求兩個(gè)源碼包，分別是libfastcommon-1.0.43.tar.gz和fastdfs-6.06.tar.gz。
  這兒附上作者的github地址：fastdfs，libfastcommon，咱們能夠到這兒下載對應(yīng)的包。

下載完結(jié)后，將其上傳到咱們的linux服務(wù)器中

[root@localhost SoftwareInstallPackage]# ll 總用量 971800 -rw-r--r--. 1 root root    809328 9月   9 23:10 fastdfs-6.06.tar.gz -rw-r--r--. 1 root root    166526 9月   9 23:10 libfastcommon-1.0.43.tar.gz

• 分別運(yùn)轉(zhuǎn)tar -zxvf fastdfs-6.06.tar.gz和tar -zxvf libfastcommon-1.0.43.tar.gz對其進(jìn)行解壓，解壓后進(jìn)入libfastcommon-1.0.43目錄中運(yùn)轉(zhuǎn)sh make.sh，運(yùn)轉(zhuǎn)完畢后運(yùn)轉(zhuǎn)sh make.sh install，然后進(jìn)入fastdfs-6.06目錄中執(zhí)行相同的操作，即可完結(jié)裝置。
  裝置成功后進(jìn)入/usr/bin目錄下，假如存在許多fdfs開頭的命令，則證明裝置成功。

[root@localhost bin]# ll|grep fdfs -rwxr-xr-x. 1 root root    362208 9月   9 23:17 fdfs_appender_test -rwxr-xr-x. 1 root root    361984 9月   9 23:17 fdfs_appender_test1 -rwxr-xr-x. 1 root root    348872 9月   9 23:17 fdfs_append_file -rwxr-xr-x. 1 root root    348480 9月   9 23:17 fdfs_crc32 -rwxr-xr-x. 1 root root    348904 9月   9 23:17 fdfs_delete_file -rwxr-xr-x. 1 root root    349640 9月   9 23:17 fdfs_download_file -rwxr-xr-x. 1 root root    349592 9月   9 23:17 fdfs_file_info -rwxr-xr-x. 1 root root    364912 9月   9 23:17 fdfs_monitor -rwxr-xr-x. 1 root root    349128 9月   9 23:17 fdfs_regenerate_filename -rwxr-xr-x. 1 root root   1280096 9月   9 23:17 fdfs_storaged -rwxr-xr-x. 1 root root    372080 9月   9 23:17 fdfs_test -rwxr-xr-x. 1 root root    367200 9月   9 23:17 fdfs_test1 -rwxr-xr-x. 1 root root    512312 9月   9 23:17 fdfs_trackerd -rwxr-xr-x. 1 root root    349832 9月   9 23:17 fdfs_upload_appender -rwxr-xr-x. 1 root root    350848 9月   9 23:17 fdfs_upload_file

• 而/etfc/fdfs目錄中寄存了一切的FastDFS的裝備文件：

然后進(jìn)入/etc/fdfs，這兒寄存了一切fastDFS的裝備文件

[root@localhost fdfs]# ll 總用量 32 #客戶端銜接裝備 -rw-r--r--. 1 root root  1909 9月   9 23:17 client.conf.sample #存儲(chǔ)節(jié)點(diǎn)裝備 -rw-r--r--. 1 root root 10246 9月   9 23:17 storage.conf.sample -rw-r--r--. 1 root root   620 9月   9 23:17 storage_ids.conf.sample #追尋器裝備 -rw-r--r--. 1 root root  9138 9月   9 23:17 tracker.conf.sample

• 最后一步，咱們需求進(jìn)入FastDFS裝置包解壓后的conf目錄下，找到http.conf和mime.types將其復(fù)制到/etc/fdfs目錄下。

[root@localhost conf]# pwd /WorkSpace/Software/fastdfs-6.06/conf [root@localhost conf]# cp http.conf /etc/fdfs/ [root@localhost conf]# cp mime.types /etc/fdfs/

• 這樣咱們就完結(jié)了FastDFS的裝置。
• 裝備文件詳解
  裝置完結(jié)后需求先把裝備文件裝備好才能夠正常發(fā)動(dòng)，這兒會(huì)貼上tracker.conf、storage.conf、client.conf的一切裝備項(xiàng)，就當(dāng)作一個(gè)裝備模板吧，裝備的時(shí)分能夠直接copy。
  首要是tracker.conf:

# 這個(gè)裝備文件是否 不收效(這兒筆者個(gè)人以為，改成是否收效會(huì)比較好)，true代表不收效，false代表收效 disabled = false # 是否綁定ip，假如不填就代表一切的ip都供給服務(wù)，常用于服務(wù)器有多個(gè)ip但只期望一個(gè)ip供給服務(wù) bind_addr = # Tracker的端口號 port = 22122 # 銜接超時(shí)的時(shí)刻 單位為s connect_timeout = 5 # Tracker的網(wǎng)絡(luò)超時(shí)，單位為秒。發(fā)送或接納數(shù)據(jù)時(shí)，假如在超時(shí)時(shí)刻后還不能發(fā)送或接納數(shù)據(jù)，則本次網(wǎng)絡(luò)通信失利。 network_timeout = 60 # Tracker服務(wù)的數(shù)據(jù)寄存地址，這個(gè)目錄有必要是存在的 base_path = /home/yuqing/fastdfs # 體系供給的最大銜接數(shù) max_connections = 1024 # 接納線程數(shù)  主張為1 accept_threads = 1 # 作業(yè)線程數(shù) 引薦設(shè)置為CPU線程數(shù) work_threads = 4 # 最小網(wǎng)絡(luò)緩存  默許值為8KB min_buff_size = 8KB # 最大網(wǎng)絡(luò)緩存 默許值為128KB max_buff_size = 128KB # 上傳文件挑選group的方法 # 0：輪詢 # 1：指定一個(gè)group # 2：負(fù)載均衡，挑選一個(gè)最多閑暇空間的group來上傳文件 store_lookup = 2 # 當(dāng)store_lookup設(shè)置為1時(shí)，有必要在這個(gè)參數(shù)中設(shè)置一個(gè)group用來上傳文件 # 當(dāng)store_lookup設(shè)置不為1時(shí)，這個(gè)參數(shù)無效 store_group = group2 # 挑選group中的哪一個(gè)storage服務(wù)器用來上傳文件 # 0：輪詢 # 1：依照ip地址排序，ip最小的那個(gè)服務(wù)器用來上傳文件 # 2：依據(jù)優(yōu)先級進(jìn)行排序，上傳優(yōu)先級在storage裝備文件中進(jìn)行裝備，裝備項(xiàng)為upload_priority store_server = 0 # 挑選storage服務(wù)器中的哪一個(gè)目錄進(jìn)行上傳，一個(gè)storage中能夠有多個(gè)寄存文件的base_path（能夠理解為磁盤分區(qū)） # 0：輪詢 # 2:負(fù)載均衡，挑選剩余空間最多的一個(gè)途徑來上傳文件 store_path = 0 # 挑選哪個(gè)storage服務(wù)器作為下載文件的服務(wù)器 # 0：輪詢 # 1：文件上傳到哪個(gè)storage服務(wù)器就去哪個(gè)storage服務(wù)器上下載 download_server = 0 # storage服務(wù)器上為其他應(yīng)用保存的空間 # 能夠用絕對值或許百分比：10G或許1024M或許1024K或許XX.XX% # 假如同組中的服務(wù)器硬盤巨細(xì)相同 以最小的為準(zhǔn)，到達(dá)最小的那個(gè)值，則無法再進(jìn)行上傳 reserved_storage_space = 20% # 規(guī)范日志級別從小到大順次:debuglog_level = info # 操作體系運(yùn)轉(zhuǎn)FastDFS的用戶組，不填默許便是發(fā)動(dòng)FastDFS的用戶組 run_by_group= # 操作體系運(yùn)轉(zhuǎn)FastDFS的用戶，不填默許便是發(fā)動(dòng)FastDFS的用戶 run_by_user = # 能夠銜接到此Tracker Server的IP范圍 # 比如： # allow_hosts=10.0.1.[1-15,20] # allow_hosts=host[01-08,20-25].domain.com # allow_hosts=192.168.5.64/26 allow_hosts = * # 同步日志緩存到硬盤的時(shí)刻 # 默許十秒一次（Tracker的日志默許是先寫在內(nèi)存里的） sync_log_buff_interval = 10 # 查看storage服務(wù)器存活狀況的距離時(shí)刻 check_active_interval = 120 # 線程棧巨細(xì) 需求大于64KB # 默許值256KB # 線程棧越大 work_thread能發(fā)動(dòng)的就越少 thread_stack_size = 256KB # 當(dāng)storage server IP地址改動(dòng)時(shí)，集群是否自動(dòng)調(diào)整。注：只有在storage server進(jìn)程重啟時(shí)才完結(jié)自動(dòng)調(diào)整。 # 默以為true storage_ip_changed_auto_adjust = true # storage 同步文件最大延遲時(shí)刻 # 默以為一天 86400秒 # 注：本參數(shù)并不影響文件同步進(jìn)程。本參數(shù)僅在下載文件時(shí)，判別文件是否現(xiàn)已被同步完結(jié)的一個(gè)閾值（經(jīng)驗(yàn)值） storage_sync_file_max_delay = 86400 # 存儲(chǔ)服務(wù)器同步一個(gè)文件需求消耗的最大時(shí)刻，缺省為300s，即5分鐘。 # 注：本參數(shù)并不影響文件同步進(jìn)程。本參數(shù)僅在下載文件時(shí)，作為判別當(dāng)前文件是否被同步完結(jié)的一個(gè)閾值（經(jīng)驗(yàn)值） storage_sync_file_max_time = 300 # 是否運(yùn)用小文件兼并，默以為false # trunk_file能夠理解為一個(gè)容器，專門用來寄存小文件的 # 含有許多個(gè)slot(槽)，每個(gè)槽寄存一個(gè)小文件 use_trunk_file = false # trunk file給小文件分配的最小字節(jié)數(shù)。比如文件只有16個(gè)字節(jié)，體系也會(huì)分配slot_min_size個(gè)字節(jié)。 slot_min_size = 256 # 只有文件巨細(xì)<=這個(gè)參數(shù)值的文件，才會(huì)兼并存儲(chǔ)。假如一個(gè)文件的巨細(xì)大于這個(gè)參數(shù)值，將直接保存到一個(gè)文件中（即不選用兼并存儲(chǔ)方法）。 slot_max_size = 1MB # 兼并存儲(chǔ)的trunk file巨細(xì)，至少4MB，缺省值是64MB。不主張?jiān)O(shè)置得過大。 trunk_alloc_alignment_size = 256 # 兼并后trunk file的接連可用空間（槽）是否兼并，默以為true（防止產(chǎn)生碎片） trunk_free_space_merge = true # 刪去沒有運(yùn)用的trunk_files delete_unused_trunk_files = false # trunk file的最大巨細(xì)，有必要要大于4MB trunk_file_size = 64MB # 是否提早創(chuàng)立trunk file 默以為false trunk_create_file_advance = false # 創(chuàng)立trunk file的起始(榜首次)時(shí)刻點(diǎn) 默以為2:00 trunk_create_file_time_base = 02:00 # 創(chuàng)立trunk file的時(shí)刻距離 默以為1天 86400秒 trunk_create_file_interval = 86400 # 提早創(chuàng)立trunk_file時(shí)，需求到達(dá)的閑暇trunk巨細(xì) trunk_create_file_space_threshold = 20G # trunk初始化時(shí)，是否查看可用空間是否被占用 trunk_init_check_occupying = false # 是否無條件從trunk binlog中加載trunk可用空間信息 # FastDFS缺省是從快照文件storage_trunk.dat中加載trunk可用空間， # 該文件的榜首行記載的是trunk binlog的offset，然后從binlog的offset開端加載 trunk_init_reload_from_binlog = false # 緊縮trunk binlog日志的最小時(shí)刻距離，0代表從不緊縮 trunk_compress_binlog_min_interval = 86400 # 緊縮trunk binlog日志的時(shí)刻距離 0代表從不緊縮 trunk_compress_binlog_interval = 86400 # 首次緊縮trunk binlog的時(shí)刻 trunk_compress_binlog_time_base = 03:00 # trunk binlog的最大備份 0代表無備份 trunk_binlog_max_backups = 7 # 是否運(yùn)用storage_id作為區(qū)別storage的標(biāo)識(shí) use_storage_id = false # use_storage_id 設(shè)置為true，才需求設(shè)置本參數(shù) # 在文件中設(shè)置組名、server ID和對應(yīng)的IP地址，拜見源碼目錄下的裝備示例：conf/storage_ids.conf storage_ids_filename = storage_ids.conf # 文件名中存儲(chǔ)服務(wù)器的id類型，值為： # ip：存儲(chǔ)服務(wù)器的ip地址 # id：存儲(chǔ)服務(wù)器的服務(wù)器id # 此參數(shù)僅在use_storage_id設(shè)置為true時(shí)有用 # 默許值為id id_type_in_filename = id # 是否運(yùn)用符號鏈接的方法 # 假如設(shè)置為true 一個(gè)文件將占用兩個(gè)文件 符號鏈接指向原始文件 store_slave_file_use_link = false # 是否定時(shí)切割error.log true只支撐一天一次 rotate_error_log = false # error.log切割時(shí)刻 error_log_rotate_time = 00:00 # 是否緊縮舊error_log日志 compress_old_error_log = false # 緊縮幾天前的errorlog，默許7天前 compress_error_log_days_before = 7 # error log按巨細(xì)切割 # 設(shè)置為0表示不按文件巨細(xì)切割，否則當(dāng)error log到達(dá)該巨細(xì)，就會(huì)切割到新文件中 rotate_error_log_size = 0 # 日志寄存時(shí)刻 # 0表示從不刪去舊日志 log_file_keep_days = 0 # 是否運(yùn)用銜接池 use_connection_pool = true # 銜接池最大閑暇時(shí)刻 connection_pool_max_idle_time = 3600 # 本tracker服務(wù)器的默許HTTP端口 http.server_port = 8080 # 距離幾秒查看storage http服務(wù)器的存活 # <=0代表從不查看 http.check_alive_interval = 30 # 查看storage的存活狀況的類型 # tcp：銜接上就能夠，但不發(fā)送懇求也不獲取響應(yīng) # http storage有必要回來200 http.check_alive_type = tcp # 查看storage狀況的uri http.check_alive_uri = /status.html