重構 WebSocket Session共享

2021-08-21 12:21:16 字數 991 閱讀 7097

最近在做訊息中心模組,想要實現訊息實時推送到前端頁面展示,直接摒棄了前端定時輪訓呼叫介面來獲取訊息資料的方式,採用了websocket服務端推送

流程是首先前端跟後端應用新建乙個連線,並攜帶當前登入的使用者id,此時websocket會建立乙個websocketsession來唯一繫結該連線,我們會在後端用map建立使用者id與session的對映關係:

map
後續有新訊息到達時,就可以通過該map對映找到指定使用者id對應的session來推送訊息。但有乙個問題,後端是多應用節點,每個節點維護乙個這樣的map,無法共享websocketsession,而且redis也無法對websocketsession序列化後進行儲存

由於專案目前用到了redis,所以可以採用redis的發布/訂閱功能來實現websocketsession共享問題。

1.新建乙個物件,屬性有userid, message,用於傳送訊息

object(string userid, string message)
2. 當新訊息到達時,將訊息註冊到redis指定topic的頻道上

convertandsent("topicname", new object(userid, message))
3.每個應用節點都訂閱該topic的頻道,這樣新訊息一註冊,每個節點都能接收到object,然後從object中獲取userid,再從對映map中獲取userid對應的websocketsession(在哪個節點建立的連線和map對映關係,就會在哪個節點找到對應的session),進行訊息推送。

就這樣通過redis的發布/訂閱功能實現session共享。當然在步驟2,新訊息到達時,可以先在本節點的map對映中查詢是否有userid對應的session,如果有,直接推送訊息,而且不必要再將訊息註冊到redis中。

重構之維 關於重構及《重構》的隨想

重構之維 關於重構及 重構 的隨想 重構 究竟重構了什麼?不止一次地,我聽到我們這個行業裡的大師們對重構技術提出 至少是 置疑 那是我們過去十五年裡一直在做的事 我從 上世紀 70年代就已經開始這樣做了 unix上的黑客們一直都是這樣做的 這些說辭讓我很有興趣探其究竟。在這本 重構 裡,martin...

為什麼要進行重構? 《重構》節選

我不想把重構說成治百病的萬靈丹,它絕對不是所謂的 銀彈 不過它的確很有價值,雖不是一顆銀子彈,卻是一把 銀鉗子 可以幫助你始終良好地控制自己的 重構是個工具,它可以 並且應該 為了以下數個目的而被運用 重構改進軟體設計 如果沒有重構,程式的設計會逐漸腐敗變質。當人們只為短期目的,或是在完全理解整體設...

重構讀書筆記 重構列表 20041028

title 重構讀書筆記 重構列表 20041028 content refactorings 重構 列表 1.add parameter 新增引數 2.change bidirectional association to unidirectional 將雙向關聯改為單項 3.change ref...