# WhatsApp 如何每秒吸引近 5 億用戶，11,000 內核和 7,000 萬條消息 > 原文： [http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html](http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html)  上次[訪問 WhatsApp](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 時，他們剛剛被 Facebook 以 190 億美元的價格收購。 我們了解了他們的早期體系結構，該體系結構主要集中于優化 Erlang，以處理服務器上的 200 萬個連接，使用 All The Phones 并通過簡單性使用戶滿意。 兩年后，流量增長了 10 倍。 WhatsApp 如何使它躍升到新的可擴展性水平？ [Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 Erlang 工廠的一次演講中告訴我們： [這是“十億”，帶有“ B”： WhatsApp 的下一個級別](https://www.youtube.com/watch?v=c12cYAUTXXs) （ [幻燈片](https://github.com/reedr/reedr/blob/master/slides/efsf2014-whatsapp-scaling.pdf) ），這顯示了 WhatsApp 的統計數據： > 擁有數百個節點，數千個內核，數百 TB 的 RAM 的東西，并希望為不久將在全球范圍內成為現實的數十億智能手機提供服務？ WhatsApp 上基于 Erlang / FreeBSD 的服務器基礎結構。 在滿足對消息傳遞服務不斷增長的需求方面，我們面臨著許多挑戰，但是隨著我們不斷擴大服務范圍（> 8000 核）和速度（>每秒 70M Erlang 消息）， 系統。 與兩年前相比，最顯著的變化是什么？ * 顯然，除了工程師數量之外，每個維度都更大。 更多的盒子，更多的數據中心，更多的內存，更多的用戶以及更多的擴展問題。 Rick 最引以為傲的是，用很少的工程師來處理這種增長水平：每個工程師 4000 萬用戶。 這是云計算勝利的一部分。 他們的工程師在他們的軟件上工作。 網絡，硬件和數據中心由其他人處理。 * 由于需要有足夠的頭部空間來處理每個盒子上增加的總體負載，因此他們放棄了嘗試為每個盒子盡可能多地支持連接。 盡管他們通過增加大型機箱并在 SMP 機器上高效運行來降低管理開銷的一般策略仍然保持不變。 * 瞬態很好。 如今，多媒體，圖片，文本，語音，視頻已成為其體系結構的一部分，而不必長期存儲所有這些資產，極大地簡化了系統。 該體系結構可以圍繞吞吐量，緩存和分區展開。 * Erlang 是它自己的世界。 聽了這個談話，很清楚您在 Erlang 的世界觀中所做的一切都多少，這可能會令人迷惑。 盡管最終是一個分布式系統，所有問題都與其他任何分布式系統相同。 * Erlang 數據庫 Mnesia 似乎是造成大規模問題的重要原因。 這讓我想知道是否還有其他一些數據庫可能更合適，是否需要留在 Erlang 解決方案系列中是否會有點盲目呢？ * 您可能會想到很多與規模有關的問題。 不穩定的連接問題，隊列太長以至于它們會延遲高優先級的操作，定時器的抖動，在一種流量級別上正常工作的代碼在較高流量級別上嚴重中斷，高負載下的高優先級消息無法得到服務，阻塞其他操作的問題 意外的方式，導致資源問題的故障等等。 無論您使用什么系統，這些事情都會發生，并且必須通過它們來解決。 * 我對 Rick 跟蹤并修復問題的能力感到震驚和驚訝。 非常令人印象深刻。 瑞克總是講好話。 他非常慷慨地提供具體細節，這些細節顯然直接來自生產中遇到的問題。 這是我對他的講話的掩飾… ## 統計信息 * 每月有 4.65 億用戶。 * 每天& 40B 中有 19B 條消息 * 600M 圖片，2 億語音，1 億視頻 * 147M 高峰并發連接-手機已連接到系統 * 230K 高峰登錄/秒-電話連接和斷開連接 * 342K 峰值 msgs in / sec，712K 峰值 * 大約有 10 位團隊成員在 Erlang 上工作，他們既處理開發工作，又處理操作。 * 假期多媒體使用率最高。 * 輸出 146Gb / s（圣誕節前夕），電話的帶寬相當大 * 已下載 360M 視頻（圣誕節偶數） * 已下載 2B 張圖片（46k / s）（除夕） * 1 張圖片已下載 3200 萬次（除夕） ## 堆棧 * Erlang R16B01（加上自己的補丁） * FreeBSD 9.2 * Mnesia（數據庫） * 偏航 * SoftLayer 是他們的云提供商，裸機，網絡內相當隔離的雙數據中心配置 ## 硬件 * ?550 個服務器+備用設備 * 約 150 個聊天服務器（每個約 100 萬個電話，1.5 億個高峰連接） * ?250 毫米（多媒體）服務器 * 2x2690v2 Ivy Bridge 10 核（超線程總共 40 個線程） * 數據庫節點具有 512GB 的 RAM * 標準計算節點具有 64GB RAM * SSD 主要用于可靠性，但由于需要更多存儲空間而存儲視頻時除外 * 雙鏈路 GigE x2（面向用戶的公共&面向后端系統的私有） * > 11,000 個內核運行 Erlang 系統 ## 系統概述 * 二郎的愛。 * 很棒的語言，只用很少的工程師就能支持這么多的用戶。 * 強大的 SMP 可擴展性。 可以運行非常大的盒子并保持較低的節點數。 操作復雜性隨節點數（而不是核心數）而定。 * 可以即時更新代碼。 * 可擴展性就像清除雷區。 他們通常能夠在爆炸之前發現并清除問題。 測試系統的事件是世界性事件，尤其是足球，這會產生較大的垂直負載峰值。 服務器故障，通常是 RAM。 網絡故障。 和不良的軟件推動。 * 傳統外觀架構： * 電話（客戶端）連接到聊天和 MMS（多媒體）。 * 聊天連接到瞬時離線存儲。 后端系統在用戶之間傳遞消息時會保留它們。 * 聊天連接到數據庫，例如帳戶，個人資料，推送，群組等。 * 發給手機的消息： * 實際短信 * 通知：小組主題，個人資料照片更改等 * 存在消息：鍵入，空閑，已連接/未連接等 * 多媒體數據庫： * 內存中 [Mnesia 數據庫](http://www.erlang.org/doc/man/mnesia.html) 使用大約 2TB 的 RAM 在 16 個分區上分片，以存儲約 180 億條記錄。 * 消息和多媒體僅在傳遞時存儲，而在傳遞媒體時，有關媒體的信息存儲在數據庫中。 * 每臺服務器的連接數為 100 萬，而不是兩年前的每臺服務器 200 萬的連接數，通常是因為服務器繁忙得多： * 隨著更多的用戶，他們希望在每臺服務器上以更多的凈空運行，以吸收峰值負載。 * 用戶比兩年前更加活躍。 他們正在發送更多消息，因此服務器正在執行更多操作。 * 這些服務器之外的功能已移至它們上運行，因此它們可以做更多的事情。 ## 去耦 * 隔離瓶頸，使它們不會在系統中傳播 * 緊密耦合會導致級聯故障。 * 堆棧中較深的后端系統不應冒充前端。 * 所有內容均已分區，因此，如果一個分區出現問題，其他分區將不會受到影響。 * 解決問題時，請保持盡可能多的吞吐量。 * 異步性可最大程度地減少延遲對吞吐量的影響 * 即使在系統中的各個點存在等待時間或等待時間無法預測時，也可以保持盡可能高的吞吐量。 * 減少耦合，并使系統盡可能快地工作。 * 避免 [行頭阻塞](http://en.wikipedia.org/wiki/Head-of-line_blocking) * 行頭塊是在隊列中對第一個數據包進行處理而使在其后排隊的所有那些項目餓死的地方。 * 分離的讀寫隊列。 特別是在表上執行事務的地方，因此，如果在寫側存在任何延遲，則不會阻塞讀側。 通常，讀取端的運行速度要快得多，因此任何阻塞都會堆積讀取器。 * 單獨的節點間隊列。 如果某個節點或連接節點的網絡出現故障，則可能會阻止應用程序中的工作。 因此，當將消息發送到不同的節點時，會將消息傳遞給不同的 [進程](http://www.erlang.org/doc/reference_manual/processes.html) （Erlang 中的輕量級并發），因此僅備份發往問題節點的消息。 這允許發送到健康節點的消息自由流動。 問題被隔離到問題所在。 修補的 mnesia 在 async_dirty 復制時可以很好地做到這一點。 發送消息的應用程序與發送程序是分離的，并且如果節點出現問題，則不會感到任何背壓。 * 當使用不確定的延遲時，使用“隊列” FIFO 工作程序分配模型。 * 元集群 * 請注意，本節僅在演講開始約 29 分鐘時進行，非常簡短，很不幸。 * 需要一種方法來包含單個群集的大小，并允許其跨越很長的距離。 * 構建了 wandist，這是 gen_tcp 上類似 dist 的傳輸，它由需要相互通信的節點的網格組成。 * pg2 之上的透明路由層創建了一個單跳路由調度系統。 * 示例：兩個數據中心中的兩個主要群集，兩個不同數據中心中的兩個多媒體群集，以及兩個數據中心之間的共享全局群集。 它們之間都有廣電連接。 * 示例： * 通過使用 async_dirty 避免進行 Mnesia 事務耦合。 大多數交易未使用。 * 僅在從數據庫取回時使用調用，否則將強制轉換所有內容以保留異步操作模式。 在 Erlang 中，handle_call 會阻止響應，并且消息已排隊，而 handle_cast 不會阻止，因為操作結果無關緊要。 * 呼叫使用超時，而不是監控器。 減少遠端 proc 上的競爭，并減少分發渠道上的流量。 * 當只需要盡力而為時，請在演員表上使用 nosuspend。 如果一個節點有問題或網絡有問題，這會將一個節點與下游問題隔離開，在這種情況下，分發緩沖區會在發送節點上備份，并且嘗試發送的 proc 會被調度程序掛起，從而導致級聯失敗，每個人 正在等待，但尚未完成任何工作。 * 使用大型分配緩沖區來吸收網絡和下游節點中的問題。 ## 并行化 * 工作分配： * 需要分配超過 11,000 個核心的工作。 * 從單線程 [gen_server](http://www.erlang.org/doc/man/gen_server.html) 開始。 然后創建一個 gen_factory 以將工作分散到多個工作人員。 * 在一定的負載下，調度過程本身成為了瓶頸，而不僅僅是執行時間。 繁瑣的操作使許多節點進入了盒子的調度過程，過程的鎖定成為分配端口和過程本身進入的瓶頸。 * 如此創建了 gen_industry，位于 gen_factory 之上的一層，因此有多個調度過程，允許對進入包裝盒的所有輸入以及對工人本身的調度進行并行化。 * 通過一個鍵選擇工作程序進行數據庫操作。 對于 IO 等不確定的延遲情況，使用 FIFO 模型分配工作量以防止行首阻塞問題。 * 分區服務： * 在 2 到 32 種方式之間進行分區。 大多數服務是按 32 種方式分區的。 * [pg2 尋址](http://erlang.org/doc/man/pg2.html) ，它們是分布式進程組，用于尋址整個群集中的分區。 * 節點成對運行。 一個是小學，另一個是中學。 如果一個或另一個發生故障，它們將處理主要和次要流量。 * 通常嘗試將訪問單個 [集合](http://www.erlang.org/doc/man/ets.html) （內置術語存儲）或單個記憶缺失片段的進程數限制為 8。 鎖爭用在控制之下。 * Mnesia： * 因為他們不使用事務來獲得盡可能高的一致性，所以他們通過哈希將對單個節點上單個進程的記錄的訪問序列化。 哈希到一個分區，該分區映射到 [記憶缺失片段](http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html) ，最終被分派到一個工廠，一個工人中。 因此，對單個記錄的所有訪問都將進入單個 erlang 進程。 * 每個記憶缺失片段僅在一個節點上的應用程序級別被寫入或讀取，這使得復制流只能在一個方向上進行。 * 當同級之間存在復制流時，片段更新的速度會遇到瓶頸。 他們修補 OTP，以使多個事務管理器僅針對 async_dirty 運行，因此記錄更新并行發生，從而提供了更多的復制吞吐量。 * 修補程序，用于將 mnesia 庫目錄拆分為多個庫，這意味著可以將其寫入多個驅動器，從而增加了磁盤的吞吐量。 真正的問題是何時從對等方加載了失憶癥。 將 IO 分散在多個驅動器（甚至是 SSD）上，就數據庫加載速度而言，提供了更大的可伸縮性。 * 將記憶缺失的島嶼縮小到每個島嶼的兩個節點。 島嶼是記憶障礙的群集。 即使有 32 個分區，也將有 16 個支持一個表的島。 由于只有兩個節點需要完成架構操作，因此有更好的機會在負載下支持架構操作。 如果嘗試同時啟動一個或兩個節點，則減少了加載時間協調。 * 通過快速警報來處理 Mnesia 中的網絡分區。 他們繼續運行。 然后進行手動對帳，以將它們合并在一起。 ## 優化 * 離線存儲系統曾經是負載高峰期間的一個大瓶頸。 只是無法將內容快速推入文件系統。 * 用戶可以快速讀取大多數郵件，例如 60 秒內可以讀取 50％。 * 添加了回寫緩存??，因此可以在必須將消息寫入文件系統之前將其傳遞。 98％的緩存命中率。 * 如果由于負載而備份了 IO 系統，則在 IO 系統追趕時，緩存會提供額外的緩沖以全速傳輸消息。 * 通過將 BEAM（Erlang VM）打補丁到所有異步工作線程中的循環文件端口請求，從而解決了異步文件 IO 中的行頭阻塞問題，該問題在出現大郵箱或慢速磁盤的情況下可簡化寫操作 。 * 將大型郵箱保留在緩存之外。 有些人處于大量群組中，每小時收到數千封郵件。 他們污染了緩存并放慢了速度。 從緩存中逐出它們。 請注意，處理不成比例的大型用戶是每個系統（包括 Twitter ）的問題。 * 緩慢訪問帶有很多碎片的失憶表 * 帳戶表分為 512 個片段，這些片段被劃分為多個孤島，這意味著用戶到這 512 個片段的稀疏映射。 大多數片段將是空的和空閑的。 * 主機數量加倍導致吞吐量下降。 事實證明，記錄訪問的速度確實很慢，因為當目標為 7 時，哈希鏈的大小超過了 2K。 * 發生的是散列方案導致創建了大量的空存儲桶，而很少的存儲桶非常長。 兩行更改將性能提高了 4 比 1。 ## 修補 * 爭奪計時器輪。 在一臺主機中有幾百萬個連接，并且每當特定電話發生任何事情時，每個連接都在設置和重置計時器，因此，結果是每秒成千上萬個計時器設置和重置。 一個計時器輪和一個鎖，這是一個重要的競爭來源。 解決方案是創建多個計時器輪以消除競爭。 * mnesia_tm 是一個很大的選擇循環，在嘗試加載表時，由于選擇接收，積壓可能會導致無法返回的點。 修補程序將物料從傳入的事務流中拉出并保存以供以后處理。 * 添加多個 mnesia_tm async_dirty 發件人。 * 為 prim_file 命令添加標記/設置。 * 有些星團橫跨整個大陸，因此，健忘癥應該從附近的節點而不是整個國家/地區加載。 * 為異步文件 IO 添加循環調度。 * 種子和哈希散列以破壞與 phash2 的重合。 * 優化主要/名稱表的比例。 * 如果已經遺失，請不要將其遺忘在隊列中。 無法完成具有待處理的轉儲的架構操作，因此如果排隊了很多轉儲，則無法進行架構操作。 ## 2/22 中斷 * 即使所有這些工作都發生了。 它發生在最壞的時間，在 Facebook 收購之后，發生了 210 分鐘的中斷[。](http://techcrunch.com/2014/02/22/whatsapp-is-down-facebooks-new-acquisition-confirms/) * 由于負載未發生。 它始于后端路由器問題。 * 路由器丟棄了 VLAN，該 VLAN 導致整個集群中大量節點斷開/重新連接。 當一切重新連接時，它處于不穩定狀態，他們從未見過。 * 最終決定，他們必須停止所有操作并將其恢復，這是他們多年來沒有做過的事情。 花了一段時間才將所有內容放回原處并重新保存。 * 在此過程中，他們發現了一個過度耦合的子系統。 通過斷開連接和重新連接，pg2 可以進入 n ^ 3 消息傳遞狀態。 他們看到 pg2 消息隊列在幾秒鐘內從零增加到 400 萬。 推出補丁。 ## 版本 * 無法模擬這種規模的流量，尤其是在高峰時段，例如午夜的新聞除夕。 如果他們嘗試的是極具破壞性的措施，則推出的速度將非常緩慢。 只需要一小部分流量。 然后快速迭代，直到效果良好為止，然后部署到集群的其余部分。 * 推出是滾動升級。 一切都是多余的。 如果他們要進行 BEAM 升級，則會先安裝 BEAM，然后逐步在集群中執行重新啟動以獲取新更改。 有時，它只是一個熱補丁，無需全面重啟就可以推出。 這是罕見的。 通常升級整個事情。 ## 尚待解決的挑戰 * 由于升級，數據庫會定期刷新。 數據量太大的問題需要花費很長時間才能加載，并且由于各種原因，加載會在較大規模下失敗。 * 實時集群狀態&大規模控制。 舊的 shell 窗口方法不再起作用。 * 2 次冪分割。 現在有 32 個分區。 下一步是 64，這將起作用，但是 128 分區將是不切實際的。 關于這一點沒有太多討論。 對 whatapp 與其他聊天應用說微信/行比較的興趣，是否有關于此的博客/文章/文檔？ Softlayer 的路由器只是“丟棄” VLAN。 他們可以通過廉價找到的 LCD（最低公分母）人員聯網的另一朵云。 檢查我們。 我們可以做的更好：) 是的，喬，讓我們使用您的小公司。 這并不是說 Softlayer 并不是一個存在時間更長的大型企業集團。 他們并不便宜。 他們很容易成為更高端的提供商之一。 他們知道自己在做什么。 一個問題并不大。 AWS 遇到了一些問題。 您的帖子只是展示您的天真，給您的公司起了壞名聲。 我建議不要發布有關其他提供商的負面評論，以使自己看起來不錯。