1. 先搞清楚它是什么FastDFS的定位與適用場(chǎng)景如果你做過(guò)后端開(kāi)發(fā)大概率遇到過(guò)文件存儲(chǔ)這類需求——用戶頭像、商品圖片、網(wǎng)盤附件、視頻資源凡是得落盤的東西早晚都會(huì)擠爆你那臺(tái)服務(wù)器的磁盤。我最早處理這類需求時(shí)特別天真把文件直接丟在應(yīng)用服務(wù)器的某個(gè)目錄下再走一層Nginx把靜態(tài)目錄暴露出去一開(kāi)始確實(shí)省事但隨著文件越來(lái)越多、服務(wù)器壓力越來(lái)越大拆分就成了繞不開(kāi)的坎。FastDFS就是奔著這個(gè)問(wèn)題來(lái)的。它是一個(gè)用C語(yǔ)言寫的開(kāi)源輕量級(jí)分布式文件系統(tǒng)專門用來(lái)存儲(chǔ)中小尺寸的文件核心能力就三句話文件存得下、文件不丟、文件能橫向擴(kuò)展。說(shuō)它是分布式文件系統(tǒng)它跟HDFS那類動(dòng)輒幾百G內(nèi)存起步的重量級(jí)選手不是一個(gè)路子FastDFS的設(shè)計(jì)哲學(xué)是極簡(jiǎn)化——不搞復(fù)雜的數(shù)據(jù)塊抽象不做副本級(jí)的強(qiáng)一致機(jī)制它把文件存成扁平結(jié)構(gòu)用組group作為基本單位來(lái)做容災(zāi)和擴(kuò)容適合文件總體規(guī)模在TB級(jí)別、單文件大小在KB到幾十MB之間的場(chǎng)景。那什么時(shí)候該用FastDFS我個(gè)人的判斷標(biāo)準(zhǔn)有三條。第一文件數(shù)量大、平均尺寸小比如一個(gè)每天產(chǎn)生幾萬(wàn)張圖片的商城系統(tǒng)這種場(chǎng)景對(duì)象存儲(chǔ)當(dāng)然也能做但如果不想把業(yè)務(wù)綁到云廠商的API上自建一套FastDFS是成本最低的路徑。第二對(duì)讀寫延遲有一定要求但不苛刻FastDFS是純內(nèi)存態(tài)的管理加磁盤態(tài)的存儲(chǔ)上傳下載速度非常快內(nèi)網(wǎng)跑滿千兆是完全可能的。第三機(jī)房環(huán)境可控、機(jī)器數(shù)量不多兩到三臺(tái)起步就能搭一套能用的集群?jiǎn)螜C(jī)磁盤不夠了再加機(jī)器就行不必一上來(lái)就上Kafka、ES那套全家桶。沒(méi)接觸過(guò)的人可能會(huì)問(wèn)它跟OSS、S3這類對(duì)象存儲(chǔ)有什么區(qū)別其實(shí)FastDFS本質(zhì)上也可以算作一種私有化部署的類對(duì)象存儲(chǔ)只不過(guò)它的接口不是S3協(xié)議而是自有的客戶端協(xié)議。前者是花錢買省心后者是自己動(dòng)手換自主可控兩條路沒(méi)有絕對(duì)好壞取決于你手里的資源和對(duì)成本的敏感度。如果項(xiàng)目剛起步、機(jī)器預(yù)算有限又希望文件這一層能扛住增長(zhǎng)FastDFS是個(gè)非常務(wù)實(shí)的備選方案。另外值得一提的是FastDFS的部署形態(tài)非常輕——Tracker和Storage兩個(gè)角色都是單一二進(jìn)制文件配置項(xiàng)也少得可憐幾分鐘就能把一個(gè)單機(jī)實(shí)例跑起來(lái)。相比起動(dòng)不動(dòng)就要你搭一堆依賴組件的系統(tǒng)這種給個(gè)tar包就能玩的項(xiàng)目對(duì)新手極其友好。我第一次部署時(shí)大概只花了不到半小時(shí)連讀文檔帶踩坑這份經(jīng)驗(yàn)后來(lái)多次幫我在朋友公司的項(xiàng)目里快速落地了文件層方案。2. 架構(gòu)拆解Tracker與Storage各自扮演的角色FastDFS整個(gè)系統(tǒng)里只有兩種角色Tracker Server和Storage Server。有的資料會(huì)把FastDFS的架構(gòu)分成三部分把客戶端也算進(jìn)去但我更習(xí)慣把客戶端忽略掉因?yàn)镕astDFS的官方客戶端更像是一層SDK真正干活的是這兩個(gè)服務(wù)端角色。Tracker Server是調(diào)度的核心它的職責(zé)是維護(hù)整個(gè)集群里所有Storage節(jié)點(diǎn)的狀態(tài)包括哪個(gè)組還活著、哪個(gè)存儲(chǔ)節(jié)點(diǎn)的負(fù)載情況、磁盤剩余空間還有多少。注意Tracker是不存文件內(nèi)容的它只保存元數(shù)據(jù)級(jí)別的路由信息所以它的內(nèi)存和CPU壓力都不大。一個(gè)FastDFS集群可以部署多個(gè)Tracker彼此之間通過(guò)選舉機(jī)制選出主節(jié)點(diǎn)客戶端拿到的是可用Tracker的地址列表任何一個(gè)掛了都能自動(dòng)切換過(guò)去。Storage Server才是真正存放文件的地方。Storage以組為組織單位一個(gè)組內(nèi)可以有多臺(tái)機(jī)器組內(nèi)機(jī)器之間做數(shù)據(jù)互備——同一份文件會(huì)在同一個(gè)組里的每臺(tái)機(jī)器上都落一份這樣只要組里還有一臺(tái)機(jī)器活著數(shù)據(jù)就還在。不同組之間存的是完全不同的文件互不相干。這種設(shè)計(jì)帶來(lái)的好處非常直接想要提高容錯(cuò)就增加組內(nèi)的機(jī)器想要提升存儲(chǔ)容量上限就增加組的數(shù)量。橫向擴(kuò)展和縱向加固被徹底解耦操作起來(lái)非常清晰?？赡苡腥藭?huì)問(wèn)既然組內(nèi)是多副本為什么FastDFS不把容災(zāi)做到多個(gè)組之間這其實(shí)是有意的取舍。跨組互備意味著任意一個(gè)組里的一對(duì)機(jī)器損壞都可能牽連到其他組的目錄結(jié)構(gòu)維護(hù)成本陡增。FastDFS選擇的是最樸素的主從模型組內(nèi)主備同步組間各自獨(dú)立。它犧牲了一點(diǎn)極端場(chǎng)景下的冗余能力換來(lái)了架構(gòu)的簡(jiǎn)潔和運(yùn)維的直觀實(shí)際用起來(lái)很少會(huì)因?yàn)槎喔北镜膯?wèn)題頭疼。Storage內(nèi)部還分幾個(gè)目錄層級(jí)文件名會(huì)經(jīng)過(guò)哈希之后分散到不同的子目錄里。這里建議初次接觸的人重點(diǎn)理解一個(gè)概念文件ID不只是一個(gè)隨機(jī)的名字它里面其實(shí)是帶著路由信息的格式通常是組名/磁盤目錄/兩級(jí)子目錄/文件名?？蛻舳四玫竭@個(gè)ID就能反推出文件在哪一組、大概在哪個(gè)子目錄Tracker的定位壓力也就被分?jǐn)傁氯チ讼螺d文件時(shí)可以直接定位到具體Storage節(jié)點(diǎn)而不需要每次都來(lái)一次全集群掃描。Tracker和Storage之間的通信走的是2188端口的心跳協(xié)議Storage每隔一段時(shí)間向自己注冊(cè)的Tracker上報(bào)磁盤剩余量和同步狀態(tài)。Tracker側(cè)維護(hù)著一張動(dòng)態(tài)更新的節(jié)點(diǎn)表客戶端每次操作文件之前先向Tracker問(wèn)一句這個(gè)文件我該找誰(shuí)Tracker返回一個(gè)可用的Storage地址客戶端再直連它去讀寫。一整套流程走下來(lái)Tracker本身只負(fù)責(zé)做輕量級(jí)的決策不會(huì)成為數(shù)據(jù)通道上的瓶頸這也是FastDFS能扛住高并發(fā)文件操作的原因之一。3. 文件從上傳到訪問(wèn)的完整鏈路搞懂FastDFS的讀寫流程比單純背概念有用得多。我剛?cè)腴T時(shí)對(duì)著架構(gòu)圖看了半天總覺(jué)得心里沒(méi)底直到自己把上傳日志打出來(lái)、一條一條追蹤了一次完整請(qǐng)求才算徹底弄明白這套調(diào)度是怎么回事。先說(shuō)上傳?？蛻舳苏{(diào)用接口時(shí)先把文件名和文件大小信息發(fā)給TrackerTracker根據(jù)各組的存儲(chǔ)狀態(tài)選出一個(gè)合適的組再?gòu)倪@個(gè)組里挑一臺(tái)剩余容量充裕的Storage然后把這臺(tái)Storage的地址返回給客戶端。注意這里的剩余容量充裕Tracker并不是隨機(jī)亂選的——它的調(diào)度策略是優(yōu)先選擇磁盤剩余空間最大的組組內(nèi)優(yōu)先選擇剩余空間最大的Storage這保證了集群里的數(shù)據(jù)相對(duì)均勻地鋪在各塊磁盤上不至于出現(xiàn)某臺(tái)磁盤寫滿、旁邊的還是空著的尷尬情況?？蛻舳四玫降刂泛笾苯酉騍torage發(fā)起連接寫入文件內(nèi)容。Storage把文件落到磁盤后會(huì)根據(jù)配置生成一個(gè)文件ID再把這個(gè)ID返回給客戶端。到這里上傳就算完成了。整個(gè)過(guò)程Tracker只在最開(kāi)始做了一次調(diào)度決策后面就完全不參與了數(shù)據(jù)不經(jīng)過(guò)它中轉(zhuǎn)。再往下走FastDFS會(huì)異步執(zhí)行組內(nèi)的同步。文件剛寫完時(shí)它只會(huì)出現(xiàn)在當(dāng)前這臺(tái)Storage上另外幾臺(tái)備機(jī)上的同組節(jié)點(diǎn)會(huì)通過(guò)binlog方式把文件拉過(guò)去實(shí)現(xiàn)最終一致。所以這里有個(gè)細(xì)節(jié)要留心剛上傳完的文件如果在極短時(shí)間內(nèi)去別的組內(nèi)節(jié)點(diǎn)讀取是有可能暫時(shí)讀不到的等同步完成才能保證可用。FastDFS的同步非常快局域網(wǎng)內(nèi)一般秒級(jí)就完成了但極端情況下如果你在寫完立刻跨節(jié)點(diǎn)去讀需要有個(gè)重試機(jī)制兜底。下載流程是上行鏈路的逆過(guò)程?？蛻舳四弥募蘒D向Tracker查詢Tracker解析出這個(gè)ID里的組名然后返回該組內(nèi)某臺(tái)Storage的地址。這里的組內(nèi)選擇策略跟上傳時(shí)略有不同——如果配置了優(yōu)先讀取本機(jī)客戶端會(huì)直接定位到ID被創(chuàng)建時(shí)那臺(tái)機(jī)器否則Tracker會(huì)返回當(dāng)前負(fù)載較低的一臺(tái)。拿到地址后客戶端再直連Storage讀取文件內(nèi)容。那客戶端又是怎么知道該找哪個(gè)Tracker的呢一般是在初始化SDK時(shí)傳入一組Tracker地址列表SDK啟動(dòng)時(shí)會(huì)主動(dòng)注冊(cè)并獲取可用的Tracker節(jié)點(diǎn)。如果第一個(gè)連不上會(huì)自動(dòng)切換下一個(gè)保證整個(gè)服務(wù)不會(huì)因?yàn)槟撑_(tái)Tracker宕機(jī)而不可用。我第一次搭的時(shí)候只配了一個(gè)Tracker后來(lái)被同事提醒才明白這玩意單點(diǎn)風(fēng)險(xiǎn)極大趕緊加了一臺(tái)并配置好選主心里才踏實(shí)。FastDFS還支持一種Nginx擴(kuò)展模塊叫fastdfs-nginx-module它的用途是把HTTP下載能力對(duì)接進(jìn)來(lái)。Storage本身的服務(wù)端口是23000走的是私有協(xié)議不方便給瀏覽器直接用通過(guò)這個(gè)Nginx擴(kuò)展你可以把文件ID映射成URL讓用戶直接通過(guò)http://域名/group1/M00/... 這種路徑訪問(wèn)文件。實(shí)際部署時(shí)普遍的做法是每臺(tái)Storage上裝一個(gè)Nginx專門用來(lái)做本機(jī)文件對(duì)外服務(wù)速度和穩(wěn)定性都很好。最后多說(shuō)一句關(guān)于目錄結(jié)構(gòu)的事。FastDFS會(huì)按天自動(dòng)生成兩級(jí)子目錄例如當(dāng)前日期是某月某日就生成M00/XX/XX這樣的路徑文件通過(guò)取文件名hash值的前兩位來(lái)決定落到哪個(gè)子目錄避免單目錄內(nèi)文件太多導(dǎo)致查詢效率下降。這部分邏輯在系統(tǒng)內(nèi)部自動(dòng)完成不需要人工干預(yù)但理解它的原理對(duì)排查某個(gè)文件到底存到哪去了這類問(wèn)題時(shí)特別有用。4. 從零搭建一套FastDFS環(huán)境的實(shí)測(cè)記錄部署FastDFS最怕的不是不會(huì)配而是配到一半發(fā)現(xiàn)文檔跟實(shí)際版本對(duì)不上。我這次記錄的是基于最新穩(wěn)定版安裝包的操作用一個(gè)組加兩塊磁盤的簡(jiǎn)單形態(tài)做講解單機(jī)照樣能跑通兩臺(tái)以上機(jī)器可以實(shí)現(xiàn)真正的組內(nèi)互備。先準(zhǔn)備環(huán)境。FastDFS依賴libfastcommon這個(gè)公共庫(kù)需要提前編譯安裝順序不能搞反。整套工具鏈要求gcc、make這些基礎(chǔ)編譯工具存在我這里用的是某臺(tái)干凈的CentOS 7虛擬機(jī)內(nèi)存給了1G沒(méi)有做任何額外優(yōu)化。如果機(jī)器上沒(méi)有這些依賴先執(zhí)行一下包管理器的安裝命令把編譯工具鏈備齊否則后面編譯會(huì)報(bào)錯(cuò)。整個(gè)安裝過(guò)程大概三步先編譯libfastcommon再編譯FastDFS本體最后把Tracker和Storage的配置寫對(duì)并啟動(dòng)服務(wù)。編譯安裝的細(xì)節(jié)我不展開(kāi)每個(gè)命令了重點(diǎn)說(shuō)配置階段最容易翻車的地方。Tracker的配置文件只有一個(gè)tracker.conf需要關(guān)注的選項(xiàng)是base_path、store_lookup和reserved_storage_space。base_path指定的是Tracker保存狀態(tài)文件的目錄建議放到獨(dú)立的磁盤分區(qū)上并把日志單獨(dú)重定向出來(lái)。reserved_storage_space這個(gè)參數(shù)非常關(guān)鍵——它決定了Tracker認(rèn)為某個(gè)存儲(chǔ)組剩余空間不足的閾值默認(rèn)是10%意思是磁盤容量只剩10%時(shí)就不再往這個(gè)組調(diào)度新文件了。如果你的磁盤總量不大建議把這個(gè)值調(diào)低一點(diǎn)否則白白浪費(fèi)很大一塊可用空間。Storage的配置文件是storage.conf里面要配的字段多幾個(gè)group_name、base_path、store_path_count、store_path0、tracker_server。group_name必須跟組內(nèi)其他節(jié)點(diǎn)保持一致否則會(huì)被Tracker當(dāng)成另一個(gè)組的機(jī)器。store_path_count和store_path0是配套的表示這個(gè)Storage上掛了幾塊獨(dú)立的存儲(chǔ)路徑FastDFS會(huì)在這幾個(gè)路徑之間做文件分布。如果你有兩塊磁盤想都利用上就在這里配store_path_count2然后分別指定store_path0和store_path1的路徑但要注意所有store_path的剩余空間必須都大于reserved_storage_space的閾值否則整個(gè)Storage會(huì)被判斷為不可用。配置寫好后先啟動(dòng)Tracker再啟動(dòng)Storage啟動(dòng)順序沒(méi)有硬性要求但建議Tracker先起Storage啟動(dòng)時(shí)才能正常注冊(cè)上去。用監(jiān)控命令查一下節(jié)點(diǎn)注冊(cè)狀態(tài)如果看到ACTIVE的字樣說(shuō)明這臺(tái)Storage已經(jīng)被Tracker納管了。首次啟動(dòng)后Tracke會(huì)生成一個(gè)data目錄里面放著集群信息千萬(wàn)不要手滑刪掉否則Storage之間會(huì)誤認(rèn)為自己是新節(jié)點(diǎn)。我把整個(gè)搭建過(guò)程中的幾個(gè)易錯(cuò)點(diǎn)整理成了一張表易錯(cuò)點(diǎn)現(xiàn)象解決方式編譯缺少依賴編譯中斷報(bào)未找到頭文件檢查gcc及l(fā)ibfastcommon是否正確安裝tracker.conf中reserved_storage_space過(guò)大新文件總寫入失敗根據(jù)實(shí)際磁盤容量下調(diào)到1%~5%storage.conf中g(shù)roup_name不一致同組互備不生效組內(nèi)所有節(jié)點(diǎn)配置完全相同的group_name防火墻未放行端口客戶端連接被拒絕放行Tracker的22122和Storage的23000端口base_path誤放在系統(tǒng)盤且空間不足日志撐爆系統(tǒng)盤用獨(dú)立數(shù)據(jù)盤掛載并指定路徑還有一件事很容易被忽略FastDFS的時(shí)間同步問(wèn)題。各節(jié)點(diǎn)之間的系統(tǒng)時(shí)間如果差太多心跳和同步會(huì)變得異常要么誤判節(jié)點(diǎn)離線要么binlog位置錯(cuò)亂。建議部署完就把NTP時(shí)間同步裝上讓所有機(jī)器的時(shí)間保持一致。我在第一次測(cè)試時(shí)沒(méi)有做這一步結(jié)果一臺(tái)Storage的時(shí)鐘慢了五分鐘日志里不斷出現(xiàn)超時(shí)重連的告警排查了半天才定位到是這個(gè)原因。5. 客戶端接入與API使用細(xì)節(jié)FastDFS客戶端不是我之前提到的那種大型SDK它本質(zhì)上是一層極薄的協(xié)議封裝支持的語(yǔ)言覆蓋了Java、Python、Go、PHP等主流方向。這里拿Java和Python各舉一個(gè)例子把最常用的上傳下載邏輯講清楚你完全可以直接遷到自己的項(xiàng)目里去。Java端的接入方式很統(tǒng)一——引入官方提供的客戶端依賴然后創(chuàng)建ClientGlobal對(duì)象初始化時(shí)把Tracker地址列表寫進(jìn)去。這里有一個(gè)容易踩的坑ClientGlobal初始化時(shí)的超時(shí)參數(shù)默認(rèn)是30秒如果網(wǎng)絡(luò)抖動(dòng)導(dǎo)致連接失敗HTTP接口層會(huì)等很久才返回前端就會(huì)看到轉(zhuǎn)圈半天。建議把網(wǎng)絡(luò)超時(shí)調(diào)到5秒以內(nèi)并配合重試邏輯體驗(yàn)會(huì)好得多。核心的上傳代碼無(wú)非就是構(gòu)建一個(gè)StorageClient對(duì)象調(diào)用upload_file方法傳入本地文件路徑和后綴名最終拿到一個(gè)包含組名和文件名的字符串?dāng)?shù)組。拿到這兩個(gè)字段后把它們拼接成文件ID保存到數(shù)據(jù)庫(kù)后續(xù)下載和刪除都用它來(lái)定位。我在實(shí)際項(xiàng)目里會(huì)把文件ID當(dāng)做一個(gè)不透明的字符串來(lái)存訪問(wèn)時(shí)直接用FastDFS的Nginx模塊去映射這樣后端Java服務(wù)只需要負(fù)責(zé)生成ID真正的文件IO全走HTTP層壓力很小。Python端的接入同樣順暢。初始化客戶端時(shí)把tracker_conf路徑指過(guò)去然后創(chuàng)建一個(gè)StorageClient實(shí)例上傳就一行代碼。需要注意的是Python客戶端返回的文件ID結(jié)構(gòu)跟Java略有不同它直接返回一個(gè)元組第一個(gè)元素是組名第二個(gè)是遠(yuǎn)程文件名兩個(gè)必須同時(shí)保存下來(lái)缺一個(gè)都定位不到文件。下載同理用download_file方法把文件內(nèi)容拉回本地或者直接拿到字節(jié)流做后續(xù)處理——比如圖片壓縮、視頻轉(zhuǎn)碼可以先在內(nèi)存里過(guò)一遍再落盤避免臨時(shí)文件的反復(fù)讀寫。講到這里必須提醒一下FastDFS自帶的客戶端API在網(wǎng)絡(luò)異常時(shí)行為比較生硬寫業(yè)務(wù)代碼時(shí)一定要在外面包一層自己的容錯(cuò)邏輯。比如上傳失敗時(shí)把文件先存到本地臨時(shí)目錄等網(wǎng)絡(luò)恢復(fù)再補(bǔ)傳下載失敗時(shí)如果允許可以嘗試從同組的另一臺(tái)Storage拉數(shù)據(jù)。FastDFS本身沒(méi)有復(fù)雜的負(fù)載均衡邏輯這些策略最好在業(yè)務(wù)層做省得日后出問(wèn)題還得改底層SDK。另外文件刪除接口也要慎用。FastDFS執(zhí)行刪除是很徹底的——文件ID一旦刪除對(duì)應(yīng)的物理文件就會(huì)被清理沒(méi)有回收站。如果你不小心把線上文件的ID刪了而且組內(nèi)同步已經(jīng)完成那就真的找不回來(lái)了。我在生產(chǎn)環(huán)境里給文件刪除接口加了一層軟刪除位業(yè)務(wù)層的刪除操作只更新數(shù)據(jù)庫(kù)狀態(tài)真正的FastDFS刪除延后到凌晨低峰期集中執(zhí)行給誤操作留出反悔時(shí)間。這個(gè)習(xí)慣救過(guò)我一次后來(lái)也推薦給了其他朋友。還有一點(diǎn)容易被忽略訪問(wèn)頻率。FastDFS對(duì)高并發(fā)讀是能扛住的畢竟每臺(tái)Storage上的Nginx直接對(duì)外服務(wù)不需要經(jīng)過(guò)任何中心節(jié)點(diǎn)。但上傳和刪除這類寫操作由于要經(jīng)過(guò)Tracker調(diào)度并發(fā)太高時(shí)Tracker的CPU也會(huì)有一定消耗。我見(jiàn)過(guò)一個(gè)極端案例對(duì)方把圖片上傳全部走FastDFS高峰每秒上千次上傳請(qǐng)求四個(gè)Tracker節(jié)點(diǎn)的CPU直接飆到80%以上。后來(lái)它們?cè)跇I(yè)務(wù)層做了合并上傳處理把多個(gè)小文件打包成一個(gè)大文件再上傳問(wèn)題就緩解了。如果你的系統(tǒng)存在類似的寫入洪峰建議盡早做這種批量化的改造。6. 用了兩年之后才知道的坑與調(diào)優(yōu)經(jīng)驗(yàn)FastDFS用久了才會(huì)發(fā)現(xiàn)它的坑多數(shù)不在功能層面而在運(yùn)維習(xí)慣和容量規(guī)劃的細(xì)節(jié)上。這里整理幾條我踩過(guò)之后印象特別深的經(jīng)驗(yàn)供后來(lái)人少走彎路。第一個(gè)坑是擴(kuò)容操作前置條件沒(méi)做好。往一個(gè)已有的組里加新的Storage節(jié)點(diǎn)時(shí)新節(jié)點(diǎn)啟動(dòng)后會(huì)自動(dòng)嘗試向同組的舊節(jié)點(diǎn)同步數(shù)據(jù)。如果舊節(jié)點(diǎn)上的文件有幾百萬(wàn)個(gè)同步過(guò)程可能持續(xù)好幾個(gè)小時(shí)期間新節(jié)點(diǎn)會(huì)顯示為SYNC狀態(tài)不會(huì)對(duì)外提供讀取服務(wù)。我遇到過(guò)最極端的案例是加了一臺(tái)新機(jī)器同步跑了三天還沒(méi)跑完因?yàn)樵璯roup里已經(jīng)有上億個(gè)小文件。所以擴(kuò)容前一定要評(píng)估任務(wù)量最好在業(yè)務(wù)低峰期操作。而且擴(kuò)容完成后不要立刻把舊節(jié)點(diǎn)重啟或者做磁盤檢查防止中斷同步導(dǎo)致數(shù)據(jù)不一致。第二個(gè)坑是磁盤空間檢查只看df是不夠的。FastDFS在上傳文件時(shí)會(huì)實(shí)時(shí)計(jì)算目標(biāo)存儲(chǔ)組的剩余容量這個(gè)計(jì)算邏輯依賴的是Storage啟動(dòng)時(shí)掃描到的磁盤信息。如果你在存儲(chǔ)節(jié)點(diǎn)上手動(dòng)清掉了大量文件比如用find命令刪了一批臨時(shí)目錄Storage的剩余空間統(tǒng)計(jì)不會(huì)立刻更新除非重啟進(jìn)程或者等它下一次定時(shí)檢測(cè)。我一朋友在生產(chǎn)環(huán)境做過(guò)一次誤刪操作明明磁盤空間已經(jīng)空出來(lái)一大半FastDFS卻還在報(bào)警說(shuō)空間不足直到重啟了Storage才恢復(fù)正常。所以推薦在存儲(chǔ)節(jié)點(diǎn)上做定期的df檢查并且配置監(jiān)控告警不要依賴存儲(chǔ)進(jìn)程自報(bào)的數(shù)字做唯一判斷。第三個(gè)坑是組內(nèi)主備切換時(shí)的文件沖突。如果同組內(nèi)的兩臺(tái)Storage因?yàn)榫W(wǎng)絡(luò)分區(qū)導(dǎo)致暫時(shí)失聯(lián)各自又都接受了一部分寫請(qǐng)求那么恢復(fù)連接后兩邊會(huì)產(chǎn)生同一文件ID的不同版本。FastDFS的同步機(jī)制默認(rèn)以后寫入為準(zhǔn)也就是說(shuō)后落盤的那份會(huì)被保留先寫的那份被覆蓋。這類問(wèn)題雖然罕見(jiàn)但在雙機(jī)房跨專線場(chǎng)景下確實(shí)可能發(fā)生。我個(gè)人的應(yīng)對(duì)方案是盡量把同一個(gè)組的Storage放在同一個(gè)機(jī)架或同一局域網(wǎng)內(nèi)避免引入跨地域的網(wǎng)絡(luò)因素。再說(shuō)說(shuō)調(diào)優(yōu)。Tracker端的性能優(yōu)化最重要的一個(gè)參數(shù)是max_connections這個(gè)值代表了Tracker能同時(shí)維持的連接數(shù)上限默認(rèn)比較保守。如果客戶端數(shù)量多建議調(diào)高同時(shí)把操作系統(tǒng)層的文件描述符上限也一并改掉否則連接數(shù)到了上限再新的請(qǐng)求就只能排隊(duì)等待。Storage端的調(diào)優(yōu)重點(diǎn)則在磁盤IO調(diào)度上FastDFS大量使用隨機(jī)小文件讀寫所以強(qiáng)烈建議用SSD而非機(jī)械盤來(lái)存文件機(jī)械盤在文件量上來(lái)以后讀取速度衰減非常明顯這在文件數(shù)量幾十萬(wàn)時(shí)還看不出差別到了千萬(wàn)級(jí)以后就是兩個(gè)世界。配置方面的調(diào)優(yōu)還有一個(gè)精妙之處Tracker的store_lookup策略默認(rèn)是選擇剩余空間最大的組但你可以把它改成輪詢模式。輪詢模式的好處是寫入壓力會(huì)均勻分散到各個(gè)組而不是總往那一個(gè)剩余空間最大的組擠這在多個(gè)組存儲(chǔ)容量差不多的場(chǎng)景下更合理。缺點(diǎn)是如果各組的物理容量差異很大輪詢模式反而可能導(dǎo)致小容量組提前寫滿。所以調(diào)整這個(gè)參數(shù)前先看清楚你的組間容量是否接近不要盲目照搬別人的配置。日志這塊雖然不起眼但排查問(wèn)題時(shí)價(jià)值巨大。FastDFS默認(rèn)日志級(jí)別是INFO生產(chǎn)環(huán)境建議調(diào)整成WARN一是降低磁盤寫入壓力二是日志量少了后真正重要的問(wèn)題反而更容易被發(fā)現(xiàn)。同步失敗、節(jié)點(diǎn)離線這類關(guān)鍵事件WARN級(jí)別都會(huì)記錄不用擔(dān)心漏掉。我在一次故障排查中就是靠Storage的日志確認(rèn)了一臺(tái)備節(jié)點(diǎn)的binlog同步位置偏移然后手動(dòng)觸發(fā)了全量補(bǔ)傳否則數(shù)據(jù)缺口還不知要拖到什么時(shí)候。還有一點(diǎn)容易被忽視但真的很關(guān)鍵FastDFS集群內(nèi)部的網(wǎng)絡(luò)帶寬。因?yàn)榻M內(nèi)互備是全量同步文件總量越大帶寬占用越高。如果同一批文件上傳寫入量很大同步流量會(huì)跟業(yè)務(wù)流量搶帶寬導(dǎo)致用戶訪問(wèn)變慢。我建議Storage節(jié)點(diǎn)之間用獨(dú)立網(wǎng)卡或者至少劃分獨(dú)立的VLAN條件允許的話直接千兆起步萬(wàn)兆更好。否則文件量增長(zhǎng)到一定程度你會(huì)在深夜發(fā)現(xiàn)明明沒(méi)什么用戶訪問(wèn)網(wǎng)絡(luò)卻打著滿屏原因就是后臺(tái)同步在做全量追平。7. 寫在最后的選型與維護(hù)建議關(guān)于FastDFS值不值得用我的立場(chǎng)是它是一個(gè)性價(jià)比極高的小型私有化文件存儲(chǔ)方案但它不適合所有人。如果你的團(tuán)隊(duì)沒(méi)有人愿意承擔(dān)維護(hù)一套自建文件系統(tǒng)的責(zé)任那直接用對(duì)象存儲(chǔ)云產(chǎn)品會(huì)更省心如果能找到人維護(hù)并且對(duì)數(shù)據(jù)私密性有要求FastDFS就是一條投入小、回報(bào)穩(wěn)的路。維護(hù)層面我建議至少投入一個(gè)人來(lái)負(fù)責(zé)這臺(tái)系統(tǒng)的日常觀察。FastDFS的控制面沒(méi)有真正意義上的可視化面板最多通過(guò)命令查看節(jié)點(diǎn)狀態(tài)和同步進(jìn)度所以監(jiān)控告警一定得靠外掛——用市面上主流的監(jiān)控系統(tǒng)去盯各節(jié)點(diǎn)的進(jìn)程存活、端口連通、磁盤使用率。我自己用的是文本形式的腳本加企業(yè)微信告警的組合每晚跑一遍狀態(tài)檢查有異常直接推給值班手機(jī)兩年下來(lái)基本沒(méi)有出過(guò)大事故。如果項(xiàng)目接下來(lái)有上云或者切換存儲(chǔ)形態(tài)的打算也不用慌。FastDFS的文件ID結(jié)構(gòu)是自包含的導(dǎo)出數(shù)據(jù)時(shí)只要把每個(gè)文件ID補(bǔ)全成完整的URL生成一個(gè)清單換到其他存儲(chǔ)服務(wù)時(shí)照著清單重新拉取一遍即可。我做過(guò)一次從FastDFS遷到另一套自建對(duì)象存儲(chǔ)的實(shí)踐整個(gè)過(guò)程最耗時(shí)的反而不是數(shù)據(jù)遷移而是清洗庫(kù)里幾十億條文件ID中那些過(guò)期無(wú)用數(shù)據(jù)這讓我意識(shí)到一個(gè)道理跟存儲(chǔ)系統(tǒng)的兼容性相比數(shù)據(jù)的生命周期治理才是真正的大工程。這個(gè)教訓(xùn)希望你在設(shè)計(jì)自己的業(yè)務(wù)表結(jié)構(gòu)時(shí)就能提前留個(gè)心眼。