# Zoosk-實時通信背后的工程 > 原文： [http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html](http://highscalability.com/blog/2012/8/27/zoosk-the-engineering-behind-real-time-communications.html)  *這是 [Peter Offringa 的來賓帖子，](http://www.linkedin.com/in/peteroffringa) [Zoosk](https://www.zoosk.com/) 的工程副總裁。 Zoosk 是一個擁有 5000 萬會員的浪漫社交網絡。* 當我們的會員可以實時互動時，他們會從 Zoosk 中獲得最大的收獲。 畢竟，用戶建立的每個連接的另一端可能是將來的關系。 這種情況的刺激性和豐富性只能實時實現。 實時通信（RTC）的一般說明引用了促進這些交互的 Zoosk 服務套件。 這些通信使用 XMPP 協議進行傳遞，該協議還為其他流行的即時消息傳遞產品提供了支持。 Zoosk 成員在三種不同的交互中體驗實時通信： * **存在**。 當成員主動連接到 Zoosk RTC 基礎結構時，其公開身份顯示為“可用”。 如果它們閑置了一段時間，它們的狀態將轉換為“離開”。 當他們關閉或斷開客戶端應用程序的連接時，其狀態會自動變為“離線”。 成員還可以選擇對其他用戶“不可見”。 此選項允許他們保留在 Zoosk 服務上并查看其他在線成員，但不會在其他用戶的花名冊中出現。 * **通知**。 重要的交互在視覺上被打包為“敬酒”，并附帶短消息。 敬酒向用戶表示事件，例如收到調情，查看其個人資料或與其他用戶匹配。 Zoosk 服務利用這些通知包來通知客戶端應用程序更新與 UI 相關的徽章的值，例如來自另一個用戶的未讀消息的數量。 * **消息傳遞**。 如果兩個用戶同時在線，則他們可以以熟悉的“即時消息”聊天格式相互發送消息。 這些消息通過 RTC 基礎結構實時傳輸。 如果用戶將來使用其他客戶端應用程序重新連接，則消息內容也將保留到數據庫中，以供將來檢索消息歷史記錄。 目前，這些通信已通過網絡瀏覽器，iPhone 應用程序，iPad，Android 和可下載的桌面應用程序傳遞給 Zoosk 所有主要產品上的用戶-Zoosk.com 網站和 Facebook 應用程序。 ### RTC 基礎結構 這些 RTC 服務是通過高性能和可擴展的基于 XMPP 的基礎結構提供的。 由開源 Jabber 服務器 [Tigase](http://www.tigase.org) 支持的聊天服務是此服務的核心。 Tigase 用 Java 編寫，我們的平臺團隊創建了許多自定義擴展來處理 Zoosk 特定的業務邏輯。 Tigase 部署在基于 Linux 的標準 8 CPU 應用服務器類計算機上。 Tigase 服務器配置在成對的群集中，主要和次要節點通過負載平衡器進行管理。 所有連接一次都定向到主節點。 如果對主服務器的服務檢查失敗，則負載平衡器將立即開始將用戶流量重定向到輔助服務器。 這些成對的群集中有 18 個，每個群集可隨時處理 4,000 至 8,000 個連接。 除了用于傳輸 XMPP 流量的套接字連接之外，Tigase 還包括一項用于支持 HTTP 上的 BOSH 連接的服務。 BOSH 是我們允許網絡瀏覽器瀏覽 Zoosk.com 和我們的 Facebook 應用程序以保持與 Tigase 的持久連接的協議。 我們的桌面應用程序和移動應用程序使用標準的 TCP-IP 套接字連接。 [ ](http://farm9.staticflickr.com/8297/7872925374_a93ee99bf9_o.png) 全尺寸 Tigase 服務器通過 Tigase 和客戶端應用程序（Web 瀏覽器，移動設備，桌面應用程序）之間的持久連接實時進行實時傳輸。 Zoosk 的許多核心產品功能，包括搜索結果，配置文件視圖和消息傳遞，都需要確保在所有客戶端應用程序上幾乎實時地反映這種狀態。 為使此狀態在 Zoosk 基礎結構的其余部分中保持一致，用戶數據庫中的用戶記錄將更新以反映其當前的在線狀態，包括其最新在線轉換的時間戳。 用戶的在線狀態也存儲在我們搜索基礎架構的緩存中，以便搜索結果可以考慮在線狀態。 Zoosk 搜索功能由一層 SOLR 服務器提供支持。 我們已經擴展了每個 SOLR 服務器，以包括一個 ehcache 實例來存儲當前在線的那些用戶。 通過稱為在線狀態管理器（OSM）的專用 Tigase 實例實時更新此在線狀態緩存。 OSM 從主要的 Tigase 聊天服務器接收指示用戶在線狀態的自定義 XMPP 數據包，然后進行網絡調用以更新每個 SOLR 服務器上的 ehcache 實例。 在高峰流量期間，每分鐘大約有 8,000 個這些在線狀態轉換。 通過在 SOLR 索引之外維護此緩存，可以實時更新用戶的狀態，而與從主節點到從節點的定期索引復制快照分開。 然后，在查詢時將用戶的狀態與搜索結果結合起來，以根據用戶當前是否在線對結果進行過濾或排名。 搜索算法更喜歡在線用戶，因為這會鼓勵實時通信并為其他用戶提供更豐富的體驗。 [ 核心 RTC 功能之外的用戶與 Zoosk 服務的交互也可以觸發業務邏輯，該邏輯會向連接的用戶生成實時通知。 例如，如果另一個用戶查看了我們的用戶個人資料，或者接受了該用戶的好友請求，我們希望立即將該操作通知我們的用戶。 基于 PHP 的 Web 應用程序將觸發異步作業，該異步作業將打開與 Tigase 服務器的網絡連接，并將 XMPP 數據包傳遞到服務器，而自定義消息有效負載將為通知提供數據。 此數據包由 Tigase 處理，并路由到當前連接用戶的客戶端應用程序。 然后，用戶的客戶端應用程序將處理此自定義數據包，并向用戶顯示適當的“祝酒”，或更新“徽章”，以反映特定功能指標的當前值（配置文件視圖數，未讀消息等）。 如果用戶當時處于脫機狀態，則 Tigase 將存儲數據包，直到用戶重新連接為止。 屆時，它將自定義數據包傳遞給用戶的客戶端應用程序。 ### 監視和測試 Zoosk 技術運營團隊已經建立了多種方法來測試和監視 RTC 基礎結構的運行狀況，以確保響應能力和可用性。 這些測試主要涉及各種機制來從 Tigase 服務器收集性能數據，或模擬實際的用戶交互。 如果特定的運行狀況檢查失敗或性能數據超出既定閾值，則我們的 Nagios 安裝將生成警報。 * **Tigase Monitor** -這是一個每 10 分鐘在 cron 上運行的腳本。 它登錄到所有主要的聊天服務器，并測試連接和狀態傳輸。 它記錄這些測試的結果，并將更新發送給 Nagios，以確定是否生成警報。 * **Tigase 的性能指標**-這些內容涵蓋了各種內部 Tigase 指標，包括執行關鍵功能的時間，消息計數，隊列大小，內存消耗等。這些值每 2 分鐘由臨時統計收集一次 通過 XMPP 管理界面命令。 然后將這些度量傳遞到 Ganglia 進行繪圖。 * **商業智能報告**-腳本每小時檢查一次與每個主 Tigase 服務器的活動連接數，以及它在前一個小時內傳遞的消息數。 該數據被加載到數據庫中。 定制的 Excel 報告可以連接到該數據源，并提供具有易于比較的歷史趨勢的數據摘要視圖。 * **Tigase 測試套件**-這是一個無頭 XMPP 客戶端，它登錄到每個 Tigase 服務器并模擬真實的交互。 然后，TTS 將記錄其功能測試的結果，以供團隊審核。 ### [ ](http://farm9.staticflickr.com/8296/7872943312_1d3a7026d0_o.png) 全尺寸 下一步 展望未來，我們將繼續積極探索為 Zoosk 會員提供實時體驗的新方法。 我們將在下個月向我們的移動 Web 應用程序（Touch）推出 RTC 支持。 交付 Zoosk 應用程序的其他設備或介質將類似地進行實時連接。 隨著我們的成員增加主動連接到 Zoosk 應用程序的時間，我們計劃增強基于 RTC 的功能，以促進成員之間的發現和通信。 這里的圖形（可能是無意間）泄漏了 Zoosk.com 上的活動用戶數。 實際上，它泄漏的是任何一次活動用戶的數量。 馬特假設同一個人整天都保持登錄狀態。 但是當涉及到[擴展其實時平臺](http://zooskdev.wordpress.com/2011/09/13/4-tricks-to-going-real-time-for-tech-ops/)時，Zoosk 并不太緊。 18 個服務器之間僅 150k 并發用戶的負載平衡又如何呢？ 僅一個 tigase 實例就夠這么低的容量嗎？ 也許這只是出于過現實的冗余因素？ 我可以為這樣的公司工作！