# AppLovin：通過每天處理 300 億個請求向全球移動消費者進行營銷 > 原文： [http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html](http://highscalability.com/blog/2015/3/9/applovin-marketing-to-mobile-consumers-worldwide-by-processi.html)  *這是來自 [AppLovin](http://www.applovin.com/) 的工程副總裁 [Basil Shikin](https://www.linkedin.com/in/basilshikin) 的來賓帖子，內容涉及其移動營銷平臺的基礎架構。 Uber，迪士尼，Yelp 和 Hotels.com 等主要品牌都使用 AppLovin 的移動營銷平臺。 每天處理 300 億個請求，每天處理 60 TB 的數據。* AppLovin 的營銷平臺為想要通過移動設備吸引消費者的品牌提供營銷自動化和分析。 該平臺使品牌商可以使用實時數據信號在全球十億移動消費者中做出有效的營銷決策。 # 核心統計信息 * 每天 300 億個廣告請求 * 每秒 300,000 個廣告請求，最高為每秒 500,000 個廣告請求 * 5 毫秒平均響應延遲 * 每秒 3 百萬個事件 * 每天處理 60TB 數據 * ?1000 臺服務器 * 9 個數據中心 * ?40 個報告維度 * 每分鐘 500,000 個指標數據點 * 1 Pb 火花簇 * 所有服務器上的峰值磁盤寫入速度為 15GB / s * 所有服務器上的峰值磁盤讀取速度為 9GB / s * AppLovin 成立于 2012 年，總部位于帕洛阿爾托，并在舊金山，紐約，倫敦和柏林設有辦事處。 # 技術堆棧 ## 第三方服務 * [Github](https://github.com/) 用于代碼 * [Asana](https://asana.com/) 用于項目管理 * [HipChat](https://www.hipchat.com/) 用于通信 ## 數據存儲 * [Aerospike](http://www.aerospike.com/) 用于用戶個人資料存儲 * [Vertica](http://www.vertica.com/) ，用于匯總統計信息和實時報告 * 每秒聚合 350,000 行，并以每秒 34,000 行的速度寫入 Vertica * 每秒寫入 Aerospike 的峰值為 12,000 個用戶個人資料 * 適用于廣告數據的 MySQL * [Spark](https://spark.apache.org/) 用于離線處理和深度數據分析 * [Redis](http://redis.io/) 用于基本緩存 * [節儉](https://thrift.apache.org/) 用于所有數據存儲和傳輸 * 每個數據點在 4 個數據中心中復制 * 每個服務至少在 2 個數據中心中復制（最多 8 個） * 用于長期數據存儲和備份的 Amazon Web Services ## 核心應用和服務 * 自定義 C / C ++ Nginx 模塊，用于高性能廣告投放 * 用于數據處理和輔助服務的 Java * 用于 UI 的 PHP / Javascript * [Jenkins](http://jenkins-ci.org/) 用于持續集成和部署 * Zookeeper，用于分布式鎖定 * 具有高可用性的 HAProxy 和 IPVS * Java / C ++靜態代碼分析的覆蓋范圍 * Checkstyle 和 PMD 用于 PHP 靜態代碼分析 * DC 集中式日志服務器的系統日志 * 休眠，用于基于事務的服務 ## 服務器和資源調配 * Ubuntu * 用于裸機置備的補鞋匠 * 用于配置服務器的廚師 * Berkshelf 適用于 Chef 依賴項 * 帶有 Test Kitchen 的 Docker，用于運行基礎結構測試 * 軟件（ipvs，haproxy）和硬件負載平衡器的組合。 計劃逐步擺脫傳統的硬件負載平衡器。 # 監視堆棧 ## 服務器監視 * 所有服務器的 [Icinga](https://www.icinga.org/) * 約 100 個自定義 Nagios 插件，用于深度服務器監視 * 每個服務器 550 個各種探針 * [石墨](http://graphite.wikidot.com/) 作為數據格式 * [Grafana](http://grafana.org/) 用于顯示所有圖形 * [PagerDuty](http://www.pagerduty.com/) 用于問題升級 * [冒煙](http://oss.oetiker.ch/smokeping/) 用于網絡網格監視 ## 應用程序監視 * [VividCortex](https://vividcortex.com/) 用于 MySQL 監控 * 每個服務上的 JSON / health 端點 * 跨 DC 數據庫一致性監視 * 9 個 4K 65 英寸電視，用于顯示辦公室中的所有圖表 * 統計偏差監視 * 欺詐性用戶監視 * 第三方系統監視 * 部署記錄在所有圖表中 ## 智能監控 * 具有反饋回路的智能警報系統：可以自省一切的系統可以學到任何東西 * 還會監控有關 AppLovin 的第三方統計信息 * 警報是跨團隊的活動：開發人員，操作人員，業務，數據科學家都參與其中 # 體系結構概述 ## 一般注意事項 * 將所有內容存儲在 RAM 中 * 如果不合適，請將其保存到 SSD * L2 緩存級別優化很重要 * 使用正確的工具完成正確的工作 * 體系結構允許交換任何組件 * 僅當替代方案好 10 倍時才升級 * 如果沒有合適的組件，請編寫自己的組件 * 復制重要數據至少 3 倍 * 確保可以在不破壞數據的情況下重播每條消息 * 自動化所有內容 * 零拷貝消息傳遞 ## 消息處理 * 保證消息傳遞的自定義消息處理系統 * 每封郵件進行 3 倍復制 * 發送消息=寫入磁盤 * 任何服務都可能失敗，但是沒有數據丟失 * 消息調度系統將所有組件連接在一起，提供了系統的隔離和可擴展性 * 跨 DC 故障容忍度 ## 廣告投放 * Nginx 的速度非常快：可以在不到一毫秒的時間內投放廣告 * 將所有廣告投放數據保留在內存中：只讀 * jemalloc 將速度提高了 30％ * 將 Aerospike 用于用戶個人資料：不到 1 毫秒即可獲取個人資料 * 將所有廣告投放數據預先計算在一個盒子上，并在所有服務器上分發 * 洪流用于在所有服務器之間傳播服務數據。 與基于 HTTP 的分發相比，使用 Torrent 導致原始服務器上的網絡負載下降 83％。 * mmap 用于在 Nginx 進程之間共享廣告投放數據 * XXHash 是具有低沖突率的最快的哈希函數。 計算校驗和的速度比 SHA-1 快 75 倍 * 實際流量的 5％進入登臺環境 * 能夠一次運行 3 個 A / B 測試（三個獨立測試的流量為 20％/ 20％/ 10％，對照為 50％） * A / B 測試結果可在常規報告中查看 # 數據倉庫 * 所有數據都已復制 * 運行大多數報告所需的時間不到 2 秒 * 聚合是允許快速報告大量數據的關鍵 * 最近 48 小時的非匯總數據通常可以解決大多數問題 * 7 天的原始日志通常足以調試 * 一些報告必須預先計算 * 始終考慮多個數據中心：每個數據點都到達多個位置 * S3 中的備份用于災難性故障 * 所有原始數據都存儲在 Spark 集群中 # 小組 ## 結構 * 70 名全職員工 * 15 個開發人員（平臺，廣告投放，前端，移動） * 4 位數據科學家 * 5 開發。 行動。 * 加利福尼亞帕洛阿爾托的工程師 * 加利福尼亞州舊金山市的業務 * 在紐約，倫敦和柏林的辦事處 ## 互動 * 討論最多問題的 HipChat * Asana，用于基于項目的通信 * 所有代碼均已審核 * 常見的組代碼審核 * 公司季度郊游 * 與首席執行官定期舉行市政廳會議 * 所有工程師（CTO 初級）都寫代碼 * 面試很難：要價實在難得 ## 開發周期 * 開發人員，業務部門或數據科學團隊提出了一個想法 * 提案已審核并計劃在星期一的會議上執行。 * 功能是在分支中實現的； 開發環境用于基本測試 * 創建拉取請求 * 代碼經過審核，并在上進行迭代 * 對于大型功能，組代碼審核很常見 * 該功能已合并到母版 * 該功能已部署到下一個版本 * 該功能已在 5％的實際流量上進行了測試 * 已檢查統計信息 * 如果功能成功，則將逐步量產 * 連續幾天監控功能 ## 避免出現問題 * 該系統旨在處理任何組件的故障 * 單個組件的故障都不會損害廣告投放或數據一致性 * 全能監控 * 工程師觀看并分析關鍵業務報告 * 高質量的代碼至關重要 * 某些功能在畢業之前需要經過多次代碼審查和迭代。 * 在以下情況下觸發警報： * 分期統計數據與生產數據不同 * 關鍵服務出現致命錯誤 * 錯誤率超過閾值 * 檢測到任何不規則活動 * 數據永不丟失 * 大多數日志行都可以輕松解析 * 通過設計，回滾任何更改都很容易 * 每次失敗后：修復，確保將來不會發生相同的事情，并添加監視 # 獲得的經驗教訓 ## 產品開發 * 輕松交換任何組件是增長的關鍵 * 故障推動了創新解決方案 * 過渡環境必不可少：始終準備放松 5％ * A / B 測試必不可少 * 監視所有內容 * 建立智能警報系統 * 工程師應了解業務目標 * 商界人士應意識到工程學的局限性 * 使構建和持續集成快速。 Jenkins 在 2 臺裸機服務器上運行，這些服務器具有 32 個 CPU，128G RAM 和 SSD 驅動器 ## 基礎結構 * 監視所有數據點至關重要 * 自動化很重要 * 每個組件在設計上均應支持 HA * 內核優化可將性能提高多達 25％ * 流程和 IRQ 平衡又使性能提高了 20％ * 省電功能會影響性能 * 盡可能使用 SSD * 優化時，分析所有內容。 火焰圖很棒！ [關于黑客新聞](https://news.ycombinator.com/item?id=9171871) 它們如何在服務器之間平衡請求的負載？ @une：我們結合使用了軟件（ipvs，haproxy）和硬件負載平衡器。 我們計劃逐步擺脫傳統的硬件負載平衡器。 您多久發布一次新功能到生產環境？ 您能否詳細描述代碼審查的執行方式，是正式的還是非正式的，重點是什么。 嗨，羅勒，非常感謝。 我現在對您的“暫存”環境特別感興趣，因為我們正在以類似的規模開展工作，并想出如何管理這種環境。 您能否進一步評論它的“深度”？ 即是否僅復制了您的前端/應用服務器并且“登臺”仍共享生產數據庫？ 還是您以某種方式擁有一個完全獨立的環境，直到數據庫和其他后端服務？ 如果您在暫存中有任何有狀態服務，那么如何管理諸如一致性/模式更改/僅部分可用數據之類的問題？ 如果不這樣做，您將如何為這些服務進行集成測試/部署-尤其是日志攝取管道之類的事情，這似乎對您的工作至關重要？ 謝謝！ @Wes 我們的發布時間表很忙。 通常每周 2-3 次。 我們使用 [GitHub Flow](https://guides.github.com/introduction/flow/) 進行代碼審查和討論。 我們致力于以最簡單的方式實現該功能。 @Paul Banks 我們的暫存環境很深。 我們試圖確保每個生產服務都有一個臨時的對等設備，可以獲取 5-10％的真實數據。 我們確實需要共享一些狀態以使登臺環境變得全面。 某些棘手的問題只能用真實數據才能解決。 由于登臺環境可以運行實驗代碼，因此我們確保采取適當的措施，以方便分離生產和登臺數據。 此設置還有助于我們進行監視：在大多數情況下，預期生產和登臺環境的行為類似。 偏差可能表明存在潛在問題。 您好，能否請您簡單說明一下如何處理 40 個基于維度的指標。 我們有一個類似的維度大小系統，我正在嘗試使用 hbase 和 redis 在每分鐘只有 200 萬個指標點的情況下使用很少的服務器。