這篇文章主要介紹了Instagram網(wǎng)站的圖片存儲(chǔ)架構(gòu),主要由Python的Django驅(qū)動(dòng)的Instagram后臺(tái)在PostgreSQL和Redis數(shù)據(jù)存儲(chǔ)的使用方面同樣亮點(diǎn)頗多,需要的朋友可以參考下

被Facebook以10億美金收購(gòu)的著名手機(jī)照片分享應(yīng)用Instagram最近吸引了無數(shù)人的眼球，Instagram聯(lián)合創(chuàng)始人Mike Krieger說他們用了8周時(shí)間打造了最初的Instagram，但現(xiàn)在的系統(tǒng)肯定已經(jīng)今非昔比。Instagram技術(shù)團(tuán)隊(duì)曾發(fā)表過一篇文章，介紹了Instagram背后的技術(shù)，日前Mike Krieger在名為Scaling Instagram的演講里，又介紹了更多細(xì)節(jié)，讓人們能了解到5名技術(shù)人員是如何支撐起整個(gè)系統(tǒng)的。

一張照片上傳的過程是這樣的：

1.采用同步的方式寫入媒體數(shù)據(jù)庫(kù)

2.如果照片上有地理位置標(biāo)簽，則以異步的方式將照片提交給Solr進(jìn)行索引

3.將照片的ID加入每個(gè)關(guān)注者的列表里，該列表保存在Redis之中

4.在顯示Feed時(shí)，選取一小部分照片ID，在Memcached里進(jìn)行查詢

5.在設(shè)計(jì)系統(tǒng)時(shí)，Instagram的設(shè)計(jì)哲學(xué)是簡(jiǎn)單、為最小化運(yùn)維負(fù)擔(dān)進(jìn)行優(yōu)化并監(jiān)控一切內(nèi)容;其核心原則是保持簡(jiǎn)單，不要重復(fù)發(fā)明輪子，盡可能使用經(jīng)過驗(yàn)證、穩(wěn)定可靠的技術(shù)。

由于只有5名技術(shù)人員(其中僅2.5名后端工程師)，精力有限，選擇Amazon的云服務(wù)是個(gè)不錯(cuò)的選擇。目前他們使用了超過100個(gè)EC2實(shí)例用于提供各種服務(wù)，運(yùn)行的操作系統(tǒng)是Ubuntu 11.04，之前的一些版本在高流量時(shí)表現(xiàn)不夠穩(wěn)定。在負(fù)載均衡方面，他們使用Amazon的Elastic Load Balancer實(shí)現(xiàn)負(fù)載均衡，后端運(yùn)行了3個(gè)Nginx實(shí)例，SSL只到ELB上為止，降低了Nginx上的CPU負(fù)載。DNS和CDN分別由Amazon的Route 53和CloudFront提供，所有的照片都存放在S3上，目前已經(jīng)有幾TB的規(guī)模了。

用于處理請(qǐng)求的應(yīng)用服務(wù)器運(yùn)行于Amazon High-CPU Extra-Large Instance之上，由于他們的請(qǐng)求更多是CPU密集型的，因此這能更好地平衡CPU與內(nèi)存。采用的開發(fā)框架是Django，WSGI服務(wù)器是Gunicorn，通過Fabric在所有機(jī)器上進(jìn)行并行部署，一次部署僅需幾秒鐘。

用戶信息、圖片元數(shù)據(jù)、標(biāo)簽等大部分?jǐn)?shù)據(jù)存儲(chǔ)在 PostgreSQL 中。

實(shí)踐中發(fā)現(xiàn) Amazon 的網(wǎng)絡(luò)磁盤系統(tǒng)單位時(shí)間內(nèi)尋道能力不行，所以有必要將數(shù)據(jù)盡量放到內(nèi)存中。創(chuàng)建了軟 RAID 以提升 IO 能力，使用的 Mdadm 工具進(jìn)行 RAID 管理。

管理內(nèi)存中的數(shù)據(jù)，vmtouch 這個(gè)小工具值得推薦。

PostgreSQL 設(shè)置為 Master-Replica 方式，流復(fù)制模式。利用 EBS 的快照進(jìn)行數(shù)據(jù)庫(kù)備份。使用 XFS 文件系統(tǒng)，以便和快照服務(wù)充分配合。 使用 repmgr 這個(gè)小工具做 PostgreSQL 復(fù)制管理器器。

連接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 數(shù)據(jù)庫(kù)的信息。

應(yīng)用程序在連接數(shù)據(jù)庫(kù)時(shí)，由Pgbouncer建立連接池。目前，Instagram的數(shù)據(jù)按照用戶ID進(jìn)行分片，某些分片可能會(huì)超出物理節(jié)點(diǎn)的容量上限，為此他們將數(shù)據(jù)分成了很多個(gè)邏輯分片，映射到少數(shù)幾個(gè)物理節(jié)點(diǎn)之上;當(dāng)一個(gè)節(jié)點(diǎn)被填滿之后，可以將某些邏輯分片移到別的節(jié)點(diǎn)上，以緩解該節(jié)點(diǎn)的壓力。隨著數(shù)據(jù)量的增長(zhǎng)，以后他們也會(huì)進(jìn)行垂直分區(qū)，Django DB Router能讓一切輕松不少。

Instagram也大量使用Redis來存放復(fù)雜的對(duì)象(對(duì)象的大小做了一定的限制)，用于主Feed、活動(dòng)Feed、會(huì)話系統(tǒng)及其他相關(guān)系統(tǒng)。因?yàn)橐獙edis的所有數(shù)據(jù)都放在內(nèi)存里，此處同樣也用了High-Memory Quadruple Extra-Large Instance，并對(duì)數(shù)據(jù)做了分片。當(dāng)Redis實(shí)例的請(qǐng)求達(dá)到4萬/秒后，它漸漸成為了瓶頸，于是Redis也做了主從復(fù)制，副本的數(shù)據(jù)會(huì)經(jīng)常導(dǎo)出到磁盤上，通過EBS快照進(jìn)行備份。

除了Redis，他們還使用Memcached來做緩存，目前運(yùn)行了6個(gè)實(shí)例，應(yīng)用服務(wù)器通過pylibmc和libmemcached進(jìn)行連接。雖然Amazon提供了Elastic Cache服務(wù)，但該服務(wù)的價(jià)格并不便宜，相比之下，還是運(yùn)行自己的Memcached實(shí)例比較劃算。異步任務(wù)隊(duì)列使用的是Gearman，目前有大約200個(gè)工作進(jìn)程來處理各種任務(wù)，比如把照片分享到Twitter和Facebook，通知用戶有新照片等等。Pyapns已經(jīng)處理了十億的推送通知，非常穩(wěn)定，他們還自己開發(fā)了基于Node.js的node2dm，用于向Android設(shè)備發(fā)送推送通知。

監(jiān)控方面，Instagram使用Munin以圖形化的方式呈現(xiàn)整個(gè)系統(tǒng)的運(yùn)行狀況，還通過Python-Munin定制了一些插件，用來顯示業(yè)務(wù)數(shù)據(jù);網(wǎng)絡(luò)守護(hù)進(jìn)程Stated可以實(shí)時(shí)收集數(shù)據(jù)并做匯總;Dogslow會(huì)監(jiān)控進(jìn)程，一旦發(fā)現(xiàn)運(yùn)行時(shí)間過長(zhǎng)的進(jìn)程，便會(huì)保存該進(jìn)程的快照，以便后續(xù)分析，比如響應(yīng)時(shí)間超過1.5秒的請(qǐng)求，通常都是卡在Memcached的set()和get_many()方法上。對(duì)于Python的錯(cuò)誤，只要登上Sentry就能實(shí)時(shí)獲取錯(cuò)誤信息。

HighScalability上還根據(jù)整理Instagram團(tuán)隊(duì)軟件工程師Mike Krieger的演講整理了一些值得借鑒的經(jīng)驗(yàn)，比如：

1.找那些你熟悉的技術(shù)和工具，在簡(jiǎn)單的使用場(chǎng)景里先做一些嘗試

2.不要使用兩個(gè)工具來處理同樣的任務(wù)

3.事先準(zhǔn)備降級(jí)方案，以便在需要時(shí)降低負(fù)載

4.不要過度優(yōu)化，或者希望能事先知道站點(diǎn)要擴(kuò)展，對(duì)于一個(gè)初創(chuàng)的社交站點(diǎn)而言，沒什么擴(kuò)展性問題是解決不了的

5.如果一個(gè)辦法不行，趕快換下一個(gè)