推拉結合的即時通信消息獲取系統和方法
【專利摘要】本發明公開了一種推拉結合的即時通信消息獲取系統和方法，其中，推拉結合的即時通信消息獲取系統，包括，通訊消息版本號模塊：給用戶端分配通訊消息版本號；分布式緩存/存儲模塊：存儲通訊消息發送隊列和對應通訊消息版本號，獲取用戶端當前已分配的最大通訊消息版本號，并對通訊消息版本號進行遞增操作；通訊消息推送模塊：采用在線消息即時推送和定時消息集中補償的方式給客戶端發送消息；通訊消息拉取模塊：當客戶端接收到服務端推送的通知報文時，客戶端向發起服務端發起請求，獲取未到達的消息。實現將通訊消息安全、靈活、高效且可靠的推送給通訊客戶端的優點。
【專利說明】
推拉結合的即時通信消息獲取系統和方法
技術領域
[0001 ]本發明涉及通信領域，具體地，涉及一種推拉結合的即時通信消息獲取系統和方法。
【背景技術】
[0002]隨著互聯網移動化智能化，互聯網APP、移動APP、企業應用、網上商城，網絡游戲等產品發展迅速，這些產品或多或少的會依賴即時通訊服務，一部分產品甚至以即時通訊服務為產品和功能的入口。目前，市場上存在很多即時通信的產品和服務，這些產品的質量也是參差不齊。對任何一個即時通訊的產品和服務，有以下的問題不可避免的需要重視和考慮:
通訊消息在傳輸中，由于網絡問題，或者服務器故障，導致消息不能及時到達目標，有一定的延遲，甚至永久丟失。這種情況可能給用戶帶來了許多不便，甚至造成了一些資源浪費和財產損失。并且發生這種情況后，用戶會對產品和服務出現不信任的態度，并很可能會考慮尋求類似的產品做替換。
[0003]而為了解決上一個問題，不同的公司和組織設計了各種方案，其中很多方案需要服務器和客戶端做大量的編程和更改，甚至需要犧牲很大的效率，才能提高消息的一部分可靠性。
[0004]由于上一個問題中解決方案的復雜度，服務器和客戶端的故障率都很可能增加，并且嚴重影響服務器的更新和擴展性，服務可用率不升反降。不良的解決方案反而會將產品帶入一個惡性循環，為了解決消息不可靠的問題而提出的解決方案，反而導致了產品和服務更加的不可靠。
[0005]
【發明內容】
[0006]本發明的目的在于，針對上述問題，提出一種推拉結合的即時通信消息獲取系統和方法，以實現將通訊消息安全、靈活、高效且可靠的推送給通訊客戶端的優點。
[0007]為實現上述目的，本發明采用的技術方案是:
一種推拉結合的即時通信消息獲取系統，包括，通訊消息版本號模塊、分布式緩存/存儲模塊、通訊消息推送模塊和通訊消息拉取模塊；
所述通訊消息版本號模塊:給用戶端分配通訊消息版本號；
所述分布式緩存/存儲模塊:存儲通訊消息發送隊列和對應通訊消息版本號，獲取用戶端當前已分配的最大通訊消息版本號，并對通訊消息版本號進行遞增操作；
所述通訊消息推送模塊:采用在線消息即時推送和定時消息集中補償的方式給客戶端發送消息；
所述通訊消息拉取模塊:當客戶端接收到服務端推送的通知報文時，客戶端向發起服務端發起請求，獲取未到達的消息。
[0008]優選的，所述通訊消息版本號模塊分配的通訊消息版本號，為從O開始遞增的長整形數字。
[0009]優選的，所述分布式緩存/存儲模塊，使用key-value數據庫實現。
[0010]優選的，所述在線消息即時推送具體為:
兩個在線的通訊客戶端發送消息時，通訊服務端對通訊消息進行轉發，并且通過消息回執和通訊消息版本號保證消息到達通訊客戶端。
[0011]優選的，所述定時消息集中補償具體為:
當一定時間內，在線的通訊客戶端沒有使用回執將通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至通訊客戶端，通知通訊客戶端主動拉取通訊消息，直到通訊客戶端發送消息回執確認消息到達。
[0012]優選的，所述通訊消息拉取模塊獲取未到達的消息時，請求的方式采用HTTP或HTTPS方式，并啟用壓縮和緩存機制。
[0013]同時本發明技術方案還公開一種推拉結合的即時通信消息獲取方法，包括，
步驟1、即時通信客戶端A通過即時通信服務端發送消息給即時通信客戶端B;
步驟2、即時通信服務端接收到來自即時通信客戶端A的通信消息后，判斷即時通信客戶端A的權限和消息合法性，滿足條件后，即時通信服務端發送消息到達回執給即時通信客戶端A;
步驟3、即時通信服務端為該條發送給即時通信客戶端B的消息分配通訊消息版本號，并將該條信息和通訊消息版本號緩存/存儲；
步驟4、判斷即時通信客戶端B是否在線，如即時通信客戶端B離線則結束；
步驟5、如即時通信客戶端B在線，則推送通訊消息給即時通信客戶端B;
步驟6、如果即時通信服務端接收到來自即時通信客戶端B對該條消息的回執，將該條消息標記為已到達，結束；
步驟7、如果即時通信服務端沒有接收到即時通信客戶端B對該條信息的回執，則將該條消息進行定時消息集中補償機制處理；
步驟8、當滿足定時消息集中補償機制的處理條件時，即時通信服務端將提醒即時通信客戶端B有沒有接收的消息，即時通信客戶端B收到通知報文后將通過消息拉取的方式獲取通訊消息。
[0014]優選的，所述定時消息集中補償機制具體為:當一定時間內，在線的即時通訊客戶端沒有使用回執將即時通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至即時通訊客戶端，通知即時通訊客戶端主動拉取通訊消息，直到即時通訊客戶端發送消息回執確認消息到達。
[0015]本發明的技術方案具有以下有益效果:
本發明以推拉結合的消息收取為基礎，實現了在即時通訊過程中，消息傳遞的即時可靠。采用此方式，一方面即時通訊消息不會長時間延遲和丟失。另一方面，服務器效率不會有明顯下降.與現有技術的區別之處主要為:
目前的很多即時通訊實現，為將消息周期重復的推送給客戶端，一旦客戶端下載失敗，會再次進行重試，在客戶端處于網絡不穩定情況下，會大大的影響服務器吞吐量；
而本發明使用推拉結合的推送機制，消息在服務器端有積壓時，服務器采用大量短小的通知消息替代實際的體積很大的消息，將通知消息推送給客戶端。
[0016]這種方式在簡化服務器和客戶端設計，減少故障率，且便于服務器更新和橫向擴展有很明顯的優勢;并且該機制很好的平衡了服務器性能和消息的實時性，在稍微降低服務器性能的情況下，能夠達到秒級的消息延遲。
[0017]而而在客戶端收到通知后，通過HTTP短連接方式獲取。采用HTTP連接不需要服務器和客戶端實現自己的報文響應回執，僅僅需要靈活設置重試策略。
[0018]下面通過附圖和實施例，對本發明的技術方案做進一步的詳細描述。
【附圖說明】
[0019]圖1為本發明實施例所述的推拉結合的即時通信消息獲取系統的邏輯關系框圖；
圖2為本發明實施例所述的推拉結合的即時通信消息獲取方法的流程圖；
圖3為本發明實施例所述的客戶端與服務器交互過程流程圖。
【具體實施方式】
[0020]以下結合附圖對本發明的優選實施例進行說明，應當理解，此處所描述的優選實施例僅用于說明和解釋本發明，并不用于限定本發明。
[0021]—種推拉結合的即時通信消息獲取系統，包括，通訊消息版本號模塊、分布式緩存/存儲模塊、通訊消息推送模塊和通訊消息拉取模塊；
通訊消息版本號模塊:給用戶端分配通訊消息版本號；
分布式緩存/存儲模塊:存儲通訊消息發送隊列和對應通訊消息版本號，獲取用戶端當前已分配的最大通訊消息版本號，并對通訊消息版本號進行遞增操作；
通訊消息推送模塊:采用在線消息即時推送和定時消息集中補償的方式給客戶端發送消息；
通訊消息拉取模塊:當客戶端接收到服務端推送的通知報文時，客戶端向發起服務端發起請求，獲取未到達的消息。
[0022]優選的，通訊消息版本號模塊分配的通訊消息版本號，為從O開始遞增的長整形數字。
[0023]分布式緩存/存儲模塊，使用key-value數據庫實現。
[0024]在線消息即時推送具體為:
兩個在線的通訊客戶端發送消息時，通訊服務端對通訊消息進行轉發，并且通過消息回執和通訊消息版本號保證消息到達通訊客戶端。
[0025]定時消息集中補償具體為:
當一定時間內，在線的通訊客戶端沒有使用回執將通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至通訊客戶端，通知通訊客戶端主動拉取通訊消息，直到通訊客戶端發送消息回執確認消息到達。
[0026]通訊消息拉取模塊獲取未到達的消息時，請求的方式采用HTTP或HTTPS方式，并啟用壓縮和緩存機制。
[0027]同時本發明技術方案還公開一種推拉結合的即時通信消息獲取方法，包括，
步驟1、即時通信客戶端A通過即時通信服務端發送消息給即時通信客戶端B; 步驟2、即時通信服務端接收到來自即時通信客戶端A的通信消息后，判斷即時通信客戶端A的權限和消息合法性，滿足條件后，即時通信服務端發送消息到達回執給即時通信客戶端A;
步驟3、即時通信服務端為該條發送給即時通信客戶端B的消息分配通訊消息版本號，并將該條信息和通訊消息版本號緩存/存儲；
步驟4、判斷即時通信客戶端B是否在線，如即時通信客戶端B離線，則結束；
步驟5、如即時通信客戶端B在線，則推送通訊消息給即時通信客戶端B;
步驟6、如果即時通信服務端接收到來自即時通信客戶端B對該條消息的回執，將該條消息標記為已到達，結束；
步驟7、如果即時通信服務端沒有接收到即時通信客戶端B對該條信息的回執，則將該條消息進行定時消息集中補償機制處理；
步驟8、當滿足定時消息集中補償機制的處理條件時，即時通信服務端將提醒即時通信客戶端B有沒有接收的消息，即時通信客戶端B收到通知報文后將通過消息拉取的方式獲取通訊消息。
[0028]優選的，所述定時消息集中補償機制具體為:當一定時間內，在線的即時通訊客戶端沒有使用回執將即時通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至即時通訊客戶端，通知即時通訊客戶端主動拉取通訊消息，直到即時通訊客戶端發送消息回執確認消息到達。
[0029]推拉結合的即時通信消息獲取方法。其特點是:
服務端使用推送方式推送即時消息。推送包括以下兩種方式:
1、在線消息即時推送的方式。服務器除了推送外，使用回執保證消息到達。沒有收到回執的報文都認為發送失敗，要求客戶端重新發送。使用這種簡單的方式，可以高效的解決客戶端網絡不穩定情況下的報文丟失；
2、在線消息集中補償的方式。服務器周期性檢測客戶端沒有收取的消息數量，在用戶可以接受的時間范圍內，快速大量的發送體積短小的通知消息，通知客戶端需要收取消息，客戶端使用下述拉取的方式獲取。
[0030]客戶端使用拉取方式獲取即時消息。即服務端使用推送方式中已經說明的補償方式通知客戶端，客戶端收到通知后，采用HTTP短連接主動請求消息。
[0031]這種方式，有以下好處:
1、可以很大程度上的簡化服務器推送消息失敗后重試的處理邏輯;如果采用推送重試的方式，需要服務端和客戶端進行多次回執，邏輯復雜繁瑣，且客戶端與服務器需要執行大量的周期任務。
[0032]2、在客戶端不可達時，通過發送簡單的通知消息，替代發送完整的消息報文，在客戶端物理網絡斷開(服務端無法感知客戶端離線)和消息擠壓較多的情況下，既簡化服務器處理邏輯，更可以節省數百倍甚至上千倍的服務器出口流量；
3、使用短連接可以一次性接收大量的離線消息，而不會對即時消息通道造成擁堵，這樣其他消息仍可以正常的收發，完全不影響其他業務模塊消息的實時性；
4、在這種模型下，短鏈接服務器的部署非常簡單而可靠，并且可以很容易做到橫向擴展，即簡單的通過增加部署的方式支撐逐漸增多的用戶。
[0033]本發明提出的基于推拉結合的消息收取系統主要包括四個模塊:消息版本號模塊、分布式存儲/緩存模塊、通訊消息推送模塊和通訊消息拉取模塊。此系統的邏輯關系圖如如I所示:
(I)通訊消息版本號模塊:
通訊消息版本號是實現推拉結合的消息接收機制的核心，通訊消息版本號以用戶為單元分配。發送給用戶的每條消息和該用戶的一個版本號進行對應，版本號為從O開始遞增的長整形數字。
[0034](2)分布式緩存/存儲模塊:
分布式緩存/存儲模塊需要存儲通訊消息發送隊列和對應版本號;通過該模塊，可以獲取用戶當前已分配的最大版本號，并通過對版本號進行遞增操作。該模塊可以使用比較成熟的key-value 數據庫實現，如 redis，memcached。
[0035](3)通訊消息推送模塊:
通訊消息推送模塊包括以下兩個部分和功能:
在線消息即時推送。兩個在線的通訊客戶端發送消息時，通訊服務器需要對通訊消息進行轉發，并且通過消息回執和消息版本號保證消息的到達。
[0036]定時消息集中補償，當一定時間內，在線的通訊客戶端沒有使用回執將通訊服務器推送的消息報文標記為已到達，即時通訊服務端將定期發送通知消息，通知客戶端主動拉取直到客戶端發送消息回執確認消息到達。
[0037]如圖2所示，消息推送的步驟描述如下:
1.即時通信客戶端A通過即時通信服務器發送消息給即時通信客戶端B;
2.即時通信服務端接收到來自A的通信消息后，判斷權限和消息合法性，滿足條件后，發送消息到達回執給客戶端A;
3.即時通信服務端為該條發送給B的消息分配版本號，并將該條信息和版本號緩存/存儲；
4.判斷通信客戶端B是否在線，離線則結束；
5.推送通訊消息給客戶端B;
6.如果接收到來自客戶端B的對該條消息的回執，將該條消息標記為已到達，該過程結束；
7.沒有接收到客戶端對該條信息的回執，則將該條消息進行消息補償機制處理。
[0038]8.當滿足需要處理的條件時，比如已經距發送消息間隔指定時間，將提醒客戶端有沒有接收的消息。客戶端收到通知報文后將通過消息拉取的方式獲取通訊消息。
[0039](4)通訊消息拉取模塊:
當客戶端接收到服務端推送的通知報文時，客戶端向發起服務端發起請求，獲取未到達的消息，請求的方式一般采用HTTP(S)方式，并啟用壓縮和緩存機制，使得這種方式簡單高效可靠。需要注意的是緩存機制針對特定的場景有效，并不適合所有場景。
[0040]在客戶端通過服務器交互的過程中，存在以下具體的丟包或延遲情況，下面會說明詳細的出現的場景以及本發明技術方案制如何解決場景中出現的問題:
I)客戶端發往服務器丟包。當客戶端發送消息后一定時間內沒有接收到服務端回執，則客戶端可以判定發送失敗，客戶端自定義處理即可，一般可以采用詢問重發的策略。
[0041]2)服務器處理過程中宕機。服務器在將消息存儲到高速的發送消息隊列后(不需要等待發往目標客戶端)，再將回執發送給發送端。如果存儲到發送隊列前宕機，則客戶端無法收到回執，認為發送失敗，客戶端重發;如果在存儲到發送隊列后宕機，由于服務器周期檢測發送失敗的消息，該消息會被通知給目標客戶端收取。
[0042]3)服務端發往客戶端丟包。這種情況由推送模塊內的消息補償機制保證可靠。月艮務端推送消息給客戶端且一定時間內沒有收到客戶端回執，周期性發送體積很小的通知報文，通知客戶端使用拉取方式獲取，直到客戶端成功獲取消息或離線。該流程圖3所示。
[0043]最后應說明的是:以上所述僅為本發明的優選實施例而已，并不用于限制本發明，盡管參照前述實施例對本發明進行了詳細的說明，對于本領域的技術人員來說，其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。
【主權項】
1.一種推拉結合的即時通信消息獲取系統，其特征在于，包括，通訊消息版本號模塊、分布式緩存/存儲模塊、通訊消息推送模塊和通訊消息拉取模塊； 所述通訊消息版本號模塊:給用戶端分配通訊消息版本號； 所述分布式緩存/存儲模塊:存儲通訊消息發送隊列和對應通訊消息版本號，獲取用戶端當前已分配的最大通訊消息版本號，并對通訊消息版本號進行遞增操作； 所述通訊消息推送模塊:采用在線消息即時推送和定時消息集中補償的方式給客戶端發送消息； 所述通訊消息拉取模塊:當客戶端接收到服務端推送的通知報文時，客戶端向發起服務端發起請求，獲取未到達的消息。2.根據權利要求1所述的推拉結合的即時通信消息獲取系統，其特征在于，所述通訊消息版本號模塊分配的通訊消息版本號，為從O開始遞增的長整形數字。3.根據權利要求1或2所述的推拉結合的即時通信消息獲取系統，其特征在于，所述分布式緩存/存儲模塊，使用key-value數據庫實現。4.根據權利要求1或2所述的推拉結合的即時通信消息獲取系統，其特征在于，所述在線消息即時推送具體為: 兩個在線的通訊客戶端發送消息時，通訊服務端對通訊消息進行轉發，并且通過消息回執和通訊消息版本號保證消息到達通訊客戶端。5.根據權利要求4所述的推拉結合的即時通信消息獲取系統，其特征在于，所述定時消息集中補償具體為: 當一定時間內，在線的通訊客戶端沒有使用回執將通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至通訊客戶端，通知通訊客戶端主動拉取通訊消息，直到通訊客戶端發送消息回執確認消息到達。6.根據權利要求5所述的推拉結合的即時通信消息獲取系統，其特征在于，所述通訊消息拉取模塊獲取未到達的消息時，請求的方式采用HTTP或HTTPS方式，并啟用壓縮和緩存機制。7.一種推拉結合的即時通信消息獲取方法，其特征在于，包括， 步驟1、即時通信客戶端A通過即時通信服務端發送消息給即時通信客戶端B; 步驟2、即時通信服務端接收到來自即時通信客戶端A的通信消息后，判斷即時通信客戶端A的權限和消息合法性，滿足條件后，即時通信服務端發送消息到達回執給即時通信客戶端A; 步驟3、即時通信服務端為該條發送給即時通信客戶端B的消息分配通訊消息版本號，并將該條信息和通訊消息版本號緩存/存儲； 步驟4、判斷即時通信客戶端B是否在線，如即時通信客戶端B離線則結束； 步驟5、如即時通信客戶端B在線，則推送通訊消息給即時通信客戶端B; 步驟6、如果即時通信服務端接收到來自即時通信客戶端B對該條消息的回執，將該條消息標記為已到達，結束； 步驟7、如果即時通信服務端沒有接收到即時通信客戶端B對該條信息的回執，則將該條消息進行定時消息集中補償機制處理； 步驟8、當滿足定時消息集中補償機制的處理條件時，即時通信服務端將提醒即時通信客戶端B有沒有接收的消息，即時通信客戶端B收到通知報文后將通過消息拉取的方式獲取通訊消息。8.根據權利要求7所述的推拉結合的即時通信消息獲取方法，其特征在于，所述定時消息集中補償機制具體為:當一定時間內，在線的即時通訊客戶端沒有使用回執將即時通訊服務端推送的消息報文標記為已到達時，即時通訊服務端將定期發送通知消息至即時通訊客戶端，通知即時通訊客戶端主動拉取通訊消息，直到即時通訊客戶端發送消息回執確認消息到達。
【文檔編號】H04L12/58GK105871703SQ201610385811
【公開日】2016年8月17日
【申請日】2016年6月3日
【發明人】劉豪
【申請人】用友網絡科技股份有限公司