• 
    <ul id="o6k0g"></ul>
    <ul id="o6k0g"></ul>

    一種消息處理方法、服務器集群及系統技術方案

    技術編號:15695739 閱讀:48 留言:0更新日期:2017-06-24 11:16
    本申請提供了一種消息處理方法、服務器集群及系統,該服務器集群包括多個隊列服務器,目標隊列服務器將第一客戶端發送的請求消息寫入目標日志文件時,觸發服務器集群中的備份隊列服務器同步該目標日志文件,在備份隊列服務器將同步的請求消息推送至對應的備份消息隊列,向目標隊列服務器反饋備份完成信息,當目標隊列服務器接收到第一預設數量的備份完成信息后,再將該請求消息推送至目標消息隊列存儲,并向第一客戶端反饋針對該請求消息的成功響應信息,從而保證請求消息的生產可靠性以及存儲可靠性;而且,由于本申請采用多副本機制,從而保證了目標隊列服務器工作異常的情況下,系統的可靠性以及可用性。

    【技術實現步驟摘要】
    一種消息處理方法、服務器集群及系統
    本申請主要涉及消息處理應用領域,更具體地說是涉及一種消息處理方法、服務器集群及系統。
    技術介紹
    在各領域應用中,客戶端之間的消息傳輸已成為實現應用業務的基本過程,參照圖1(a)所示,傳統的消息傳輸通常是消息生產者與消息消費者進行一對一傳輸,很容易導致消息丟失,且往往無法實現消息復用,影響工作效率。為了解決上述問題,如圖1(b)所示,目前通常會在消息生產者與消息消費者之間設置開源消息隊列中間件,用來存儲消息生產者生成的消息,并根據需要轉發至消息消費者,實現了消息復用,且避免了因突然產生大量消息而導致消息的丟失等問題。然而,現有的開源消息隊列中間件主要采用單擊或主從結構,一旦其中的某一個節點發生故障,將會導致整個系統不可用,在此期間若有丟失的消息,將導致消息不可回溯,從而影響系統的可靠且穩定運行;而且,當調整開源消息隊列中間件中節點數量時,將會引發全局的數據重新均衡,影響系統可用性。
    技術實現思路
    有鑒于此,本申請提供了一種消息處理方法、服務器集群及系統,采用多副本的備份機制,在目標隊列服務器工作異常情況下,保證了系統的可靠性以及穩定性。為了實現上述目的,本申請提供了以下技術方案:本申請實施例提供了一種消息處理方法,應用于服務器集群,所述服務器集群包括多個隊列服務器,所述方法包括:目標隊列服務器獲得第一客戶端發送的請求消息,所述目標隊列服務器是所述多個隊列服務器中的任意一個隊列服務器,將所述多個隊列服務器中的其他隊列服務器作為備份隊列服務器;所述目標隊列服務器將所述請求消息寫入目標日志文件,并觸發所述備份隊列服務器同步所述目標日志文件;所述備份隊列服務器將同步的所述請求消息推送至對應的備份消息隊列存儲,并向所述目標隊列服務器反饋備份完成信息;所述目標隊列服務器接收到第一預設數量的所述備份隊列服務器反饋的所述備份完成信息,將所述請求消息推送至目標消息隊列存儲,并向所述第一客戶端反饋針對所述請求消息的成功響應信息。本申請實施例還提供了一種服務器集群,包括:一個目標隊列服務器以及多個備份隊列服務器,其中:所述目標隊列服務器,用于獲得第一客戶端發送的請求消息,并將所述請求消息寫入目標日志文件,觸發所述備份隊列服務器同步所述目標日志文件;所述備份隊列服務器,用于將同步的所述請求消息推送至對應的備份消息隊列存儲,并向所述目標隊列服務器反饋備份完成信息,以使所述目標隊列服務器接收到第一預設數量的所述備份隊列服務器反饋的所述備份完成信息,將所述請求消息推送至目標消息隊列存儲,并向所述第一客戶端反饋針對所述請求消息的成功響應信息。本申請實施例還提供了一種消息處理系統,其特征在于,所述系統包括:多個客戶端以及至少一個如上所述的服務器集群。由此可見,與現有技術相比,本申請提供了一種消息處理方法、服務器集群及系統,該服務器集群包括多個隊列服務器,將其中任意一個隊列服務器作為目標隊列服務器,其他隊列服務器作為備份隊列服務器,目標隊列服務器獲得第一客戶端發送的請求消息,并將其寫入目標日志文件時,將觸發該服務器集群中的備份隊列服務器同步該目標日志文件,之后,備份隊列服務器將同步的請求消息推送至對應的備份消息隊列,并向目標隊列服務器反饋備份完成信息,當目標隊列服務器接收到第一預設數量的備份完成信息后,再將該請求消息推送至目標消息隊列存儲,并向第一客戶端反饋針對該請求消息的成功響應信息,從而保證請求消息的生產可靠性以及存儲可靠性;而且,由于本申請采用多副本機制,從而保證了目標隊列服務器工作異常的情況下,系統的可靠性以及可用性。附圖說明為了更清楚地說明本申請實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本申請的實施例,對于本領域普通技術人員來講,在不付出創造性勞動的前提下,還可以根據提供的附圖獲得其他的附圖。圖1(a)和圖1(b)為本申請提供的兩種現有的消息處理方法的示意圖;圖2為本申請實施例提供的一種消息處理方法的實現系統結構圖;圖3為本申請實施例提供的一種消息處理方法的信令流程圖;圖4為本申請實施例提供的一種消息處理方法的部分流程圖;圖5為本申請實施例提供的一種消息復用應用示意圖;圖6為本申請實施例提供的一種服務器集群的結構示意圖;圖7為本申請實施例提供的一種服務器集群中的隊列服務器的結構框圖;圖8為本申請實施例提供的另一種服務器集群中的隊列服務器的結構框圖;圖9為本申請實施例提供的又一種服務器集群中的隊列服務器的結構框圖;圖10為本申請實施例提供的一種消息隊列的系統應用示意圖;圖11為本申請實施例提供的一種服務器集群中的隊列服務器的硬件結構圖。具體實施方式下面將結合本申請實施例中的附圖,對本申請實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本申請一部分實施例,而不是全部的實施例。基于本申請中的實施例,本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例,都屬于本申請保護的范圍。為了使本申請的上述目的、特征和優點能夠更加明顯易懂,下面結合附圖和具體實施方式對本申請作進一步詳細的說明。其中,為了方便理解本申請技術方案,將對下文實施例可能涉及到的技術術語進行解釋說明,具體如下:producer:消息生產者,負責生產消息;consumer:消息消費者,負責消費消息,在本申請中,消息消費者和消息生產者可以是不同的客戶端;broker:消息中間件,負責消息的存儲,轉發,一般也稱作隊列服務器,即MQ(MessageQueue,消息隊列)server;queue:隊列模型,生產者發送消息到broker的隊列,消費者從broker隊列消費消息。leader:領導者,即下文描述的目標隊列服務器,broker中引入replication(復制)機制,每個partition(分區)可能會有多個備份,因此需要在多個MQserver中選出一個leader,producer和consumer只與這個leader交互,其他的MQserver作為follower從leader中復制數據;follower:跟隨者,即下文描述的備份隊列服務器,在本申請中,可以從leader中復制數據,保證系統可靠運行。如圖2所示,為本申請實施例提供的消息處理方法的實現系統架構圖,該系統可以包括:多個客戶端21以及至少一個服務器集群22,每個服務器集群可以包括多個隊列服務器23。其中,客戶端21可以是裝載在手機、平板電腦、筆記本電腦等用戶設備上,在實際應用中,通過與隊列服務器13建立通信連接,實現信息交互。可選的,客戶端21可以是從官方網站或應用中心等下載并安裝到用戶設備上的應用程序,也可以是以瀏覽器的形式存在,本申請對客戶端21的存在形式不作限定。在本申請實際應用中,客戶端可以包括支付客戶端、充值客戶端以及實現訂單查詢等功能的業務客戶端,具體可以根據實際業務需要確定,本申請對此不作限定。隊列服務器23可以作為消息隊列中間件,在實際應用中,可以將多個隊列服務器23組成的服務器集群作為一個Brokerset,從而保證消息的可靠性和可用性。其中,在本申請提供的系統可以包括多個Brokerset,具體可以根據實際需要確定。在本申請中,隊列服本文檔來自技高網...
    一種消息處理方法、服務器集群及系統

    【技術保護點】
    一種消息處理方法,其特征在于,應用于服務器集群,所述服務器集群包括多個隊列服務器,所述方法包括:目標隊列服務器獲得第一客戶端發送的請求消息,所述目標隊列服務器是所述多個隊列服務器中的任意一個隊列服務器,將所述多個隊列服務器中的其他隊列服務器作為備份隊列服務器;所述目標隊列服務器將所述請求消息寫入目標日志文件,并觸發所述備份隊列服務器同步所述目標日志文件;所述備份隊列服務器將同步的所述請求消息推送至對應的備份消息隊列存儲,并向所述目標隊列服務器反饋備份完成信息;所述目標隊列服務器接收到第一預設數量的所述備份隊列服務器反饋的所述備份完成信息,將所述請求消息推送至目標消息隊列存儲,并向所述第一客戶端反饋針對所述請求消息的成功響應信息。

    【技術特征摘要】
    1.一種消息處理方法,其特征在于,應用于服務器集群,所述服務器集群包括多個隊列服務器,所述方法包括:目標隊列服務器獲得第一客戶端發送的請求消息,所述目標隊列服務器是所述多個隊列服務器中的任意一個隊列服務器,將所述多個隊列服務器中的其他隊列服務器作為備份隊列服務器;所述目標隊列服務器將所述請求消息寫入目標日志文件,并觸發所述備份隊列服務器同步所述目標日志文件;所述備份隊列服務器將同步的所述請求消息推送至對應的備份消息隊列存儲,并向所述目標隊列服務器反饋備份完成信息;所述目標隊列服務器接收到第一預設數量的所述備份隊列服務器反饋的所述備份完成信息,將所述請求消息推送至目標消息隊列存儲,并向所述第一客戶端反饋針對所述請求消息的成功響應信息。2.根據權利要求1所述的方法,其特征在于,所述方法還包括:檢測到所述目標隊列服務器工作異常,按照預設算法,重新選擇所述服務器集群的目標隊列服務器。3.根據權利要求2所述的方法,其特征在于,所述檢測到所述目標隊列服務器工作異常,按照預設算法,重新選擇所述服務器集群的目標隊列服務器,包括:所述備份隊列服務器判斷第一預設時間內是否接收到所述目標隊列服務器發送的續期信息;如果否,所述備份隊列服務器轉變為候選隊列服務器,并向所述服務器集群中的其他隊列服務器發送選舉請求;所述候選隊列服務器判斷接收到的針對所述選舉請求的響應信息數量是否達到第二預設數量;如果達到,所述候選隊列服務器轉變為新的目標隊列服務器,并向所述服務器集群中的其他隊列服務器發送所述續期信息;如果未達到,所述候選隊列服務器經第二預設時間向所述服務器集群中的其他隊列服務器再次發送所述選舉請求,直至接收到的所述響應信息數量達到所述第二預設數量,或者接收到新的目標隊列服務器發送的續期信息。4.根據權利要求1所述的方法,其特征在于,所述目標隊列服務器將所述請求消息寫入目標日志文件,包括:所述目標隊列服務器通過一致性算法將接收到的請求消息寫入目標日志文件。5.根據權利要求1所述的方法,其特征在于,所述方法還包括:所述目標隊列服務器檢測所述目標消息隊列存儲的請求消息的存儲時間是否達到預設閾值;基于檢測結果,刪除達到所述預設閾值的存儲時間對應的請求消息,并觸發所...

    【專利技術屬性】
    技術研發人員:張曉宇,周維躍,莊秋濤,謝家提,
    申請(專利權)人:騰訊科技深圳有限公司
    類型:發明
    國別省市:廣東,44

    網友詢問留言 已有0條評論
    • 還沒有人留言評論。發表了對其他瀏覽者有用的留言會獲得科技券。

    1
    主站蜘蛛池模板: 国产av无码专区亚洲av果冻传媒| 国产AV无码专区亚洲Av| 国产精品无码av天天爽| 精品爆乳一区二区三区无码av| 亚洲人成无码www久久久| 人妻AV中出无码内射| 中文无码人妻有码人妻中文字幕| 永久免费av无码网站大全| 中文字幕在线无码一区二区三区| 在线高清无码A.| av无码东京热亚洲男人的天堂| 丰满熟妇乱又伦在线无码视频| 精品三级AV无码一区| 国产综合无码一区二区色蜜蜜| 国产乱子伦精品无码码专区| 久久久久亚洲AV无码观看| 黄桃AV无码免费一区二区三区| 人妻丰满熟妇av无码区不卡| 亚洲?V无码成人精品区日韩| 色综合久久久久无码专区| 红桃AV一区二区三区在线无码AV| 色偷偷一区二区无码视频| 狠狠精品干练久久久无码中文字幕 | 亚洲的天堂av无码| 亚洲日韩激情无码一区| 国产精品亚洲а∨无码播放麻豆| 精品无码成人片一区二区98| 国产精品无码无片在线观看| 国精品无码一区二区三区左线| 蜜色欲多人AV久久无码| 自慰系列无码专区| 成人av片无码免费天天看| 无码专区永久免费AV网站| 无码人妻品一区二区三区精99| 亚洲av片不卡无码久久| 久久AV高潮AV无码AV| 人妻少妇精品无码专区动漫| 99久久人妻无码精品系列| 精品久久久久久无码专区不卡| 爆乳无码AV一区二区三区| 免费无码国产V片在线观看|