服務器的消息推送方法和裝置的制造方法
【技術領域】
[0001] 本發(fā)明設及計算機領域，具體來說，設及一種服務器的消息推送方法和裝置。
【背景技術】
[0002] 在企業(yè)級的系統(tǒng)中，尤其是需要實現服務器后臺數據不斷同步到客戶端的監(jiān)控W 及即時事件消息的云計算系統(tǒng)的開發(fā)中，在BS的架構下，怎樣能夠讓后臺數據高效即時穩(wěn) 定的推送到前端頁面一直是一個難題，尤其是能夠支持信息的離線獲取推送。運里需要考 慮兩個方面的問題，一個是消息源的獲得，另外一個是消息的高效即時推送。
[0003] 在過去的服務器推送技術發(fā)展中，使用ajax短輪詢及長輪詢的方式最為常見，它 們都是通過基于原始的ht化請求服務器間歇性地獲取數據，從某種意義上講屬于服務器 拉取的方式，即客戶端主動向服務器發(fā)送獲取數據的請求，而不是服務器端。短輪詢方式是 每次請求后立即返回，但長輪詢是請求后不會立即返回而是將請求掛起直到服務器端有數 據后才返回到客戶端。
[0004] 在另一方面，如何實現消息的離線推送也是一個在過去的解決方案中不能很好解 決的問題，運里需要解決服務器已經推送到前端但是前端還未及時呈現的消息怎樣才能夠 再次呈現出來，而且能夠對于不同頁面的切換實現頁面式的信息推送?，F有技術大多采用 的是服務器級別的session存儲或者是本地cookie存儲，而在本系統(tǒng)設計中本發(fā)明采用的 是WebStorage技術。 陽0化]對于采用ajax短輪詢技術來說，需要從客戶端定時的向服務器端發(fā)送請求，實現 定時刷新的效果，但是由于運種方式不能準確的知曉服務器端是否真的有消息需要推送而 浪費了大量請求，而又由于每次請求都需要經歷一個基本的ht化連接建立、請求發(fā)送、響 應返回、連接斷開的過程，使得客戶端和服務器端的負載開銷都會增大，服務器消息推送的 效率會明顯低下。而采用長輪詢的方式，雖然減少了無效請求的次數，但是在服務器端有大 量消息進行推送的情況下，依然和短輪詢一樣會加大服務器和客戶端的負載，極大可能出 現頁面卡死或者無響應的情況，降低了用戶體驗效果。
[0006] 在信息的離線存儲方面，采用服務器級別的session存儲太依賴于服務器后臺環(huán) 境，因為它是在服務器端進行編譯后響應到客戶端并存儲在客戶端瀏覽器中的，一旦后臺 環(huán)境發(fā)生改變，實現方式也都需要進行重構。無法做到離線環(huán)境的解禪。顯然采用服務器 級別的存儲會存在運樣的弊端，那么就要考慮瀏覽器客戶端級別的存儲，運個目前采用最 多的解決方式就是利用瀏覽器cookie,但是cookie方式也存在W下兩大問題：數據大小： 作為存儲容器，cookie的大小限制在4邸左右，對于現在復雜的業(yè)務邏輯需求和大容量的 信息存儲已經無法滿足；網絡負擔：cookie會被附加在每個HTTP請求中，在化化Request 和化化Response的header中都是要被傳輸的，運對于只為了實現消息的離線存儲是沒有 意義的且增加了大量的網絡負擔。
[0007] 針對相關技術中的上述問題，目前尚未提出有效的解決方案。

【發(fā)明內容】

[0008] 針對相關技術中的上述問題，本發(fā)明提出一種服務器的消息推送方法和裝置，能 夠提高服務器端的消息推送效率，提升用戶體驗感。
[0009] 本發(fā)明的技術方案是運樣實現的：
[0010] 根據本發(fā)明的一個方面，提供了一種服務器的消息推送方法。
[0011] 該消息推送方法包括：
[0012] 接收客戶端的Websocket連接請求，根據Websocket連接請求在服務器端建立與 客戶端的Websocket連接；
[0013] 服務器端基于Websocket連接發(fā)送頁面消息；
[0014] 其中，服務器端處建立的Websocket連接與消息中間件整合在一起。
[0015] 此外，該消息推送方法進一步包括：
[0016] 在建立Websocket連接后，將客戶端的當前用戶ID與Websocket連接綁定；
[0017] 將該Websocket連接存儲至對應當前用戶ID的第一連接集合中。 陽018] 可選的，該消息推送方法進一步包括：
[0019] 建立對Websocket連接的監(jiān)聽連接；
[0020] 將監(jiān)聽連接存儲至第一連接集合中。
[0021] 另外，該消息推送方法還包括：
[0022] 在建立Websocket連接后，判斷客戶端的當前用戶是否創(chuàng)建與客戶端的當前用戶 ID關聯(lián)的MQ連接；
[0023] 如果沒有創(chuàng)建MQ連接，則從MQ連接池中獲取一個新的MQ連接并存儲至第一連接 集合中。
[0024] 此外，該消息推送方法進一步包括：
[00巧]在斷開客戶端與服務器端的Websocket連接時，將該Websocket連接從第一連接 集合中移除；
[0026] 判斷該Websocket連接是否是客戶端的用戶ID下的最后一個Websocket連接；
[0027] 在判斷為是的情況下，將對應該用戶ID的MQ連接回收至MQ連接池，并將該MQ連 接從第一連接集合中移除。
[0028] 另外，該消息推送方法進一步包括：
[0029] 在客戶端監(jiān)聽到來自服務器端的推送消息的情況下，檢測用戶的當前頁面所在的 業(yè)務模塊；
[0030] 檢測推送消息所屬于的業(yè)務模塊；
[0031] 在判斷用戶的當前頁面所在的業(yè)務模塊與推送消息所屬于的業(yè)務模塊相同的情 況下，將推送消息推送至當前頁面；
[0032] 在判斷用戶的當前頁面所在的業(yè)務模塊與推送消息所屬于的業(yè)務模塊不同的情 況下，將推送消息進行離線存儲。
[0033] 另外，該消息推送方法進一步包括：
[0034] 在客戶端進入一個新的頁面的情況下，確定新的頁面的業(yè)務模塊；
[0035] 檢測離線存儲的推送消息中是否存在對應業(yè)務模塊的推送消息；
[0036] 如果存在對應業(yè)務模塊的推送消息，則將該推送消息推送至新的頁面，并將該推 送消息從離線存儲中刪除。
[0037] 其中，位于客戶端的瀏覽器端的原生的Websocket接口預先經過二次封裝。
[0038] 此外，客戶端的瀏覽器端的Websocket連接為單例模式。
[0039] 根據本發(fā)明的另一方面，提供了一種服務器的消息推送裝置。
[0040] 該消息推送裝置包括： 陽041] 接收建立模塊，用于接收客戶端的Websocket連接請求，根據Websocket連接請求 在服務器端建立與客戶端的Websocket連接；
[0042] 發(fā)送模塊，用于基于Websocket連接發(fā)送頁面消息；
[0043] 其中，服務器端處建立的Websocket連接與消息中間件整合在一起。
[0044] 本發(fā)明通過在服務器端將Websocket連接進行統(tǒng)一管理和分配，并將其與消息中 間件整合在一起，能夠提高服務器端的消息推送效率，提升用戶體驗感。
【附圖說明】 W45] 為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案，下面將對實施例中所 需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施 例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可W根據運些附圖獲 得其他的附圖。
[0046] 圖1是根據本發(fā)明實施例的服務器的消息推送方法的流程圖；
[0047] 圖2是根據本發(fā)明實施例的Websocket時序圖； W48] 圖3是根據本發(fā)明實施例的創(chuàng)建Websocket連接和MQ連接的流程圖； W例圖4是根據本發(fā)明實施例的斷開Websocket連接和MQ連接的流程圖；
[0050]圖5是根據本發(fā)明實施例的推送消息的存儲策略流程圖；
[0051] 圖6是根據本發(fā)明實施例的離線消息的推送策略流程圖；
[0052] 圖7是根據本發(fā)明實施例的服務器的消息推送框架的示意圖；
[0053] 圖8是根據本發(fā)明實施例的服務器的消息推送裝置的框圖。
【具體實施方式】
[