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