被Facebook以10億美金收購的著名手機照片分享應用Instagram最近吸引了無數人的眼球，Instagram聯合創始人Mike Krieger說他們用了8周時間打造了最初的Instagram，但現在的系統肯定已經今非昔比。Instagram技術團隊曾發表過一篇文章，介紹了Instagram背后的技術，日前Mike Krieger在名為Scaling Instagram的演講里，又介紹了更多細節，讓人們能了解到5名技術人員是如何支撐起整個系統的。

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

1.采用同步的方式寫入媒體數據庫
2.如果照片上有地理位置標簽，則以異步的方式將照片提交給Solr進行索引
3.將照片的ID加入每個關注者的列表里，該列表保存在Redis之中
4.在顯示Feed時，選取一小部分照片ID，在Memcached里進行查詢
5.在設計系統時，Instagram的設計哲學是簡單、為最小化運維負擔進行優化并監控一切內容；其核心原則是保持簡單，不要重復發明輪子，盡可能使用經過驗證、穩定可靠的技術。

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

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

用戶信息、圖片元數據、標簽等大部分數據存儲在 PostgreSQL 中。
實踐中發現 Amazon 的網絡磁盤系統單位時間內尋道能力不行，所以有必要將數據盡量放到內存中。創建了軟 RAID 以提升 IO 能力，使用的 Mdadm 工具進行 RAID 管理。
管理內存中的數據，vmtouch 這個小工具值得推薦。
PostgreSQL 設置為 Master-Replica 方式，流復制模式。利用 EBS 的快照進行數據庫備份。使用 XFS 文件系統，以便和快照服務充分配合。 使用 repmgr 這個小工具做 PostgreSQL 復制管理器器。
連接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 數據庫的信息。

應用程序在連接數據庫時，由Pgbouncer建立連接池。目前，Instagram的數據按照用戶ID進行分片，某些分片可能會超出物理節點的容量上限，為此他們將數據分成了很多個邏輯分片，映射到少數幾個物理節點之上；當一個節點被填滿之后，可以將某些邏輯分片移到別的節點上，以緩解該節點的壓力。隨著數據量的增長，以后他們也會進行垂直分區，Django DB Router能讓一切輕松不少。

Instagram也大量使用Redis來存放復雜的對象（對象的大小做了一定的限制），用于主Feed、活動Feed、會話系統及其他相關系統。因為要將Redis的所有數據都放在內存里，此處同樣也用了High-Memory Quadruple Extra-Large Instance，并對數據做了分片。當Redis實例的請求達到4萬/秒后，它漸漸成為了瓶頸，于是Redis也做了主從復制，副本的數據會經常導出到磁盤上，通過EBS快照進行備份。

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

監控方面，Instagram使用Munin以圖形化的方式呈現整個系統的運行狀況，還通過Python-Munin定制了一些插件，用來顯示業務數據；網絡守護進程Stated可以實時收集數據并做匯總；Dogslow會監控進程，一旦發現運行時間過長的進程，便會保存該進程的快照，以便后續分析，比如響應時間超過1.5秒的請求，通常都是卡在Memcached的set()和get_many()方法上。對于Python的錯誤，只要登上Sentry就能實時獲取錯誤信息。

HighScalability上還根據整理Instagram團隊軟件工程師Mike Krieger的演講整理了一些值得借鑒的經驗，比如：

1.找那些你熟悉的技術和工具，在簡單的使用場景里先做一些嘗試
2.不要使用兩個工具來處理同樣的任務
3.事先準備降級方案，以便在需要時降低負載
4.不要過度優化，或者希望能事先知道站點要擴展，對于一個初創的社交站點而言，沒什么擴展性問題是解決不了的
5.如果一個辦法不行，趕快換下一個