# Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延遲進行實時處理 > 原文： [http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html](http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html)  *這是關于[的 Disqus 更新：它仍然是實時的，但是 Go 拆除了 Python](http://highscalability.com/blog/2014/5/7/update-on-disqus-its-still-about-realtime-but-go-demolishes.html) 。* 您如何向 Web 規模應用程序添加實時功能？ 這就是 [Adam Hitchcock](https://www.linkedin.com/in/adamhitchcock) ，在 Disqus 上，Disqus 的一名軟件工程師在精彩的演講中談到：[使 DISQUS Realtime](https://www.youtube.com/watch?v=5A5Iw9z6z2s) （[幻燈片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock)）。 Disqus 必須采用他們的評論系統并為其添加實時功能。 在談話之時（2013 年），他們每月只有 10 億的唯一身份訪問者，這并非易事。 Disqus 開發的是一種稱為“實時”的實時評論系統，該系統經過測試可處理 150 萬個并發連接的用戶，每秒 45,000 個新連接，每秒 165,000 條消息，并且端到端的延遲少于 0.2 秒。 評論系統的本質是它受 IO 約束并且具有很高的扇出度，這是評論的傳入，必須將其發送給許多讀者。 這個問題與 Twitter 必須解決的[非常相似。](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) Disqus 的解決方案及其解決之道非常有趣。 他們嘗試了不同的體系結構，但選擇了基于 Python，Django，Nginx Push Stream Module 和 Thoonk 構建的解決方案，這些解決方案均通過靈活的管道體系結構進行了統一。 在此過程中，我們能夠大幅減少其服務器數量并輕松處理高流量負載。 在演講的某一時刻，亞當問管道式架構是否是一個好的架構？ 對于 Disqus 消息，通過一系列轉換進行過濾是完美的選擇。 這是一個非常古老的想法。 Unix 系統 5 長期以來具有 [Streams 功能](http://infohost.nmt.edu/~eweiss/222_book/222_book/0201433079/ch14lev1sec4.html)用于創建靈活的管道體系結構。 這是組織代碼的一種非常靈活而強大的方式。 因此，讓我們看看 Disqus 如何發展其實時評論架構并在此過程中創建新舊事物。 ## 統計資料 * 當前： * 300 萬個網站使用 Disqus 作為其評論系統 * 每月有十億人參與對話 * 每月有 2000 萬條評論 * 截至 2013 年 3 月： * 每月有十億獨立訪客。 * 18 位工程師 ## 平臺 * Python（Disqus 是一項服務，用 Python 和其他語言編寫） * Django * [Thoonk Redis 隊列](http://blog.thoonk.com/) -Redis 之上的隊列庫。 * Nginx [推流模塊](http://wiki.nginx.org/HttpPushStreamModule) -用于 Nginx 設置的純流 http 推技術。 Comet 變得簡單且真正可擴展。 * [Gevent](http://www.gevent.org/) -基于協程的 Python 網絡庫，該庫使用 greenlet 在 libev 事件循環的頂部提供高級同步 API。 * 使用 EventSource 的長輪詢（在瀏覽器中） * [Sentry](https://github.com/getsentry/sentry) -一個與平臺無關的實時錯誤記錄和聚合平臺。 * [縮放比例](https://github.com/Cue/scales) -跟蹤服務器狀態和統計信息，使您可以查看服務器的運行狀況。 * 在原始金屬（而非 EC2）上運行。 ## 架構 * 實時動機： * **參與度** 。 評論的實時分發鼓勵用戶在頁面上停留更長的時間。 實時評論后的人比以前多。 * **買賣數據** 。 從全局評論流中創建消防軟管產品。 * 舊的實時系統： * 用 Django 編寫的 Disqus 應用程序將通過許多鍵發布到內存緩存：Forum：id，thread：id，user：id，post：id。 也許將來有人會覺得有趣。 由于 pub / sub 的價格便宜，因此可以進行以后的創新。 * 前端客戶端每隔幾秒鐘會輪詢一次內存緩存密鑰。 * 客戶端將顯示任何新評論。 * 問題：根本沒有縮放。 一次只有 10％的網絡可以使用該產品。 * 第一種解決方法： * 新帖-> Disqus-Redis [發布/訂閱](http://redis.io/topics/pubsub) -> [燒瓶](http://en.wikipedia.org/wiki/Flask_(web_framework)) （一個 Web 框架）前端集群<-HAProxy <-客戶端。 * 客戶端將連接到 HAProxy。 HAProxy 用于處理數百萬個連接。 * 問題：由于燒瓶計算機正在執行冗余工作，因此它們很快耗盡了 CPU。 如果兩個訂戶正在偵聽同一線程，則該消息將被格式化兩次。 * 第二種方法： * 已創建后端服務器以執行重復數據刪除格式化工作。 * 新流程：新帖子-> Disqus-> redis 隊列->“ python 膠” Gevent 格式服務器（2 個服務器用于冗余）-> redis 發布/訂閱（6 個服務器） -> Flask FE（前端）群集（14 個大服務器）<-HA 代理（5 個服務器）<-客戶端 * 效果很好。 除了擴展外，它使用的服務器越來越多，尤其是 Flask 集群。 Redis 發布/訂閱集群也迅速增長。 ## 第三種制勝法則： * 使用 [流水線架構](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) ，其中消息在過濾器作用下從一個隊列傳遞到另一個隊列。 * 切換到 Nginx +推送流模塊。 這取代了 redis pub / sub，flask 服務器和 HAProxy 集群。 * 新流程如下所示：新帖子-> Disqus-> redis 隊列->“ python 膠” Gevent 格式服務器（2 個服務器）-> http 帖子-> nginx pub 端點- > nginx +推送流模塊（5 個服務器）<-客戶端 * 僅使用了 redis 的 pub / sub，并且 nginx 推送流模塊支持相同的功能。 * 由于內核中的網絡內存限制，需要 5 個推送流服務器。 這是一個套接字分配問題，即有很多套接字打開。 否則可以在 3 臺服務器上運行，包括冗余。 * 流程中的 Disqus 部分是 Django Web 應用程序，它使用 post_save 和 post_delete 掛鉤將內容放入 thunkk 隊列中。 這些掛鉤對于生成實時數據通知非常有用。 * Thoonk 是 Redis 之上的隊列庫。 * 他們已經有了 thunkk，因此可以使用它來代替分解 RabbitMQ 計算機的 HA 集群。 最終真的很喜歡它。 * Thoonk 被實現為狀態機，因此很容易查看已聲明或未聲明哪些作業，等等。使故障后的清除變得容易。 * 由于使用 zset 將隊列存儲在 Redis 中，因此可以在隊列上執行范圍查詢。 例如，您可以詢問哪些消息已被處理，并采取適當的措施，因此對實施端到端的確認很有用。 * python 膠水程序。 * 收聽 thoonk 隊列。 * 為客戶端執行所有格式化和計算。 包括清潔和格式化數據。 * 最初是在 Flask 群集中進行格式化的，但是這占用了太多 CPU。 * 發現用 gzip 壓縮單個郵件并不成功，因為郵件中沒有足夠的冗余來從壓縮中節省足夠的錢。 * 對于這樣的 IO 綁定系統，Gevent 的運行速度非常快。 * 看門狗確保 [綠色](https://pypi.python.org/pypi/greenlet) 始終在運行，也就是說，始終在執行工作。 Greenlet 是沒有隱式調度的微線程： [協程](http://en.wikipedia.org/wiki/Coroutine) 。 * 監視器監視許多故障，然后在觀察到時發出警報。 * 流水線架構。 * python 膠水程序的結構是一個數據管道，數據必須經過幾個階段：解析，計算，發布到另一個地方。 這些在 greenlet 中運行。 * [Mixins](http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful) 用于實現階段功能：JSONParserMixin，AnnomizeDataMixin，SuperSecureEncryptDataMixin，HTTPPublisher，FilePublisher。 * 這個想法是組成管道。 一條消息將從 thunkk 中傳出并通過以下管道運行：JSONAnnonHTTPPipeline，JSONSecureHTTPPipeline，JSONAnnonFilePipeline。 * 管道可以共享它們的大多數功能，但是仍然是專門的。 啟用新功能時很棒，您可以創建一個新的管線階段，創建一個新的管線，并使舊管線與新管線并排運行。 新舊功能愉快地共存。 * 測試也可以在管道中進行。 要運行測試，只需在管道中插入 filter / module / mixin 即可運行測試。 * 容易推斷。 每個 mixin 都很容易理解。 它做一件事。 項目中的新工程師使用這種方法設計的系統要容易得多。 * Nginx 推送流 * 處理系統的發布/訂閱方面和 Web 服務方面。 并且都很好。 * 最近通過 5 臺服務器吸引了 200 萬并發用戶。 CPU 使用率低于 15％時，每臺計算機的用戶數量達到約 950K 的峰值，每臺計算機達到 40 MB /秒。 * 持續將數據寫入套接字以測試套接字是否仍然打開。 如果不是，則將其清理以為下一次連接騰出空間。 * 配置是發布端點和訂閱端點，以及如何在它們之間映射數據。 * 內置良好的監視功能，可通過推送流狀態端點進行訪問。 * 模塊中的內存泄漏需要全天滾動重啟，尤其是當每個進程有數十萬個并發連接時。 瀏覽器將在斷開連接時迅速知道，因此它將重新啟動并重新連接。 * 較長的輪詢 * 這是在瀏覽器/ JavaScript 客戶端上。 * 當前使用 WebSocket 的原因是它們速度很快，但由于它內置在瀏覽器中并且可以處理所有內容，因此正在遷移到 EventSource。 只需注冊消息類型并為其提供回調處理程序即可。 ## 測試 * 黑暗時間測試。 Disqus 已安裝在數百萬個網站上，因此需要對數百萬個并發連接進行測試。 使用現有網絡進行負載測試，而不是在 EC2 中創建偽設置。 * 例如，有條理的客戶說只有 10％的用戶或恰好這個網站應該流經新系統。 * 最暗時間。 世界上發生了一些重要的事情，而且兩個網站的流量也很大。 因此，他們接受了所有流量，并通過系統中的單個 pub / sub 密鑰發送了流量。 這有助于識別代碼中的許多熱點。 ## 度量 * 測量所有東西。 在流水線系統中，您只需測量每個階段的輸入和輸出，即可與 HAProxy 等其他系統協調數據。 沒有測量數據，就無法向下鉆取并找出誰是錯的。 * 盡可能將指標表示為+1 和-1。 （我不太了解這一點） * Sentry 幫助查找代碼中的問題。 * 通過測量，可以輕松創建漂亮的圖形。 * 當選擇教皇并看到白色煙霧時，流量峰值達到每秒 245 MB，當天傳輸了 6 TB 數據，峰值 CPU 為 12％。 ## 獲得的經驗教訓 * **一次工作**。 在大型扇出架構中，在一個地方進行工作，然后將其發送給所有消費者。 不要為每個消費者重復工作。 * **最有可能失敗的代碼是您的代碼**。 您很聰明，但是很聰明的人寫了 redis 和其他產品，所以要比系統的其他部分更關心您的代碼。 * **端到端的支架不錯，但價格昂貴**。 想要 100％交付的客戶所必需。 無法為每個前端用戶做到這一點。 * **Greenlets 是免費的**。 使用它們。 它們使代碼更易于閱讀。 * **發布是免費的**。 發布到所有頻道。 由于消息已通過所有渠道發布，因此他們無需事先進行計劃就可以制作出實時的流量大圖。 * **有時候會有個大勝利。** 發現 Nginx 推送流模塊簡化了其系統的巨大塊并減少了服務器數量。 * **了解負載測試時的用例，以便您可以真正測試系統**。 * **使用實際流量進行測試**。 當您的系統變大并且生成合成負載本身就是一個巨大的項目時，這是一種容易得多的方法。 * **使用 Python** 。 他們確實喜歡 Python 和 Django，盡管其中一些后端內容現在是用 Go 編寫的。 * **響應規模而增加的服務器數量是您的體系結構可能需要進行一些調整的標志。 看一看，您可以更改架構并更有效地使用資源。** * **使用現成的技術**。 不必覺得您必須從頭開始構建所有內容。 利用代碼，使您的團隊規模變小。 ## 相關文章 * [將 DISQUS 擴展到 7500 萬評論和 17,000 RPS](http://highscalability.com/blog/2010/10/26/scaling-disqus-to-75-million-comments-and-17000-rps.html) （2010） * Disqus [nginx-push-stream-module 配置](https://gist.github.com/dctrwatson/0b3b52050254e273ff11) 適用于> 1MM 并發用戶。 * [通過](https://www.youtube.com/watch?v=5A5Iw9z6z2s) [Adam 制作 DISQUS 實時](https://www.linkedin.com/in/adamhitchcock) （ [幻燈片](https://speakerdeck.com/pyconslides/scaling-realtime-at-disqus-by-adam-hitchcock) ） 希區柯克 ，軟件工程師，?2013 年 3 月 * [將 Django 擴展到 80 億頁面瀏覽量](http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views) [Matt Robenolt](https://www.linkedin.com/in/mattrobenolt) ，運籌領先，2013 年 9 月 * [HTTP for Great Good](https://www.youtube.com/watch?v=HAjOQ09I1UY) （[幻燈片](https://speakerdeck.com/mattrobenolt/http-for-great-good)），作者：Matt Robenolt，2013 年 10 月 * [Google On Latency Tolerant Systems：由不可預測的部分組成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) * [Twitter 用來處理 1.5 億活躍用戶，300K QPS，22 MB / S Firehose 的架構，并在 5 秒內發送推文](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html) * John Watson 的 [C1MM 和 NGINX](https://www.youtube.com/watch?v=yL4Q7D4ynxU) （[[幻燈片](https://speakerdeck.com/dctrwatson/c1m-and-nginx)）-Disqus 結構的更新。 * [試試這個 Go 事情…](http://blog.disqus.com/post/51155103801/trying-out-this-go-thing) 引用“如果可以的話，將指標表示為+1 和-1。（我不太了解這一點）” 這不僅僅是計數指標嗎？也就是說，因為您正在使用鏈接的消息隊列，因為消息到達您對計數器+1 的每個點，而消息離開您-1 的另一個計數器。 您可以在每個節點/隊列的輸入和輸出處執行此操作。 每個點+1 的變化，每個點-1 的變化告訴您每個時間間隔（傳入和傳出）的消息吞吐量，總+1 和總-1 的差告訴您消息' 在隊列中”。 好讀！ 好東西。 現在，他們需要解決垃圾郵件問題。 這看起來像一團糟。 在這家公司工作會很害怕。 這就是為什么您需要良好的系統架構師的原因。 如果您不能用 c / c ++自己編寫（暗示理解）這些工具的一半，則需要重新考慮領導該項目。 現在您有了一個巨大的泥球，上帝知道有多少種不同類型的“粘土”。 http://en.wikipedia.org/wiki/Big_ball_of_mud 我很好奇他們是否會考慮為此使用 elixir 以及 phoenix 框架。 流水線方法，大規模，并發性和容錯性固有地內置于長生不老藥中，并且不需要像這樣做的一整套分散的組件。 話雖如此。 做到這一點仍然是一個了不起的壯舉，我敢肯定，出于很多原因，研究長生不老藥可能不是他們追求的解決方案。 這看起來很混亂。 會害怕在這個組織工作。 這就是為什么您需要好的程序設計師。 如果您不能在 c / c ++中自己創建（暗示理解）這些資源的 50％，則需要重新評估獲得的資源。 現在您有了一個偉大的泥濘足球，上帝知道有多少種“粘土”。 我很好奇你們在 django 中存儲持久連接的位置，這是我們的主要問題，我們的隊列（我們使用 Rabbitmq）連接快要死了并且無法恢復。 現在他們需要解決垃圾郵件問題。這就是為什么您需要優秀的程序設計師。 如果您不能在 c / c ++中自己創建（暗示理解）這些資源的 50％，則需要重新評估獲得的資源。 好東西。 從它的聲音來看，它聽起來像是一個混亂的機構，但是，從它提供的服務的種類來看，我相信他們可能已經將其微調到可以接受的水平。 我喜歡這篇文章，但有一個問題。 Disqus 使用的數據庫是什么？ 該帖子解釋了如何保存新帖子，但是當我打開網站并打開 Disqus 評論時。 獲取所有評論并顯示在網站上的過程是什么？ 謝謝這個