了解Instagram背后的技術(shù)
[丁雪豐 是InfoQ中文站編輯，滿江紅翻譯組核心成員，出版過《Spring攻略》、《JRuby實戰(zhàn)》等多部譯著。主要關(guān)注領(lǐng)域：企業(yè)級應(yīng)用、海量數(shù)據(jù)計算、動態(tài)語言應(yīng)用等。]
剛被Facebook以10億美金收購的著名手機照片分享應(yīng)用Instagram最近吸引了無數(shù)人的眼球，Android版本登陸Google Play不到一個月下載量就突破1000萬，總用戶數(shù)即將超過5000萬。Instagram聯(lián)合創(chuàng)始人Mike Krieger說他們用了8周時間打造了最初的Instagram，但現(xiàn)在的系統(tǒng)肯定已經(jīng)今非昔比。Instagram技術(shù)團隊曾發(fā)表過一篇文章，介紹了Instagram背后的技術(shù)，日前Mike Krieger在名為Scaling Instagram的演講里，又介紹了更多細節(jié)，讓人們能了解到5名技術(shù)人員是如何支撐起整個系統(tǒng)的。
一張照片上傳的過程是這樣的：
采用同步的方式寫入媒體數(shù)據(jù)庫
如果照片上有地理位置標(biāo)簽，則以異步的方式將照片提交給Solr進行索引
將照片的ID加入每個關(guān)注者的列表里，該列表保存在Redis之中
在顯示Feed時，選取一小部分照片ID，在Memcached里進行查詢
在設(shè)計系統(tǒng)時，Instagram的設(shè)計哲學(xué)是簡單、為最小化運維負擔(dān)進行優(yōu)化并監(jiān)控一切內(nèi)容;其核心原則是保持簡單，不要重復(fù)發(fā)明輪子，盡可能使用經(jīng)過驗證、穩(wěn)定可靠的技術(shù)。
由于只有5名技術(shù)人員(其中僅2.5名后端工程師)，精力有限，選擇Amazon的云服務(wù)是個不錯的選擇。目前他們使用了超過100個EC2實例用于提供各種服務(wù)，運行的操作系統(tǒng)是Ubuntu 11.04，之前的一些版本在高流量時表現(xiàn)不夠穩(wěn)定。在負載均衡方面，他們使用Amazon的Elastic Load Balancer實現(xiàn)負載均衡，后端運行了3個Nginx實例，SSL只到ELB上為止，降低了Nginx上的CPU負載。DNS和CDN分別由Amazon的Route 53和CloudFront提供，所有的照片都存放在S3上，目前已經(jīng)有幾TB的規(guī)模了。
用于處理請求的應(yīng)用服務(wù)器運行于Amazon High-CPU Extra-Large Instance之上，由于他們的請求更多是CPU密集型的，因此這能更好地平衡CPU與內(nèi)存。采用的開發(fā)框架是Django，WSGI服務(wù)器是Gunicorn，通過Fabric在所有機器上進行并行部署，一次部署僅需幾秒鐘。
大多數(shù)數(shù)據(jù)都存放在PostgreSQL里，主分片集群運行于12個High-Memory Quadruple Extra-Large Instance(68.4GB內(nèi)存)上，另有12個位于不同可用區(qū)里的副本，通過repmgr以Streaming Replication的方式進行同步。由于Elastic Block Store的磁盤IOPS不高，因此需要將正在使用的數(shù)據(jù)都加載到內(nèi)存里，vmtouch能幫助管理內(nèi)存中的數(shù)據(jù)。他們在EBS上使用mdadm實現(xiàn)了軟件Raid，以此提升寫吞吐量;數(shù)據(jù)庫的文件系統(tǒng)用的是XFS，在從庫獲取快照時，會先凍結(jié)RAID陣列，保證快照的一致性。
應(yīng)用程序在連接數(shù)據(jù)庫時，由Pgbouncer建立連接池。目前，Instagram的數(shù)據(jù)按照用戶ID進行分片，某些分片可能會超出物理節(jié)點的容量上限，為此他們將數(shù)據(jù)分成了很多個邏輯分片，映射到少數(shù)幾個物理節(jié)點之上;當(dāng)一個節(jié)點被填滿之后，可以將某些邏輯分片移到別的節(jié)點上，以緩解該節(jié)點的壓力。隨著數(shù)據(jù)量的增長，以后他們也會進行垂直分區(qū)，Django DB Router能讓一切輕松不少。
Instagram也大量使用Redis來存放復(fù)雜的對象(對象的大小做了一定的限制)，用于主Feed、活動Feed、會話系統(tǒng)及其他相關(guān)系統(tǒng)。因為要將Redis的所有數(shù)據(jù)都放在內(nèi)存里，此處同樣也用了High-Memory Quadruple Extra-Large Instance，并對數(shù)據(jù)做了分片。當(dāng)Redis實例的請求達到4萬/秒后，它漸漸成為了瓶頸，于是Redis也做了主從復(fù)制，副本的數(shù)據(jù)會經(jīng)常導(dǎo)出到磁盤上，通過EBS快照進行備份。
除了Redis，他們還使用Memcached來做緩存，目前運行了6個實例，應(yīng)用服務(wù)器通過pylibmc和libmemcached進行連接。雖然Amazon提供了Elastic Cache服務(wù)，但該服務(wù)的價格并不便宜，相比之下，還是運行自己的Memcached實例比較劃算。異步任務(wù)隊列使用的是Gearman，目前有大約200個工作進程來處理各種任務(wù)，比如把照片分享到Twitter和Facebook，通知用戶有新照片等等。Pyapns已經(jīng)處理了十億的推送通知，非常穩(wěn)定，他們還自己開發(fā)了基于Node.js的node2dm，用于向Android設(shè)備發(fā)送推送通知。
監(jiān)控方面，Instagram使用Munin以圖形化的方式呈現(xiàn)整個系統(tǒng)的運行狀況，還通過Python-Munin定制了一些插件，用來顯示業(yè)務(wù)數(shù)據(jù);網(wǎng)絡(luò)守護進程Stated可以實時收集數(shù)據(jù)并做匯總;Dogslow會監(jiān)控進程，一旦發(fā)現(xiàn)運行時間過長的進程，便會保存該進程的快照，以便后續(xù)分析，比如響應(yīng)時間超過1.5秒的請求，通常都是卡在Memcached的set()和get_many()方法上。對于Python的錯誤，只要登上Sentry就能實時獲取錯誤信息。
HighScalability上還根據(jù)整理Mike Krieger的演講整理了一些值得借鑒的經(jīng)驗，比如：
找那些你熟悉的技術(shù)和工具，在簡單的使用場景里先做一些嘗試
不要使用兩個工具來處理同樣的任務(wù)
事先準(zhǔn)備降級方案，以便在需要時降低負載
不要過度優(yōu)化，或者希望能事先知道站點要擴展，對于一個初創(chuàng)的社交站點而言，沒什么擴展性問題是解決不了的
如果一個辦法不行，趕快換下一個
如果您想進一步了解Instagram背后的技術(shù)細節(jié)，可以訪問其技術(shù)團隊的博客。
【編輯推薦】
