中等規(guī)模網(wǎng)站的UGC圖片存放規(guī)劃

　　先聲明，本文借鑒了很多劉濤(Tarkus)和 Druggo Yang 的實戰(zhàn)經(jīng)驗，特此感謝

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

　　我對中等的定義：圖片所占空間在 1T – 數(shù)十 T 之間。

　　功能需求

　　基本的就兩點(diǎn)：排除重復(fù)，和可擴(kuò)展性。

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

　　具體設(shè)計

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

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

　　文件就是整個 ID 的補(bǔ)零切三段，如 12345 保存為實際的文件 /upload/000/012/345，不保留擴(kuò)展名，統(tǒng)一發(fā)送 Header Content-Type application/octet-stream

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

　　調(diào)優(yōu)

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

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

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

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

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

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

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

　　至于縮略圖接口，另算

　　應(yīng)用特例：頭像

　　其實每個網(wǎng)站都有的圖片機(jī)制是頭像，現(xiàn)在普遍的規(guī)則是用戶 ID + 補(bǔ)碼，補(bǔ)碼可以是更新次數(shù)(如 douban)、時間戳(如 t.sina)、文件名(如 twitter)之類的。補(bǔ)碼的主要目的是為了靠改變 URL 而繞開 Header Expires

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

　　問題

　　再次強(qiáng)調(diào)，這僅僅是個例子，針對每個網(wǎng)站、每個應(yīng)用的需求，方案也是千變?nèi)f化的。大家都有各自關(guān)注的重點(diǎn)。

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

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

　　來源：http://soulogic.com/blog/archives/407.html

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈