基于websocket實現(xiàn)的im實時通訊的示例分析

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

下載源碼后的運行方法：

運行環(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ā)送群消息

設(shè)計思路

socket選型

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

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

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

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

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

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

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

• 需要判斷A是否有權(quán)限；

• 等等。。

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

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

這樣做十分之二。。。

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

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

獲取歷史消息：客戶端請求業(yè)務(wù)方(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萬人，怎么辦？？？

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

• imServer1 訂閱 redisChanne1

• imServer2 訂閱 redisChanne2

• imServer3 訂閱 redisChanne3

• imServer4 訂閱 redisChanne4

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。