基于websocket實現(xiàn)的im實時通訊的示例分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

創(chuàng)新互聯(lián)專注于企業(yè)全網整合營銷推廣、網站重做改版、洛浦網站定制設計、自適應品牌網站建設、html5、成都做商城網站、集團公司官網建設、成都外貿網站建設公司、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為洛浦等各大城市提供網站開發(fā)制作服務。

下載源碼后的運行方法：

運行環(huán)境：.NETCore 2.1 + redis-server 2.8

下載Redis-x64-2.8.2402.zip，點擊 start.bat 運行；或者修改 imServer、web 下面 appsettings.json redis 配置，指向可用的redis-server

cd imServer && dotnet run --urls="http://0.0.0.0:6001"

cd web && dotnet run --urls="http://0.0.0.0:5555"

打開多個瀏覽器，訪問 http://127.0.0.1:5555 發(fā)送群消息

設計思路

socket選型

最二的辦法是瀏覽器端使用websocket，其他端socket，這么混亂的設計最終將非常難維護。

所以強烈建議所有端都使用websocket協(xié)議，adorid/ios/h6/小程序全部支持websocket客戶端。

業(yè)務與通訊協(xié)議

im系統(tǒng)一般涉及【我的好友】、【我的群】、【歷史消息】等等。。

那么，imServer與業(yè)務方(web)該保持何種關系呢？

用戶A向好友B發(fā)送消息，分析一下：

• 需要判斷B是否為A好友；

• 需要判斷A是否有權限；

• 等等。。

諸如此類業(yè)務判斷會很復雜，我們試想一下，如果使用imServer做業(yè)務協(xié)議，它是不是會變成巨無霸難以維護。

又假如獲取歷史記錄，難道客戶端要先websocket.send('gethistory')，再在onmessage里定位回調處理？

這樣做十分之二。。。

咱這樣設計，所有用戶的主動行為走業(yè)務方(web)，imServer只負責即時消息推送。什么意思？

用戶A向好友B發(fā)送消息：客戶端請求業(yè)務方(web)接口，由業(yè)務方(web)后端向imServer發(fā)起推送請求，imServer收到指令后，向前端用戶B的websocket發(fā)送數據，用戶B收到了消息。

獲取歷史消息：客戶端請求業(yè)務方(web)接口，返回json(歷史消息)

回執(zhí)：用戶A如何知道消息發(fā)送狀態(tài)（成功或失敗或不在線）？imServer端向用戶B發(fā)送消息時，把狀態(tài)以消息的方式推給用戶A即可（按上面的邏輯），具體請看源碼吧。。。

web通知imServer性能優(yōu)化

采用消息隊列，redis的發(fā)布訂閱最為輕量。

實現(xiàn)多節(jié)點部署

單個imServer實例支持多少websocket連接，幾百個沒問題吧，好。。。

如果系統(tǒng)在線用戶有1萬人，怎么辦？？？

可以根據id的hash分區(qū)，比如部署4個imServer：

• imServer1 訂閱 redisChanne1

• imServer2 訂閱 redisChanne2

• imServer3 訂閱 redisChanne3

• imServer4 訂閱 redisChanne4

業(yè)務方(web)端根據接收方的id的hash分區(qū)算法，定位到對應的redisChannel，這樣publish就可以將消息定位到相應的imServer了 。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。