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