淺談teamtalk

       蘑菇街開源的teamtalk可以作為2-3年初學者學習之用，或者小型公司當作内部im辦公交流之用。至于源碼講解，網上開源的挺多。迷茫且閑着沒事的初學者們可以簡單看看，看網絡架構大概一天可以看明白，看業務，大概需要一到兩周，需要去centos7.0以上部署下，msgserver可以看完代碼配置2個試試，調試。用戶端代碼也可以簡單看看。還是有一定價值的，像網絡架構通用，簡單，沒有過多炫技，且業務邏輯簡單實用，資料表的設計，我之前調試的時候，裡面是缺了一張表，具體那張表記不太清了。不過不影響大局。通信協定用的是protobuf，簡單搞笑，雖然可視化程度不夠，但取舍之下相對于後端來說，protobuf前後相容（此處可以看看為啥相容），各個語言都支援，使用起來也簡單。

     可供學習的點，大概如下幾點：

     1：網絡庫設計包括定時器設計，消息隊列設計，逾時處理這裡。

     2：protobuf使用學習，logserver裡面的http解析代碼可以簡單看看。

     3：整體邏輯架構設計，業務設計，資料表設計。

     4：一個使用者登出伺服器這裡如何處理可以簡單看看。

      可優化的點，大概有如下幾點：

     1：裡面的網絡架構，大多是單程序單線程服務，雖說可以部署多程序，但難免消耗資源，且配置檔案搞起來也比較麻煩。此處可以修改為類似muduo這種的，單線程處理網絡收發包，多線程處理消息隊列（此處可以後續接着探讨網絡庫如何設計），或者直接修改teamtalk的源碼，單線程接受fd，多線程處理網絡收發包以及具體消息業務邏輯。

    2：日志子產品，teamtalk裡面用的日志是log4，之前搞用戶端的時候市面上倒是有一些公司，用的是log4，伺服器來說倒是少見。日志子產品，不清楚底層實作，容易出問題，自己寫個日志子產品倒是也不難，此處建議自己寫用來替換。市面上有兩種日志子產品設計方法：1：直接同步寫，這樣設計邏輯簡單，但多線程寫容易亂序且會對同步線程造成損耗。2：異步寫，抛到線程裡，用任務隊列去消費日志，可以先寫緩存，再寫磁盤。且任務隊列大小要做限制，日志一條長度也要做限制，一個日志檔案大小也要做限制。市面上也有兩種日志存儲形式：1：在目前服務log目錄下，2：在系統某個目錄下。此處仁者見仁，智者見智。還有一些公司日志檔案分為三種：error，debug，sys，這樣會導緻日志分散，不易于查找問題。不建議這種存儲方法。簡單寫寫自己玩玩倒是可以，網上也有類似代碼。不作贅述。

   3：最重要的設計上面的缺陷在于單點routeserver，此處作為存儲所有使用者關系的緩存服務以及資料轉發服務，後端來說，單點一旦崩潰，整個程式無法運作。此處可以修改為使用者關系存在redis裡，最好搞一個redis叢集模式，具體叢集如何設計網上有文章可以查到。且群使用者線上這裡可以搞一個redis hash key設計，key為群号。redis 叢集99.99%的可靠性。轉發還是在routeserver這裡。msgserver這裡轉發之前去查找群使用者具體在那台機器上，然後定向轉發，避免浪費網絡帶寬，此處做一次查詢，也提高效率。

   4：圖檔，以及檔案管理這裡，這裡直接磁盤存儲檔案圖檔，如檔案過多，會導緻讀取效率，磁盤io大幅變低，此處可以搞個什麼分布式的小檔案管理系統或者資料庫啥的。具體啥，網上應該也一大堆檔案，可以簡單了解下。

   5：消息緩存設計，此處可以添加redis 叢集或者ldb作消息緩存，以防止消息過多，mysql爆掉，mysql可以搞個主從啥的，防止丢資料。

   6：loginserver設計，此處負載均衡設計，可以搞一個類似nginx這樣的dns負載，或者lvs之類的，大多都是配置域名登入，然後域名解析作負載均衡處理這樣。

本人qq交流群：242598595。有啥商榷之處，可以交流探讨，常年不定時線上。

在轉載此站點文章時，希望可以聲明原作者 ，感謝。