對于一個即時通信服務(wù)器來說，在用戶量少的時候，一臺服務(wù)器就足以提供所有的服務(wù)。而這種架構(gòu)也最簡單，舉個例子，用戶A與用戶B互為好友，A向B發(fā)消息，服務(wù)器接收到消息時，解析出接收消息的人，直接轉(zhuǎn)發(fā)給B即可。可是當(dāng)用戶數(shù)量越來越多時，一臺服務(wù)器已經(jīng)無法所有用戶的需求，這時就要進(jìn)行服務(wù)擴(kuò)容，進(jìn)行分布式部署
如圖所示，不同的用戶可能登錄到不同的服務(wù)器上，那么用戶A給用戶B發(fā)消息時，服務(wù)器收到消息，首先判斷B是否也登錄在本服務(wù)器上，如果是，那么直接轉(zhuǎn)發(fā)消息即可。如果B不在本服務(wù)器上，那應(yīng)該往哪里轉(zhuǎn)發(fā)這條消息呢？最簡單的做法就是向服務(wù)器集群中的其他服務(wù)器廣播這條消息，對于每個收到這條消息的服務(wù)器，首先判斷消息的目的用戶是否登錄在自己身上，如果不是，直接忽略該消息。如果是，那么向目的用戶轉(zhuǎn)發(fā)該消息。固然，這種暴力粗獷的做法是最簡單直接的，但是會產(chǎn)生很多無效的消息轉(zhuǎn)發(fā)，對于服務(wù)器性能產(chǎn)生很大的影響。曾看過蘑菇街開源的即時通信軟件Teamtalk的代碼，服務(wù)器就是這種實現(xiàn)方式。其服務(wù)器架構(gòu)如下：
不同的msg服務(wù)器連接到同一臺route server上,所有msg服務(wù)器之間的轉(zhuǎn)發(fā)全部通過route server。這無疑會加重route server的負(fù)載。即時msg server部署的再多，根據(jù)木桶理論，一個系統(tǒng)的性能是由其最薄弱的環(huán)節(jié)所決定的。所以也注定這樣的架構(gòu)，其系統(tǒng)容量也是有限的。那么如何改善這種系統(tǒng)呢，很明顯服務(wù)器之間的消息轉(zhuǎn)發(fā)不能直接全部廣播，而應(yīng)該有一套明確的路由系統(tǒng)，即服務(wù)器在轉(zhuǎn)發(fā)消息時，應(yīng)該知道這條消息應(yīng)該轉(zhuǎn)發(fā)到哪一臺服務(wù)器，這樣就不需要每條消息都在所有服務(wù)器之間廣播了。
那么如何實現(xiàn)這樣一套路由系統(tǒng)呢？
簡單的做法是，每個用戶上線時，通過其連接的msg server向其他所有msg server廣播自己的登錄信息，告知其他服務(wù)器自己登錄在哪臺服務(wù)器上面。這樣當(dāng)某個用戶向其好友發(fā)消息時，首先通過好友id查看其登錄的msg server。如果好友與自己是同一臺服務(wù)器，那么直接轉(zhuǎn)發(fā)即可；如果不是，服務(wù)器向route server發(fā)送轉(zhuǎn)發(fā)該消息，并且?guī)夏繕?biāo)msg server的id.這樣route server 收到消息后，解析出目標(biāo)的msg server，進(jìn)行一次轉(zhuǎn)發(fā)即可，省去了大量的廣播消息。這種方式雖然解決了廣播消息的問題，但是在每臺msg server上都要保存所有用戶的路由信息。當(dāng)所有用戶都登錄時，幾乎就退化成了單點(diǎn)模型，msg server肯定承受不了。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式