正如預期的那樣，我們有各種不同類型的工作：有些需要較高的優(yōu)先級，如用戶時時的通話，短消息，以及抓取當前活動用戶的圖片。低優(yōu)先級的工作包括：抓取離線用戶的圖片，以及長期的數(shù)據(jù)加強延遲工作。盡管我們使用了非常強大的beanstalke作為工作隊列服務，但我們依然在他之上開發(fā)了管理框架。我們稱之為Auto-Pilot（自動領(lǐng)航員），他能夠自動管理優(yōu)先權(quán)，將系統(tǒng)資源交給高權(quán)限的工作，并停止優(yōu)先權(quán)低的工作。
我們開發(fā)了非常復雜的優(yōu)先權(quán)處理規(guī)則，同時考慮到系統(tǒng)性能和用戶體驗。一些指標很容易衡量，比如工作的平均等待時間，系統(tǒng)主從服務器之間的延遲時間等（我們從來沒有延遲）。更多的是一些復雜的指標，如我們自己的PHP同步互斥的狀態(tài)的分布式鎖環(huán)境。我們盡可能的在性能和效率間做出公平的權(quán)衡。
抓取引擎-通過Facebook、Twitter和其他全天候的網(wǎng)站抓取新圖片
我們內(nèi)部不斷的提高抓取技術(shù)，這是一種復雜的并行算法，通過互斥鎖庫，同步特定用戶的所有進程。這種算法幫我們在Facebook上抓取圖片的速度提高了至少5倍?，F(xiàn)在，每天我們可以很容易地獲取超過20萬張新圖片。 這是相當了不起的，事實上，任何對Facebook API的大型數(shù)據(jù)請求只能持續(xù)幾秒鐘。在正文后附屬文件會深入探討我們的抓取引擎。
數(shù)據(jù)存儲-對圖片和元數(shù)據(jù)進行索引
目前，90%的數(shù)據(jù)通過MySQL存儲（在一個分布式緩存在其之上建立）在兩組服務器上。第一組采用2主2從設計，存儲那些規(guī)則的數(shù)據(jù)，如用戶的信息、全球分類設置和其他系統(tǒng)參數(shù)。
第二組包含手動共享服務器，用來存儲用戶圖片的相關(guān)信息，如圖片的URL地址。這部分數(shù)據(jù)是高度非標準化的，僅在MySQL表中（NoSQL在MySQL中）我們采用了NoSQL方案，如MongoDB。所以，另外10%的數(shù)據(jù)通過MongoDB存儲！我們正在部分的遷移到MongoDB，主要因為其簡單且靈活，并提供分區(qū)和重寫（sharding and replication）功能。
日志，剖析和分析
我們開發(fā)了高度靈活的日志和剖析框架，允許日志高粒度且細化到每行代碼。每個事件日志都被按照標簽分類供以后查詢（例如用戶X的事件，或者在模塊Y調(diào)用）。重要的是，我們能動態(tài)的分析某一時間點的所有日志事件，建立整個系統(tǒng)的實時分析。日志和分析系統(tǒng)對存儲系統(tǒng)的壓力非常大（每秒鐘數(shù)千次更新），所以我們將兩個級別的MySQL表結(jié)合在一起（一個基于內(nèi)存的快速緩存，對實時數(shù)據(jù)而言服務器就像一個有遺撒的桶），并結(jié)合一些分離的MySQL表（稍后數(shù)據(jù)將異步到表中）。這個架構(gòu)每秒可處理超過1.5萬條日志。我們有自己的事件跟蹤系統(tǒng)，包括每個用戶從登錄到分享到個性化的點擊，我們可以在以后查詢分析這些復雜記錄行動。
我們也依賴出色的Mixpanel服務，幫我們完成高標準的分析和報告。
前端 - 簡單的可視化設備
Pixable可在各種（前端）設備上運行，如iPhone和iPad。我們也有網(wǎng)頁版和移動網(wǎng)頁版，他們只讀取一個簡單的網(wǎng)頁，剩下的任務全部交給客戶端的jQuery和Ajax完成。很快，我們所有的網(wǎng)站前端將運行一個單一的代碼庫，自動適應移動或桌面屏幕（請嘗試 http://new.pixable.com ）。這樣，我們可以在主要網(wǎng)站上使用相同的代碼，包括在Android設備和Chrome瀏覽器的擴展。事實上，我們的Android版App結(jié)合了移動web前端程序。Android版App申請最小的框架控制權(quán)，并在其中顯示移動web的內(nèi)容。
這聽起來有點苛刻，但我們所有的前端是“啞巴”。 所有繁重的任務通過我們自己的私有API連接在后臺執(zhí)行。 這使我們能夠快速開發(fā)和部署，而無需改變已有的用戶基礎(chǔ)。 靈活的，寶貝！