[發明專利]一種消息快速推送方法

有效

• 申請號: 202011587924.8
• 申請日: 2020-12-29
• 公開（公告）號: CN112689018B
• 公開（公告）日: 2023-03-10
• 發明（設計）人: 彭恩江
• 申請（專利權）人: 中通服公眾信息產業股份有限公司
• 主分類號: H04L67/1095
• 分類號: H04L67/1095;H04L67/142;H04L67/568;H04L67/55;H04L69/163
• 代理公司: 濟南智圓行方專利代理事務所(普通合伙企業) 37231
• 代理人: 王華

本發明公開了一種消息快速推送方法，涉及信息技術領域，技術方案為，包括，獲取網絡數據幀傳輸大小，作為傳輸標準量；以傳輸標準量對必要數據進行打包，并將打包后的數據發送給客戶端；服務端從所述數據庫中查詢對消息的必要數據再次進行查詢，獲取更多的必要數據，并保存在緩存服務器中等待下一次發送，消息的必要數據發送完成后，以消息的次要數據為發送對象，重復步驟直至次要數據發送完成。本發明的有益效果是：本方案每次傳輸的數據量都是以數據包的形式在一個數據幀中傳送，因此效率可以達到最高。客戶端無需等待多個數據包傳輸完成后進行解析操作。因此可以減少網絡延遲帶來的影響。

技術領域

本發明涉及信息技術領域，特別涉及一種消息快速推送方法。

背景技術

在安防領域中的某些場景下，需要將事件發生地的號碼(電話號碼或其他唯一的一個設備編號)發生的事件信息在調度中心的特殊終端(PC上的一個軟件)上顯示，供調度人員去指派。或者會在事件處置機構的終端上顯示，供事件處置人員閱覽。因為顯示信息的除號碼、位置以外，還包括從數據庫、第三方平臺上獲取到的信息。

在消息推送到客戶端時，一般只推送必要的號碼到客戶端，客戶端根據實際情況再向服務器查詢額外的必要信息。

由于信息顯示是基于客戶端主動發起的查詢請求，服務端根據查詢請求再進一步處理。在服務端完成響應后，客戶端才能顯示出報警信息。這其中，可能存在1次或多次的網絡請求。基于TCP/IP協議的HTTP請求存在3次握手的情況。因此整個報警信息的顯示延遲比較大(約500ms以上)。

在實時消息推送過程中，服務器的作用一般是消息的傳遞和響應客戶端對附加消息的請求，所以一般情況分兩種：

一是服務器在收到消息后，將消息轉發到客戶端，客戶端根據實際情況再次發起請求，服務端根據請求查詢響應的結果返回給客戶端，如說明書附圖1。

二是服務端在收到消息后，將客戶端所需的附加信息都準備好一次性推送給客戶端，如說明書附圖2。

現有技術的缺點是從原始消息源接到消息后，服務端或者客戶端需要等待數據庫或第三方服務返回結果后才能進行在客戶端顯示彈屏，這其中的延遲比較大，在某些對延時要求比較高的場景下，效果極其不好。

在消息傳輸過程中客戶端和服務端之間傳輸的數據一般都是基于業務邏輯數據包的形式(也就是說，即使是使用TCP流的方式進行傳輸數據，還是明顯將數據以邏輯數據包的形式進行傳輸)在數據包未完整傳輸完成的情況下，客戶端無法對數據包進行處理，需要等待當前數據包傳輸完成。

參看上述說明書附圖1和2，序列圖中數據庫和第三方服務的調用時長是一致的。

現有技術方案一，多次請求涉及到數據包來回傳送問題，即使是使用TCP長連接形式來規避TCP協議的3次握手開銷，那么客戶端請求數據包及服務端響應數據包的傳輸還是占用了一部分的時間開銷。在上述技術方案一的配圖中，傳輸次數為5次。假設每次傳輸延遲50ms，總傳輸延遲就是250ms。考慮到如果請求數據包太小會導致延遲傳輸算法延遲每次100ms，考慮到客戶端每次處理數據包的延遲100ms，則總延遲就是5*50ms+2*100ms+100ms*3＝750ms。如果考慮等待數據庫及第三方服務(假設各花費了2000ms處理各自的業務)，那么總延遲將超過4750ms。

而技術方案二，只進行了一次傳輸數據傳輸，假設每次傳輸延遲50ms，只進行了一次數據包解析，延遲100ms。等待數據庫及第三方服務(同上假設各花費了2000ms處理各自的業務)，那么總延遲將超過4150ms。

上述兩個技術方案，總延遲均超過4000ms。在對延時要求比較高的場合下應用系統，如警務系統，則不能滿足使用需求。

發明內容