# Pixable Architecture-每天對 2000 萬張照片進行爬網，分析和排名 > 原文： [http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html](http://highscalability.com/blog/2012/2/21/pixable-architecture-crawling-analyzing-and-ranking-20-milli.html) *這是 Pixable 的 CTO PHD 的 Alberto Lopez Toledo 和 Pixable 的工程副總裁 Julio Viera 的來賓帖子。*  [可混合](http://new.pixable.com/)匯總來自您不同社交網絡的照片，并找到最佳照片，因此您永遠不會錯過重要時刻。 這意味著當前每天要處理超過 2000 萬張新照片的元數據：對它們以及已經存儲在我們數據庫中的其他 5+十億張圖像進行爬網，分析，排名和排序。 弄清所有數據都面臨挑戰，但尤其要強調兩個挑戰： 1. 如何每天以最有效的方式從 Facebook，Twitter，Instagram 和其他服務訪問數百萬張照片。 2. 如何處理，組織，索引和存儲與那些照片相關的所有元數據。 當然，Pixable 的基礎架構正在不斷變化，但是去年我們學到了一些東西。 因此，我們已經能夠構建可擴展的基礎架構，以利用當今的工具，語言和云服務，所有這些都在 Amazon Web Services 上運行，其中我們有 80 多個服務器在運行。 本文檔簡要介紹了這些課程。 ## 后端架構-一切都會發生 ### 基礎架構-喜歡 Amazon EC2 我們使用 CentOS Linux，使用從 t1.micro 到 m2.2xlarge 的各種實例在 Amazon EC2 上維護所有服務器。 設置服務器后，我們將創建自己的內部 AMI（每種類型的服務器一個）。 我們總是準備好在負載增加時立即部署它們，從而始終保持最低性能標準。 為了補償這些負載波動，我們開發了自己的自動伸縮技術，該技術可以根據一天中特定時間的當前和歷史負載來預測每種類型的服務器數量。 然后，我們啟動或終止實例只是為了保持正確的配置水平。 這樣，我們就可以通過在不需要服務器時縮減服務器規模來節省資金。 在亞馬遜中自動縮放并非易事，因為要考慮許多變量。 例如：由于 Amazon 會收取整個小時的費用，因此終止僅運行了半個小時的實例是沒有意義的。 此外，亞馬遜可能需要 20 多分鐘才能啟動即時實例。 因此，對于流量的突然激增，我們對按需實例（啟動速度更快）進行了一些巧妙的啟動調度，然后在接下來的一個小時內將它們替換為現場實例。 這是純粹的運營研究的結果，其目的是為了以適當的金額獲得最佳性能。 可以把它想像成電影《 Moneyball》，但它帶有虛擬服務器而不是棒球運動員。 我們的 Web 服務器當前運行 Apache + PHP 5.3（最近我們一直在微調一些 Web 服務器以運行 nginx + php-fpm，它將很快成為我們的標準配置）。 這些服務器平均分布在 Amazon Elastic Load Balancer 后面的不同可用性區域中，因此我們可以吸收 Amazon 的停機時間和價格波動。 我們的靜態內容存儲在 Amazon Cloud Front 上，并且我們將 Amazon Route 53 用于 DNS 服務。 是的，確實……我們愛亞馬遜。 ### 工作隊列-用于抓取照片并對其進行排名，發送通知等的工作 實際上，Pixable 的所有處理都是通過異步作業完成的（例如，從 Facebook 抓取來自不同用戶的新照片，發送推送通知，計算朋友排名等）。 我們有數十個工作服務器，它們從不同服務的照片中抓取元數據并處理該數據。 這是一個連續的，全天候的過程。 不出所料，我們有不同類型的工作：一些優先級高的工作，例如實時用戶呼叫，消息收發以及為當前活動用戶抓取照片。 優先級較低的作業包括脫機爬網和長時間的數據密集型延遲任務。 盡管我們使用功能強大的 [beantalkd](http://kr.github.com/beanstalkd/) 作為我們的作業隊列服務器，但我們在其之上開發了自己的管理框架。 我們將其稱為自動駕駛儀，它會自動管理優先級的處理，例如 通過將作業服務器時間用于高優先級作業，并在滿足平臺范圍的某些條件時暫停低優先級作業。 我們開發了非常復雜的規則來處理這些優先級，同時考慮了影響系統性能和影響用戶感知速度的指標。 有些是顯而易見的，例如作業的平均等待時間或從屬服務器的滯后時間（ssshhh，我們從不滯后于從屬服務器:-)），而更復雜的指標則是分布式分布式 PHP 同步互斥鎖的狀態。 環境。 我們會盡力在效率和績效之間做出公平的權衡。 ### 抓取引擎-在 Facebook，Twitter 等 24/7 上抓取新照片 我們一直在不斷改進抓取技術，這是一種復雜的并行算法，它使用內部開發的互斥鎖庫來為特定用戶同步所有進程。 自推出以來，該算法已幫助我們將 Facebook 的抓取速度提高了至少 5 倍。 現在，我們每天可以輕松獲取超過 2000 萬張新照片。 考慮到事實上，對 [Facebook API](http://developers.facebook.com/) 的任何大數據查詢都可能需要幾秒鐘的時間，因此這是非常出色的。 我們將在一個輔助文檔中更深入地了解我們的抓取引擎。 ### 數據存儲-索引照片和元數據 自然，我們的數據存儲每天都在增長。 目前，我們使用兩組服務器將 90％的數據存儲在 MySQL 中（其頂部是 memcached 層）。 第一組是 2 主 2 從配置，該配置存儲幾乎每個系統訪問的更規范化的數據，例如用戶配置文件信息，全局類別設置和其他系統參數。 第二個服務器組包含手動分片服務器，我們在其中存儲與用戶照片有關的數據，例如照片 URL。 此元數據已高度反規范化，以至于我們實際上僅以 MySQL 表（NoSQL-in-MySQL）的形式將存儲作為 NoSQL 解決方案（如 MongoDB）運行。 因此，您可以猜測其他 10％的數據存儲在什么地方，對嗎？ 是的，在 MongoDB 中！ 我們將部分存儲移至 MongoDB，主要是因為它提供了簡單靈活的分片和復制解決方案。 ### 記錄，分析和分析 我們開發了高度靈活的日志記錄和性能分析框架，該框架使我們能夠以高粒度記錄事件-只需一行代碼。 每個日志事件均按一組我們稍后查詢的標簽進行分類（例如，用戶 X 的事件或模塊 Y 中的調用）。 最重要的是，我們可以動態地分析任何日志記錄事件之間的時間，從而使我們能夠構建整個系統的實時性能分析。 日志記錄和概要分析系統在存儲系統上的負擔非常重（每秒數千次更新），因此我們開發了兩級 MySQL 表（基于內存的快速緩沖區，用作實際數據的泄漏存儲區）的混合體 存儲），再結合一些分區的 MySQL 表，這些表稍后會異步填充。 這種架構使我們每秒可以處理 15,000 多個日志條目。 我們還擁有自己的事件跟蹤系統，其中記錄了從登錄到共享到單個點擊的每個用戶操作，以便以后可以使用復雜的查詢進行分析。 我們還嚴重依賴于出色的 [Mixpanel](http://www.mixpanel.com/) 服務，這是一個基于事件的跟蹤系統，我們在其中執行大部分高級分析和報告。 ## 前端-簡單的可視化設備 Pixable 可在多個（前端）設備中運行，最受歡迎的設備是 iPhone 和 iPad。 我們也有加載簡單索引頁的 Web 和移動 Web 站點，其他所有操作都通過廣泛使用 jQuery 和 Ajax 調用在客戶端中執行。 我們所有的 Web 前端都將很快運行一個可自動適應移動或桌面屏幕的代碼庫（嘗試一下！ [http://new.pixable.com](http://new.pixable.com/) ）。 這樣，我們可以在我們的主站點，Android 設備或 Chrome 瀏覽器擴展程序上運行相同的代碼！ 實際上，我們的 Android 應用是原生應用和我們的移動網絡前端的結合。 Android 應用程序使用最少的控件來渲染框架，并僅在其中顯示移動 Web 視圖。 聽起來有些刺耳，但是我們所有的前端都是“啞巴”。 所有繁重的工作都在后端執行，所有事情都通過我們自己的私有 API 連接。 這使我們能夠快速進行開發和部署，而不必更改已安裝的用戶群。 敏捷，寶貝！ ## API-連接我們的前端和后端 API 是使一切保持協同工作的粘合劑。 使用 [Tonic PHP](http://peej.github.com/tonic/) ，我們開發了自己的私有 RESTful API，該 API 公開了我們的后端功能。 另外，我們擴展了 [Tonic](http://peej.github.com/tonic/) ，使其支持內置版本控制。 這樣一來，在開發新功能或更改 API 中的響應格式時，我們很容易保持向后兼容性。 我們只配置哪個設備版本支持哪些版本的 API 調用。 無論版本多舊，我們都有不留設備的政策！ 但是 API 并沒有做任何實際的工作。 它僅依賴于來自前端的信息，并將其傳遞給實際的 Pixable 心臟：后端。 每天排名 2000 萬張照片？ 真的很棒 值得讀。 謝謝你的好文章。