乙個支援40萬併發使用者的
企業即時通訊架構介紹
2023年04月07日 星期一 13:17
前言：看了些討論類似qq的系統的文章，自己以前參與的乙個專案，就做這個，不過規模相對小點。寫份文件，旨在清理清理思路，交流一下經驗。這裡的一些模組名稱（acs、nas），採用了以前公司的命名方式，我覺得這麼用不當，覺得沒有必要令換個名字。文中的內容與那個系統也有很大的區別，時間太長了，很多東西記不清了是乙個原因，再者一直覺得那東西問題多多，做了些更改，同時為簡單起見，去掉了很多的細節內容。準確地說這裡描述的系統應該是乙個杜撰出來的，因此我想不涉及什麼商業秘密。
一、摘要
二、整個系統的邏輯檢視
各模組的說明：
c-xx：使用者端使用自己定義的協議與nas、acs進行通訊，提供im的基本功能。
nas：為使用者c-xx分配acs伺服器，在使用者登入時進行。nas簡單的採用輪轉的方式，依次分配系統中存在的acs給登陸的使用者。
acs：為使用者提供im服務端功能，主要有使用者資訊的修改，使用者狀態的維護，使用者訊息的處理等。acs之間的邏輯結構是網狀的，任何兩個acs都可以平等的進行通訊。
db：儲存使用者的狀態，不同的db分成不同的區，維護不同段的使用者。每個acs到各個分割槽的資料庫都有連線，acs根據使用者所在的區，訪問相應的資料庫，訪問使用者的資料。
c-xx、nas、db-x的具體內容在這裡不做太多的討論，主要描述一下acs的具體結構，主要的模組如下
三、acs的主要邏輯模組
使用者定位資訊：包括使用者id，登入的acs編號，使用者登入使用的ip位址，使用者登入使用的埠(port)，使用者使用的網路型別。這些資訊是實現使用者間的通訊必需的，這些資訊的維護和獲取是系統中乙個核心任務，相關操作十分頻繁。
四、物理部署檢視
說明：nas為避免單點實效性，可以採用dns或者nat的方式，在多台伺服器之間進行負載平衡。
五、主要流程
5.1 登入處理
5.2 acs**使用者的中轉訊息的處理
簡單描述：在向指定的使用者傳送資訊的時候，需要使用者的定位資訊，這些資訊依次在好友列表，本地快取和資料庫之中進行查詢。實際測試發現，使用本地快取可以大大減少對資料庫的訪問。
5.3 通過acs**訊息
簡單描述：對於一些比較特殊的網路型別，如果需要保證資料報抵達指定使用者，最穩妥的方式就是通過目的使用者登入的acs進行中轉。在上圖中user-01登入到acs-01，user-02登入到acs-02。
後記一、支援更大規模應用的考慮
我不維護這個系統的時候，系統可以支援40萬左右。當時的感覺系統並沒有達到支援的上限，感覺可以支援到100萬左右。對於系統的近一步擴大，覺得系統還有寬展的潛力，支援更大規模的應用不是什麼問題。可以在以下方式進行擴充套件：
1、根據使用者的使用習慣，細分分割槽，減少單個資料庫的壓力。伺服器對於分割槽的變化能夠給與相應的支援。
2、對於使用者登入的acs的分配，使用複雜的策略，可以區分使用者，使用不同的acs。對於系統壓力分布的可以方便的調整。
3、感覺通過提高系統的配置性，可以實現不停的通過簡單堆疊擴充套件系統容量，使系統隨使用者數量增加不斷擴大。
二、和以前看過的一些系統的對照
後來感覺這個系統和g**系統有些相似的地方，像儲存使用者資訊和使用者狀態的資料庫有點類似hlr的功用，對於acs則有點像**c，使用者可以在各個acs登入，登入到acs後使用者資料庫中的使用者狀態要進行更新，以示其他使用者和這個使用者進行通訊。對於nas和acs集群，很像個基於dns的負載均衡系統。也許真的是萬法歸綜…
乙個支援40萬併發使用者的即時通訊架構介紹
採用私有im協議 db 使用者 好友等 採用分割槽分段的方式劃分db,不同的db分成不同的區，維護不同段的使用者.cluster 前面有乙個負責分配節點的伺服器，使用者的請求可以由任何乙個邏輯伺服器來處理。邏輯伺服器之間網狀結構。使用者所在節點find方法,可能是詢問所有網內節點，然後在本地cach...
設計乙個高併發IM即時通訊軟體的思路要點
假如要我設計乙個qq，訪問量在百萬級別併發。大致功能點 1 上線通知 2 群的訊息顯示 3 傳送訊息 4 良好擴充套件性。增加使用者能直接通過增加機器解決 5 穩定性 6 高效能 相關資料效能。1 單個節點能支援一萬左右的使用者登入 2 使用mysql資料庫儲存使用者資訊 處理策略 1 資料庫上如果...
如何實現乙個可靠的IM即時通訊應用
目前的im即時應用很多，可以有以下幾種思路 假如你有伺服器，可以採用多個客戶端連線到伺服器上，伺服器進行訊息 使用長連線的方式。可以採用xmpp協議，伺服器可以參考開源openfire。假如你沒有伺服器，可以借助第三方的im平台，通過客戶端連線到平台上，讓平台代為 訊息。這個的優勢是，不用自己開發維...