# 英雄聯盟如何將聊天擴大到 7000 萬玩家-需要很多小兵。 > 原文： [http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html](http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html)  您將如何構建一個聊天服務，每天需要處理 750 萬并發玩家，2,700 萬每日玩家，每秒 11,000 條消息和每臺服務器 10 億個事件？ 什么會產生這么多的流量？ 當然是游戲。 [英雄聯盟](http://leagueoflegends.com) 。 英雄聯盟是一款基于團隊的游戲，一種多人在線戰斗競技場（ [MOBA](http://en.wikipedia.org/wiki/Multiplayer_online_battle_arena) ），其中兩支五人的隊伍互相對抗，以控制地圖和 實現目標。 對于團隊而言，成功的溝通至關重要。 我從 [Michal Ptaszek](https://twitter.com/michalptaszek) 中了解到，在關于 [擴展英雄聯盟的有趣演講中，與 7,000 萬玩家聊天](https://www.youtube.com/watch?v=_jsMpmWaq7I) （ [幻燈片](http://www.slideshare.net/michalptaszek/strange-loop-presentation) ）在 [Strange Loop 2014](https://thestrangeloop.com/) 會議。 Michal 很好地說明了為什么多人團隊游戲需要玩家之間的良好溝通。 想象一下沒有打籃球的籃球比賽。 這是行不通的。 因此，這意味著聊天至關重要。 聊天不是“很好”的功能。 Michal 以一種有趣的方式構建了對話，將以下表達用作模板：使之起作用。 改正它。 快一點。 使其工作意味著從 XMPP 開始作為聊天的基礎。 WhatsApp 遵循 [相同的策略](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) 。 開箱即用，您將獲得可以正常使用和擴展的功能……直到用戶數真正增加。 為了使其正確而快速，例如 WhatsApp，《英雄聯盟》發現自己自定義了 Erlang VM。 添加許多監視功能和性能優化，以消除破壞大規模性能的瓶頸。 他們聊天架構中最有趣的部分可能是使用 Riak 的 [CRDT](http://blog.joeljacobson.com/riak-2-0-data-types/) （會聚復制數據類型）來實現 他們沒有共享的目標助長了大規模線性水平可伸縮性。 CRDT 仍然很深奧，因此您可能還沒有聽說過它們，但是如果您可以讓它們為您服務，那么它們將是下一件很酷的事情。 這是處理寫入的另一種思考方式。 讓我們了解一下英雄聯盟如何構建他們的聊天系統來處理 7000 萬玩家... ## 統計信息 * 每月有 6700 萬唯一身份玩家（不包括聊天中的其他服務） * 每天有 2700 萬玩家 * 750 萬并發玩家 * 僅使用 20％到 30％的可用 CPU 和 RAM，每天每臺服務器路由 10 億個事件。 * 每秒 11K 條消息 * 全世界部署了數百個聊天服務器。 由 3 個人管理。 * 99％的正常運行時間。 ## 平臺 * [Ejabberd](https://www.ejabberd.im/) （基于 Erlang）XMPP 服務器 * 修復 * 負載均衡器 * 石墨 * Zabbix * Nagios * 詹金斯 * 匯合 ## 聊天 * 可以是一對一或群聊。 * 聊天充當在線狀態服務，并且還維護好友列表。 它知道播放器是在線還是離線。 他們在玩嗎？ 他們玩了多久了？ 他們在玩什么冠軍？ * REST API 提供聊天作為其他 LoL 服務的后端服務。 例如，商店通過聊天來驗證友誼。 聯賽使用聊天社交圖譜將新玩家分組在一起，以便他們可以更頻繁地比賽并相互競爭。 * 聊天必須以低且穩定的延遲運行。 如果聊天不起作用，游戲體驗會下降。 * 選擇 [XMPP](http://xmpp.org/) 作為協議。 提供消息傳遞，狀態信息，并維護聯系人列表。 * 由于性能原因和實施新功能，它們必須與核心 XMPP 協議有所不同。 * 選擇 Ejabberd 作為他們的服務器。 一開始它運作良好。 Erlang 有很多好處。 它的構建考慮了并發性，分發性和可伸縮性。 它支持熱代碼重載，因此可以在不停止服務的情況下修補錯誤。 * 目標是 [不共享任何體系結構](http://en.wikipedia.org/wiki/Shared_nothing_architecture) 以實現大規模線性水平可伸縮性。 還可以實現更好的錯誤隔離和可追溯性。 尚不存在，但正在朝著這個目標取得進展。 * 擁有數百個聊天服務器，只有幾個人可以管理它們，因此服務器必須具有容錯能力，這一點很重要。 并非每一次失敗都需要人工干預。 * 讓它崩潰。 不要試圖從重大故障中緩慢恢復。 而是從已知狀態重新啟動。 例如，如果有大量待處理查詢積壓到數據庫中，則數據庫將重新啟動。 所有新查詢都會實時處理，而排隊的查詢將重新安排進行處理。 * 每個物理服務器都運行 Ejabberd 和 Riak。 Riak 用作數據庫。 可以根據需要水平添加服務器。 Ejabberd 在集群中運行。 風險服務器也運行在它們自己的群集中。 * Riak 服務器使用多數據中心復制將持久性數據導出到輔助 Riak 群集。 像社交圖查詢一樣，昂貴的 ETL 查詢在輔助群集上運行，而不會中斷主要群集。 備份也會在輔助群集上運行。 * 隨著時間的流逝，由于必須關注可伸縮性，性能和容錯能力，因此大部分 Ejabberd 都被重寫。 * 重寫以符合他們的要求。 例如，在 LoL 友誼僅是雙向的，XMPP 允許非對稱友誼。 XMPP 友誼的創建需要客戶端和服務器之間大約有 16 條消息，這對數據庫造成了打擊。 新協議是三個消息。 * 刪除了不必要的代碼。 * 優化了協議本身。 * 寫了很多測試以確保沒有損壞。 * 配置文件代碼可消除明顯的瓶頸。 * 避免共享可變狀態，因此它可以在單個服務器上以及在集群環境中線性擴展。 * 多用戶聊天（MUC）。 每個聊天服務器都可以處理數十萬個連接。 對于每個用戶連接，都有一個會話過程。 每次用戶想要更新其狀態或向房間發送消息時，事件都必須轉到稱為 MUC 路由器的單個進程中。 然后它將消息中繼到相關的群聊。 這是一個明顯的瓶頸。 解決方案是并行化路由。 現在，在用戶會話中查找群組聊天室。 能夠使用所有可用的內核。 * 每個 Ejabberd 服務器都包含會話表的副本，該表包含用戶 ID 和會話之間的映射。 發送消息需要查看用戶會話在集群中的位置。 消息已寫入會話表。 通過檢查會話是否存在，檢查存在優先級以及其他一些檢查，分布式寫操作的數量減少了 96％。 巨大的勝利。 更多的用戶可以更快地登錄，并且狀態更新可以更頻繁地發生。 * 新增的功能使您可以更好地了解已升級到生產中的代碼。 因此，可以在事務上下文中一次在多個服務器上更新代碼。 * 為了優化服務器，調試功能已添加到 Erlang VM 中。 需要具有查看會話中內存使用情況的能力，以便他們可以更好地優化內存使用率。 * 從一開始就設計了數據庫可伸縮性。 從 MySQL 開始，但是遇到了多個性能，可靠性和可伸縮性問題。 例如，不可能足夠快地更新架構以跟蹤代碼中所做的更改。 * 因此，他們選擇了 Riak。 Riak 是分布式，容錯的鍵值存儲。 真正的無主，所以沒有單點故障。 即使兩臺服務器故障也不會降低服務質量或丟失數據。 * 必須在聊天服務器上花費大量工作來實現最終的一致性。 實現了 Ejabberd [CRDT 庫](http://blog.joeljacobson.com/riak-2-0-data-types/) （會聚復制數據類型）。 負責所有寫沖突。 嘗試將對象收斂到穩定狀態。 * CRDT 如何工作？ 與其將新玩家直接添加到好友列表中，不如保留對象的操作日志。 日志中有“添加播放器 1”和“添加播放器 2”之類的條目。 下次讀取該對象時，將查閱該日志并解決所有沖突。 然后將日志以任何順序應用于對象，因為順序無關緊要。 這樣，朋友列表就處于一致狀態。 想法是在適當的位置更新值，而不是為對象建立一長串的操作日志，并且只要讀取對象就應用該操作。 * Riak 取得了巨大的成功。 允許線性縮放。 還提供了方案靈活性，因為可以隨時更改對象。 * 這是一個巨大的思想轉變和大量的工作。 它改變了他們測試服務并圍繞它構建工具的方式。 ## 監控 * 內置了超過 500 個實時計數器，每分鐘收集一次并發布到監視系統（Graphite，Zabbix，Nagios）中。 * 計數器具有閾值，在超過閾值時會生成警報。 在玩家注意到任何服務問題之前就可以解決問題。 * 例如，最近的客戶端更新進入了廣播自己存在狀態的無限循環。 觀察 Graphite，立即可以看出聊天服務器受到了從新客戶端版本開始的狀態更新的沖擊。 ## 實現功能切換（功能標志） * 能夠即時打開和關閉新功能，而無需重新啟動服務。 * 開發新功能時，將通過開/關開關將其包圍。 如果某個功能導致問題，則可以將其禁用。 * 部分部署。 只能為某些用戶啟用新代碼，或者一定比例的用戶可以激活新代碼。 這樣可以在遠低于滿載的情況下測試潛在危險功能。 如果新功能有效，則可以為所有人打開。 ## 快速重新加載代碼 * Erlang 的一大特色是能夠即時熱加載新代碼。 * 在一種情況下，第三方客戶（如 pidgin）沒有經過良好的測試，結果證明他們發送的事件與官方客戶不同。 可以將這些修補程序部署并集成到聊天服務器中，而不必重新啟動整個聊天。 這意味著減少了玩家的停機時間。 ## 正在記錄 * 記錄所有異常情況，例如錯誤和警告。 * 服務器還報告運行狀況良好，從而可以查看日志并確定服務器是否正常，因為它正在記錄用戶，接受新連接，修改好友列表。 * 內置進入所選用戶會話的調試模式的功能。 如果有可疑用戶或實驗用戶（在生產服務器上進行質量檢查），即使聊天服務器上有 100,000 個會話，也只需記錄特定的會話即可。 日志記錄包括 XML 流量，事件和指標。 這樣可以節省大量的日志存儲空間。 * 通過功能切換，部分部署和選擇性日志記錄的組合，可以將功能部署到生產服務器，因此只能由幾個人進行測試。 可以收集和分析相關日志，而不會受到所有用戶的干擾。 ## 負載測試代碼 * 每天晚上，自動驗證系統都會將所有更改的構建部署到負載測試環境，并運行一系列負載測試。 * 在測試過程中監視服務器的運行狀況。 指標被提取和分析。 將生成一個 Confluence 頁面，其中包含所有指標和測試結果。 將發送電子郵件摘要以及測試結果摘要。 * 可以將更改與以前的版本進行比較，因此可以跟蹤代碼更改對測試的影響，發現災難或諸如內存使用量減少了 X％之類的更改。 ## 未來 * 從 MySQL 遷移數據。 * 希望在游戲外提供聊天功能，以便玩家無需登錄游戲即可享受友誼。 * 想使用社交圖譜來改善體驗。 分析玩家之間的聯系，并了解其如何影響游戲的樂趣。 * 計劃將游戲內聊天遷移到游戲外聊天服務器。 ## 獲得的經驗教訓 * **事情將失敗**。 您沒有完全的控制權。 即使您的代碼沒有錯誤，如果 ISP 的路由器死亡并且同時失去 100,000 個播放器，會發生什么情況？ 做好準備 確保您的系統可以一次處理掉一半的玩家。 或者在 20 個聊天服務器中損失 5 個而不會降低性能。 * **縮放表面蟲** 。 即使一個錯誤僅發生十億次，這意味著在英雄聯盟的規模下，該錯誤每天也會發生一次。 隨著時間的流逝，甚至不太可能發生的事件。 * **成功的關鍵是了解系統實際上在做什么** 。 了解您的系統是否處于健康狀態或即將崩潰。 * **制定策略** 。 大聲笑有一種橫向擴展其聊天服務的策略。 為了支持他們的策略，他們做了一些不同的事情。 他們不僅使用 Riak 購買了 NoSQL，而且改變了利用 CRDT 的方法，以使水平擴展盡可能無縫和強大。 * **使它起作用** 。 從某個地方開始發展。 埃賈伯德把他們弄倒了。 從頭開始會更容易嗎？ 也許可以，但是當他們了解了需求是什么時，他們便能夠開發出滿足他們需求的系統。 * **使其可見** 。 添加跟蹤，日志記錄，警報，監視，圖形以及所有這些好東西。 * **使其成為 DevOps** 。 LoL 在軟件更新，功能標記，熱更新，自動負載測試，高度可配置的日志級別等中添加了事務，以使系統更易于管理。 * **減少聊天協議** 。 根據系統需求定制功能。 例如，如果您的系統僅支持雙向友誼，那么您就不會采用更為通用和昂貴的協議。 * **避免共享可變狀態** 。 這是一種常見的策略，但是看到共享狀態如何在每次擴大規模時引起越來越多的問題總是很有趣的。 * **利用您的社交圖** 。 聊天服務自然會提供社交圖。 該信息可用于改善用戶體驗和實現新穎的新功能。 ## 相關文章 * [在 Reddit 上](http://www.reddit.com/r/programming/comments/2j95dv/how_league_of_legends_scaled_chat_to_70_million/) * [使用 Erlang 的新 Facebook 聊天功能可擴展至 7000 萬用戶](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) （2008） * [HipChat 如何使用 ElasticSearch 和 Redis 存儲和索引數十億條消息](http://highscalability.com/blog/2014/1/6/how-hipchat-stores-and-indexes-billions-of-messages-using-el.html) （使用 XMPP） * [Facebook 以 190 億美元的價格收購了 WhatsApp 架構](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) （使用 XMPP） * [誤區：埃里克·布魯爾（Eric Brewer）論為何銀行不使用堿-可用性是收入](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html) * [英雄聯盟內部，電子競技的主要賽事](http://www.nytimes.com/2014/10/12/technology/riot-games-league-of-legends-main-attraction-esports.html) 很棒的文章，謝謝！ 一個小小的更正：Riak（還有問題）中的 CRDT 風格是收斂的復制數據類型，而不是您的文章所說的可交換的 從某種意義上講，CRDT 并不是新事物：您的銀行分類帳是事件日志，并且在存在所有此類即時網絡之前，銀行分支機構通常會在一天結束時合并其日志，以獲取權威的銀行余額。 但是顯然，分布式數據庫專家并沒有永遠談論 CRDT，所以我知道您的意思。 很酷的文章！ 作為每天使用 Erlang 的人，看到越來越多的知名項目/公司使用它總是很有趣。 感覺就像總是隱藏在 XD 中的那些語言之一 想一想游戲的持續發展速度如何，而且除了 DDOS 攻擊之外，幾乎沒有打 h 過，這真是令人驚訝。