圖片伺服器應該如何設計文件結構？
01-11
一般如何設計文件結構？文件命名規則是什麼？這樣設計出於什麼樣的考慮？
謝邀. 其實我沒有專業做過圖片的伺服器, 只做過通用的對象存儲. 簡單說一下個人理解吧.
做為使用最廣泛, 最最基礎的圖床服務, 業界幾乎每家大點的公司可能都有自己的解決方案.
具體到某一家廠商, 對於圖片存儲的需求的層次 決定 圖片服務系統設計的結構, 簡要的分幾個層次吧:
初級: 還有些人在乎的中小網站.
圖片偏多, 需要簡單的組織和管理.
一般可能還是把圖片存儲到文件系統裡面 按照目錄+ 文件的組織形式. 本地 或者 NFS 的文件系統裡面, 這裡是我理解的一些小點:- 不要使用中文, 空格, 特殊字元...之類的做文件名!!!
- 對於UGC網站, 不拿用戶上傳的圖片文件名做為文件名直接存儲.
- 用戶的文件名會各種不規範, 容易有衝突, 另外存起來.
- 按 時間 / 用戶 等業務邏輯做目錄的劃分.
- 更利於組織和管理, 避免衝突文件名導致覆蓋(用戶頭像存儲等Case).
- 也避免一個目錄下文件過多, 導致查詢性能
- 必要時可能要多級的目錄.
- 避免過長的文件名.
- 避免修改文件內容
- 修改後的圖片存為另一個圖片
- 為縮略圖做預處理
- 最好是就只用特定的幾個尺寸.
- 不能滿足需求的話, 可以預存大, 中, 小, 原圖等幾個級, 其他尺寸由鄰近級去實時轉換.
- 不同尺寸的文件, 而且大小之間可以相互換算.
- Eg: 圖片大小命名的目錄.
- 不要用連續遞增的數字做文件id
- 避免圖片被直接遍歷爬走了
- logo 等常用圖片獨立存儲.
- 避免文件路徑的變更.
- 各處本地緩存, 引用 都會失效...
中級: 適合較大型的網站
普通的文件系統已經不能很好滿足需求了:- 運維管理的考慮
- 超過單機的容易, 多機來存儲導致各種圖片的增減, 管理成本非常的大
- 性能的考慮
- 文件系統的開銷過大
- 多次的IO和網路交互
- 成本的考慮
- 容災的考慮
這個一般使用 通用的對象存儲, 類似S3的服務, 會增加一些CDN之類的.
在組織管理這一塊, 雖然不再是本地的文件系統, 但是原理和想法 和 前面基本一樣.高級: 適合大型的網站
相對於更強調通用性和業務靈活性的S3存儲服務, 圖片服務的文件名一般都是專有的規則, 因為就這個單一的服務就已經足夠的大, 值得去做一些專門的定製和優化.
比如說:- 存儲信息直接Encode進文件名, 省去文件名到存儲路徑的查詢.
- 更好的緩存支持, CDN的調度
- 極端熱點的處理
- 冷數據的淘汰和Archive
- 專門的硬體支持 (針對圖片訪問特別的機器定製.)
- ...
國內做得比較好的分享應該是 章文嵩 博士的. 詳見:
揭秘淘寶286億海量圖片存儲與處理架構-IT168 存儲專區 和 淘寶圖片存儲與CDN系統
國外的如Facebook的Haystack的設計.
http://www.stanford.edu/class/cs240/readings/haystack.pdf 和 https://www.facebook.com/note.php?note_id=76191543919好吧, 先就想到這麼多了.推薦掃兩眼FastDFS的文檔, 從架構上如何動態擴展, 如何提高存儲性能, 如何設計目錄, 如何獲得文件名等等 這些問題怎麼處理就都懂了.
這是一個非常輕量級的DFS, 專為圖片和小文件的分散式集群存儲來設計的, 也就是題主說的圖片伺服器, 以前我們項目的圖片伺服器也用到過 非常簡潔易用.- 按 時間 / 用戶 等業務邏輯做目錄的劃分.
- 更利於組織和管理, 避免衝突文件名導致覆蓋(用戶頭像存儲等Case).
- 也避免一個目錄下文件過多, 導致查詢性能
- 必要時可能要多級的目錄.
推薦閱讀：