好像現在是個網站就允許用戶上傳頭像，其中一部分還允許上傳相冊、個性背景圖之類的東西。對圖片的規劃各村都有各村的高招，這里只是拋磚引玉、提個醒：當文件膨脹到一定規模的時候再去改就來不及了，在一個項目的草創時期，讓一個人多花兩個星期的時間來琢磨這個“小”問題也絕對稱不上是過度設計。

我對中等的定義：圖片所占空間在 1T - 數十 T 之間。

功能需求

基本的就兩點：排除重復，和可擴展性。

排重并不為很多人所重視，因為對很多人來說短期可以承受，實際經驗重復的占了 50%（一些流行的圖片會被重復上傳很多次），但問題是這里還關系到另外一件事：審核。例如一些很流行的黃圖會被頻繁的被不同人重復上傳，這也是不小的審核工作量。

具體設計

簡單的說就是 MySQL 單點來保證唯一，將文件 MD5 轉換為遞增ID，再將固定數量的文件分成組，例如最簡單的 MySQL 表可以這樣。

CREATE TABLE IF NOT EXISTS `upload_pic` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`hash` binary(16) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `hash` (`hash`)
) ENGINE=MyISAM DEFAULT CHARSET=ucs2 AUTO_INCREMENT=1;

每次有上傳，先 MD5、INSERT，成功就返回 ID，失敗就重新 SELECT 找以前的 ID

文件就是整個 ID 的補零切三段，如 12345 保存為實際的文件 /upload/000/012/345，不保留擴展名，統一發送 Header Content-Type application/octet-stream

首要原則是只新增，不改寫（除了審核后刪除的）

調優

上面所述只為了方便理解的最精簡的方案，還有很多事情可以做。

用于發號的 MySQL 僅僅是寫入單點，對于已經生成的 hash，可以定期生成 Archive 引擎 的只讀表。然后新上傳時以 SELECT/INSERT/SELECT 的順序獲取 ID（這時候，第三步的 SELECT 是極其罕見的）。

如果是 nfs 掛載，初期可以掛整個 /upload，后期可以以一級子目錄為單位，分散在不同機器上。如 /upload/001 和 /upload/002 掛在機器 A 上，諸如此類。這樣我們可以每 M 個圖片為一個掛載單位（下面簡稱 MU——Mounted Unit）。如果圖片的平均大小是 200K 左右，則每個 MU 的平均大小應該在 1M * 200K = 200G 左右。由于內容不再改寫，老的 MU 可以到處搬動、甚至分散到不同機房，其實是類似 flickr 的 farm*.static 子域名。

實際磁盤問題是個大問題，這方面網友 Druggo Yang 給了我很多經驗，他最早面臨的問題是大量隨機讀寫、幾乎沒熱點，大概是文件實在太碎，硬盤反倒在網卡之前成為瓶頸，銀彈是有：SSD，不過太tmd貴了。最后他們是用的 LVS，那已經是我知識體系以外的東西了。

我想到的解決方法被 Druggo Yang 評價為自己做軟 RAID：不同 MU 掛到不同盤，用 nginx 訪問，或者系統本身瓶頸，那就若干個 Server 有相同的 MU，做輪詢。但總之我不推薦做磁盤 RAID，這可能是我還沒搞明白，也可能真的如此，就拿最簡單的兩塊硬盤做 RAID 0 來說，按我的理解，每讀一個文件的時候，兩塊磁盤都需要定位，而兩塊獨立的磁盤卻可以分別各定位一個文件，據說也會受磁盤控制器的限制，但大體上不影響我的我的結論：RAID 的優勢應該在連續讀寫上，而隨機讀寫反而會因為短板效應而略微降低 IOPS。總之這問題我只能紙上談兵，有條件應該拿幾塊硬盤測一下的。

此外，諸如目錄分級是 1000 還是 100 個文件一組，還是用其他進制，都可以細測。記得以前看過一個單目錄文件數的 Benchmark，可惜后來再也找不到了（有誰能提示一下？），隱約記得 500 比較合適，因為這里需要頻繁手工搬動，索性就弄個人腦容易識別的數了

另外為了防止遍歷需要加個擾碼，這也很容易了。

至于縮略圖接口，另算

應用特例：頭像

其實每個網站都有的圖片機制是頭像，現在普遍的規則是用戶 ID + 補碼，補碼可以是更新次數（如 douban）、時間戳（如 t.sina）、文件名（如 twitter）之類的。補碼的主要目的是為了靠改變 URL 而繞開 Header Expires

但直到上家公司的產品部門在全面模仿 Facebook 運動中，想要實現 Facebook 里的一個功能：所有圖片的大一統，如新上傳的圖片進相冊、可以將任意一張圖片設為頭像，而收藏功能的流程跟自己上傳幾乎是一樣的，等等，雖然這個改動過于底層以至于辭職一年多后公司徹底黃掉也沒能看到它實現，但我還是很喜歡這個大一統的：不去考慮一張圖片被哪些地方引用，只管存就是了，而所有涉及到圖片的地方，都保存的是圖片 ID，因此只看某一張圖片的 URL，你不知道頭像的主人是誰：有可能其他人也用相同的圖片做頭像，或者在某人的相冊里。

問題

再次強調，這僅僅是個例子，針對每個網站、每個應用的需求，方案也是千變萬化的。大家都有各自關注的重點。

所有圖片都是不刪的，刪的只是針對圖片的引用頁而已，也就是說，如果一個人傳了幾張私人圖片、由自己刪除后，如果別人知道圖片 URL，則還是可以訪問的（或者更簡單的情況，某個被設置為限少數人訪問的相冊的圖片 URL 被公開），我不清楚實際運營時這個問題是否會很嚴重，總之不好回避。

對 MU 的調配是基于人工的，而不是任何高科技的自維護系統。老實說我認為就目前（2010 年）來說，除了 SSD 在某些特殊情況下能值回票價，其他的一些高科技玩意真的看不懂，我目前還很排斥云××類東西，不僅僅是貴，最主要的原因是，即使錢花到了，它們做的還沒說的那么好。一個外行可以把技術視為魔法和銀彈，但作為從業者，基本的問題是應該知道的，云存儲再牛逼，他也是跑在機械硬盤上的，而我們現有的工作，有很重要的一部分是在約定的系數下，加減成本和可靠性兩個指標，使其乘積最大。如果磁盤數量在可控范圍內，偶爾找人花幾個工時維護一下就夠，我相信普通的熱備就已經是好的選擇。除非容量已經上 PB 了，或者到了無緣無故的程度，可反過來說，那些魔法軟件又有多少 PB 級案例？總之云××可以等等，第一批沖上去的大都是炮灰。現階段我還是覺得每GB平均半毛錢不到的硬盤真他媽便宜好用