一種基于長連接的消息處理方法和消息處理裝置制造方法
【專利摘要】本發(fā)明提供一種基于長連接的消息處理方法和消息處理裝置，在基于長連接的消息處理中能夠?qū)崿F(xiàn)跨瀏覽器平臺處理，并且對客戶端的容量較大。該消息處理方法包括：對于服務(wù)器集群中的各個(gè)服務(wù)器，該服務(wù)器使用一個(gè)或多個(gè)線程管理與自身與客戶端的長連接，每個(gè)所述線程用于維持預(yù)設(shè)數(shù)目個(gè)所述長連接；所述服務(wù)器獲取來自于消息源的消息，然后將該消息提供給訂閱該消息的客戶端。
【專利說明】一種基于長連接的消息處理方法和消息處理裝置
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種基于長連接的消息處理方法和消息處理裝置。
【背景技術(shù)】
[0002]隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，各類應(yīng)用系統(tǒng)中往往需要頻繁地將消息發(fā)送到客戶端，例如在電子商務(wù)領(lǐng)域中，很多應(yīng)用譬如監(jiān)控、庫存變化、即時(shí)報(bào)價(jià)系統(tǒng)都需要將后臺發(fā)生的變化實(shí)時(shí)傳送到客戶端，傳統(tǒng)的一種模式是客戶發(fā)送輪訓(xùn)請求，不停的從服務(wù)器獲取數(shù)據(jù)，這種方式同時(shí)增加了客戶端與服務(wù)器的工作量，因此出現(xiàn)了長連接技術(shù)以改進(jìn)客戶端獲取消息的方式。長連接推送實(shí)現(xiàn)客戶端請求服務(wù)器，服務(wù)器一直保持此連接。服務(wù)器從消息源(mq或者其他消息來源)獲取消息，進(jìn)行分揀(過濾掉一些不重要的字段)，最后發(fā)送給指定的客戶端。相比傳統(tǒng)做法，無須客戶端不停地刷新、發(fā)送請求，這樣服務(wù)器的壓力就會變小，并且可以實(shí)時(shí)的獲取最新數(shù)據(jù)。再加上使用nio，并發(fā)連接數(shù)目很多的場景下對于降低服務(wù)器的資源負(fù)載非常有效。
[0003]目前關(guān)于長連接推送技術(shù)主要都是基于瀏覽器+ajax長輪詢實(shí)現(xiàn)的。一個(gè)比較成型的框架是Pushlet。但是隨著系統(tǒng)的不斷擴(kuò)張，終端數(shù)目的日益增加、終端所使用的瀏覽器的種類的不斷出新，Pushlet也暴露出以下不足之處:
[0004]Pushlet需要使用能工作在任何平臺、所有瀏覽器版本的DHTML庫。也就是說針對不同的瀏覽器，需要準(zhǔn)備不同的DHTML庫，存在對瀏覽器的依賴性；當(dāng)數(shù)目稍大(例如100個(gè)以上)的客戶端通過Pushlet連接到服務(wù)器時(shí)，服務(wù)器上的線程和套接字資源都將出現(xiàn)緊張，也就是說。Pushlet對客戶端的容量有限。

【發(fā)明內(nèi)容】

[0005]有鑒于此，本發(fā)明提供一種基于長連接的消息處理方法和消息處理裝置，在基于長連接的消息處理中能夠?qū)崿F(xiàn)跨瀏覽器平臺處理，并且對客戶端的容量較大。
[0006]為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的一個(gè)方面，提供了一種基于長連接的消息處理方法。
[0007]本發(fā)明的基于長連接的消息處理方法包括:對于服務(wù)器集群中的各個(gè)服務(wù)器，該服務(wù)器使用一個(gè)或多個(gè)線程管理與自身與客戶端的長連接，每個(gè)所述線程用于維持預(yù)設(shè)數(shù)目個(gè)所述長連接；所述服務(wù)器獲取來自于消息源的消息，然后將該消息提供給訂閱該消息的客戶端。
[0008]可選地，所述將該消息提供給訂閱該消息的客戶端的步驟包括:所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器連接，然后將該消息發(fā)送給該客戶端。
[0009]可選地，所述將該消息提供給訂閱該消息的客戶端的步驟包括:所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器集群中的另一服務(wù)器連接，然后將該消息發(fā)送給該另一服務(wù)器，以供該另一服務(wù)器將該消息發(fā)送給訂閱該消息的客戶端。
[0010]可選地，所述將該消息提供給訂閱該消息的客戶端的步驟之前，還包括:所述服務(wù)器根據(jù)所述客戶端的配置信息對該客戶端訂閱的消息進(jìn)行過濾。
[0011]可選地，所述將該消息提供給訂閱該消息的客戶端的步驟之后，還包括:所述服務(wù)器確認(rèn)該消息發(fā)送失敗，然后記錄發(fā)送失敗的時(shí)間；所述服務(wù)器確認(rèn)與該客戶端的長連接恢復(fù)，然后向該客戶端發(fā)送包含所述發(fā)送失敗的時(shí)間的丟包消息，以供所述客戶端根據(jù)所述丟包消息查詢所述發(fā)送失敗的消息。
[0012]根據(jù)本發(fā)明的另一方面，提供了一種基于長連接的消息處理裝置。
[0013]本發(fā)明的基于長連接的消息處理裝置設(shè)置在服務(wù)器集群中的各個(gè)服務(wù)器中，該消息處理裝置包括:長連接管理模塊，用于使用一個(gè)或多個(gè)線程管理所述服務(wù)器與客戶端的長連接，每個(gè)所述線程用于維持預(yù)設(shè)數(shù)目個(gè)所述長連接；獲取發(fā)送模塊，用于獲取來自于消息源的消息，然后將該消息提供給訂閱該消息的客戶端。
[0014]可選地，所述獲取發(fā)送模塊還用于:從所述服務(wù)器連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器連接，然后將該消息發(fā)送給該客戶端。
[0015]可選地，所述獲取發(fā)送模塊還用于:所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器集群中的另一服務(wù)器連接，然后將該消息發(fā)送給該另一服務(wù)器；以及，接收另一服務(wù)器發(fā)送的消息，然后將該消息發(fā)送給自身連接的訂閱該消息的客戶端。
[0016]可選地，所述獲取發(fā)送模塊還用于對獲取的所述客戶端訂閱的消息根據(jù)所述客戶端的配置信息對該客戶端訂閱的消息進(jìn)行過濾。
[0017]可選地，還包括失敗處理模塊，用于在所述獲取發(fā)送模塊將客戶端訂閱的消息發(fā)送給該客戶端之后，確認(rèn)該消息發(fā)送失敗，然后記錄發(fā)送失敗的時(shí)間，以及確認(rèn)與該客戶端的長連接恢復(fù)，然后向該客戶端發(fā)送包含所述發(fā)送失敗的時(shí)間的丟包消息，以供所述客戶端根據(jù)所述丟包消息查詢所述發(fā)送失敗的消息。
[0018]根據(jù)本發(fā)明的技術(shù)方案，采用服務(wù)器上運(yùn)行的程序的線程來維持服務(wù)器與客戶端的長連接，能夠使基于長連接的消息處理不依賴于具體的瀏覽器，實(shí)現(xiàn)了跨瀏覽器平臺處理，因?yàn)槊總€(gè)線程能夠維持?jǐn)?shù)量級為幾千的連接數(shù)，因此使服務(wù)器能夠與大量客戶端連接。
【專利附圖】

【附圖說明】
[0019]附圖用于更好地理解本發(fā)明，不構(gòu)成對本發(fā)明的不當(dāng)限定。其中:
[0020]圖1是根據(jù)本發(fā)明實(shí)施例的服務(wù)器、客戶端以及消息源的連接的示意圖；
[0021]圖2是根據(jù)本發(fā)明實(shí)施例的基于長連接的消息處理方法的一種流程的示意圖；
[0022]圖3是根據(jù)本發(fā)明實(shí)施例的基于長連接的消息處理裝置的基本結(jié)構(gòu)的示意圖。
【具體實(shí)施方式】
[0023]以下結(jié)合附圖對本發(fā)明的示范性實(shí)施例做出說明，其中包括本發(fā)明實(shí)施例的各種細(xì)節(jié)以助于理解，應(yīng)當(dāng)將它們認(rèn)為僅僅是示范性的。因此，本領(lǐng)域普通技術(shù)人員應(yīng)當(dāng)認(rèn)識至IJ，可以對這里描述的實(shí)施例做出各種改變和修改，而不會背離本發(fā)明的范圍和精神。同樣，為了清楚和簡明，以下的描述中省略了對公知功能和結(jié)構(gòu)的描述。[0024]圖1是根據(jù)本發(fā)明實(shí)施例的服務(wù)器、客戶端以及消息源的連接的示意圖。如圖1所示，服務(wù)器集群11中有多臺互相連接(圖中未示出連接關(guān)系)的服務(wù)器111、112、113、……、11N。其中各個(gè)服務(wù)器上連接有多個(gè)客戶端。為示意清晰起見，圖中僅示出連接在服務(wù)器111上的客戶端121和連接在服務(wù)器112上的客戶端122。實(shí)際上各個(gè)服務(wù)器可以連接有幾千個(gè)客戶端。圖1中還示出了多個(gè)消息源，同樣為了示意清晰起見，圖中僅示出連接在服務(wù)器111上的一個(gè)消息源131和連接在服務(wù)器112上的一個(gè)消息源132。在實(shí)際的系統(tǒng)中，各個(gè)服務(wù)器可能連接一個(gè)或多個(gè)消息源，也有可能不與任何消息源連接。
[0025]對于服務(wù)器集群中的各個(gè)服務(wù)器，該服務(wù)器使用一個(gè)或多個(gè)線程管理與自身與客戶端的長連接。服務(wù)器可以把多個(gè)長連接放入一個(gè)池中，并且一個(gè)線程管理、維持一個(gè)池的長連接。對于現(xiàn)有的處理能力的服務(wù)器來說，可以維護(hù)多個(gè)這樣的池，并且每個(gè)池可以容納幾千個(gè)長連接。另外，各個(gè)服務(wù)器在運(yùn)行時(shí)，獲取來自于消息源的客戶端訂閱的消息，然后將該消息發(fā)送給該客戶端。因?yàn)榉?wù)器采用服務(wù)器端的程序線程來實(shí)現(xiàn)長連接的維護(hù)，這種程序能夠獨(dú)立于瀏覽器，擔(dān)當(dāng)客戶端請求與服務(wù)器響應(yīng)的中間層，所以在基于長連接的消息處理中能夠?qū)崿F(xiàn)跨瀏覽 器平臺處理。并且這種程序的運(yùn)行效率主要取決于服務(wù)器硬件的處理能力，鑒于目前服務(wù)器硬件性能已相當(dāng)強(qiáng)大，因此運(yùn)行這種程序時(shí)對于對客戶端的容量較大，一般每個(gè)線程容納的長連接數(shù)目以千計(jì)。這種程序可以采用servlet程序。
[0026]以下結(jié)合圖2和圖3對本實(shí)施例中的消息處理方法做出說明。
[0027]圖2是根據(jù)本發(fā)明實(shí)施例的基于長連接的消息處理方法的基本流程的示意圖。
[0028]步驟S21:服務(wù)器111在消息源131處查詢是否有新消息。服務(wù)器111在運(yùn)行中，如果有需要向客戶端發(fā)送的消息，則通過自身與客戶端之間的長連接進(jìn)行發(fā)送，反之則定期地向客戶端發(fā)送心跳消息以維持該長連接。如果心跳消息發(fā)送失敗或者消息發(fā)送失敗，就確認(rèn)該長連接中斷。該中斷可能是由于客戶端故障或網(wǎng)絡(luò)異常導(dǎo)致。在沒有需要向客戶端發(fā)送消息的情況下，服務(wù)器111即從消息源處查詢是否有新消息。查詢結(jié)果為有或者沒有，從步驟S22起是有新消息的情況。如沒有新消息，則服務(wù)器111等待一個(gè)預(yù)設(shè)的周期時(shí)長之后返回本步驟再次查詢，如圖中所示。
[0029]步驟S22:服務(wù)器111拉取消息源131中的新消息。
[0030]步驟S23:服務(wù)器111對新消息進(jìn)行過濾。本步驟為可選步驟，用于客戶端的配置信息中有過濾需求的情況。例如客戶端要求不接收指定的字段，或者僅接收指定的字段。服務(wù)器111相應(yīng)地從新消息中刪除或提取客戶端指定的字段。各個(gè)服務(wù)器都能夠獲得連接在服務(wù)器集群11上的每個(gè)客戶端的配置信息，不論該客戶端是否直接連接在該服務(wù)器上。
[0031]步驟S24:服務(wù)器111將消息提供給客戶端。這里分兩種情況，一種情況是訂閱了服務(wù)器111所獲取的消息的客戶端與服務(wù)器111直接連接，例如客戶端121，這種情況下服務(wù)器111根據(jù)客戶端配置信息確認(rèn)獲取的消息是客戶端121所訂閱，于是將消息直接推送給客戶端121 ;另一種情況是訂閱了服務(wù)器111所獲取的消息的客戶端與另一服務(wù)器連接，例如是客戶端122訂閱了該消息，這種情況下服務(wù)器111根據(jù)客戶端配置信息確認(rèn)獲取的消息是連接在服務(wù)器112的客戶端122所訂閱，于是將該消息推送給服務(wù)器112，由服務(wù)器112將該消息推送給客戶端122。
[0032]至此，本次的向客戶端提供消息的流程結(jié)束，服務(wù)器111再次在消息源131處查詢是否有新消息，即返回步驟S21。[0033]如果服務(wù)器與客戶端之間的長連接中斷，則服務(wù)器向客戶端發(fā)送消息時(shí)會失敗。服務(wù)器確認(rèn)消息發(fā)送失敗后，丟棄要發(fā)送的消息，并且記錄消息發(fā)送失敗的時(shí)間。當(dāng)該長連接恢復(fù)并被服務(wù)器確認(rèn)后，服務(wù)器向該長連接的客戶端發(fā)送一個(gè)丟包消息，該丟包消息中有記錄的消息發(fā)送失敗的時(shí)間，這樣客戶端就可以根據(jù)該時(shí)間查詢曾經(jīng)丟失的消息?？蛻舳舜藭r(shí)需訪問一個(gè)網(wǎng)絡(luò)地址，該地址中包含消息源的消息。并且該網(wǎng)絡(luò)地址在客戶端進(jìn)行消息訂閱時(shí)已經(jīng)獲知。
[0034]圖3是根據(jù)本發(fā)明實(shí)施例的基于長連接的消息處理裝置的基本結(jié)構(gòu)的示意圖。以下結(jié)合圖3對本發(fā)明實(shí)施例中的基于長連接的消息處理裝置做出說明。該裝置可以設(shè)置在圖1中的各個(gè)服務(wù)器中。
[0035]如圖3所示，消息處理裝置30主要包括長連接管理模塊31和獲取發(fā)送模塊32。長連接管理模塊31用于使用一個(gè)或多個(gè)線程管理服務(wù)器與客戶端的長連接，每個(gè)線程用于維持預(yù)設(shè)數(shù)目個(gè)長連接；獲取發(fā)送模塊32用于獲取來自于消息源的客戶端訂閱的消息，然后將該消息發(fā)送給該客戶端。
[0036]獲取發(fā)送模塊32還可用于:從服務(wù)器連接的消息源獲取消息，對于獲取的各條消息，確定訂閱該消息的客戶端，然后將該消息發(fā)送給該客戶端。
[0037]獲取發(fā)送模塊32還可用于:從服務(wù)器集群中的另一服務(wù)器獲取消息，對于獲取的各條消息，確定訂閱該消息的客戶端，然后將該消息發(fā)送給該客戶端，其中該另一服務(wù)器連接有消息源，該客戶端訂閱有該消息源的消息。
[0038]獲取發(fā)送模塊32還可用于:對獲取的客戶端訂閱的消息根據(jù)客戶端的配置信息對該客戶端訂閱的消息進(jìn)行過濾。
[0039]消息處理裝置30還可以包含失敗處理模塊(圖中未示出)，用于在獲取發(fā)送模塊32將客戶端訂閱的消息發(fā)送給該客戶端之后，確認(rèn)該消息發(fā)送失敗，然后記錄發(fā)送失敗的時(shí)間，以及確認(rèn)與該客戶端的長連接恢復(fù)，然后向該客戶端發(fā)送包含發(fā)送失敗的時(shí)間的丟包消息，以供該客戶端根據(jù)該丟包消息查詢所述發(fā)送失敗的消息。
[0040]根據(jù)本發(fā)明實(shí)施例的技術(shù)方案，采用服務(wù)器上運(yùn)行的程序的線程來維持服務(wù)器與客戶端的長連接，能夠使基于長連接的消息處理不依賴于具體的瀏覽器，實(shí)現(xiàn)了跨瀏覽器平臺處理，因?yàn)槊總€(gè)線程能夠維持?jǐn)?shù)量級為幾千的連接數(shù)，因此使服務(wù)器能夠與大量客戶端連接。
[0041]以上結(jié)合具體實(shí)施例描述了本發(fā)明的基本原理，但是，需要指出的是，對本領(lǐng)域的普通技術(shù)人員而言，能夠理解本發(fā)明的方法和設(shè)備的全部或者任何步驟或者部件，可以在任何計(jì)算裝置(包括處理器、存儲介質(zhì)等)或者計(jì)算裝置的網(wǎng)絡(luò)中，以硬件、固件、軟件或者它們的組合加以實(shí)現(xiàn)，這是本領(lǐng)域普通技術(shù)人員在閱讀了本發(fā)明的說明的情況下運(yùn)用他們的基本編程技能就能實(shí)現(xiàn)的。
[0042]因此，本發(fā)明的目的還可以通過在任何計(jì)算裝置上運(yùn)行一個(gè)程序或者一組程序來實(shí)現(xiàn)。所述計(jì)算裝置可以是公知的通用裝置。因此，本發(fā)明的目的也可以僅僅通過提供包含實(shí)現(xiàn)所述方法或者裝置的程序代碼的程序產(chǎn)品來實(shí)現(xiàn)。也就是說，這樣的程序產(chǎn)品也構(gòu)成本發(fā)明，并且存儲有這樣的程序產(chǎn)品的存儲介質(zhì)也構(gòu)成本發(fā)明。顯然，所述存儲介質(zhì)可以是任何公知的存儲介質(zhì)或者將來開發(fā)出的任何存儲介質(zhì)。
[0043]還需要指出的是，在本發(fā)明的裝置和方法中，顯然，各部件或各步驟是可以分解和/或重新組合的。這些分解和/或重新組合應(yīng)視為本發(fā)明的等效方案。并且，執(zhí)行上述系列處理的步驟可以自然地按照說明的順序按時(shí)間順序執(zhí)行，但是并不需要一定按照時(shí)間順序執(zhí)行。某些步驟可以并行或彼此獨(dú)立地執(zhí)行。
[0044]上述【具體實(shí)施方式】，并不構(gòu)成對本發(fā)明保護(hù)范圍的限制。本領(lǐng)域技術(shù)人員應(yīng)該明白的是，取決于設(shè)計(jì)要求和其他因素，可以發(fā)生各種各樣的修改、組合、子組合和替代。任何在本發(fā)明的精神和原則之內(nèi)所作的修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明保護(hù)范圍之內(nèi)。
【權(quán)利要求】
1.一種基于長連接的消息處理方法，其特征在于，包括: 對于服務(wù)器集群中的各個(gè)服務(wù)器，該服務(wù)器使用一個(gè)或多個(gè)線程管理與自身與客戶端的長連接，每個(gè)所述線程用于維持預(yù)設(shè)數(shù)目個(gè)所述長連接； 所述服務(wù)器獲取來自于消息源的消息，然后將該消息提供給訂閱該消息的客戶端。
2.根據(jù)權(quán)利要求1所述的消息處理方法，其特征在于，所述將該消息提供給訂閱該消息的客戶端的步驟包括: 所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器連接，然后將該消息發(fā)送給該客戶端。
3.根據(jù)權(quán)利要求1所述的消息處理方法，其特征在于，所述將該消息提供給訂閱該消息的客戶端的步驟包括: 所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器集群中的另一服務(wù)器連接，然后將該消息發(fā)送給該另一服務(wù)器，以供該另一服務(wù)器將該消息發(fā)送給訂閱該消息的客戶端。
4.根據(jù)權(quán)利要求1，2或3所述的消息處理方法，其特征在于，所述將該消息提供給訂閱該消息的客戶端的步驟之前，還包括:所述服務(wù)器根據(jù)所述客戶端的配置信息對該客戶端訂閱的消息進(jìn)行過濾。
5.根據(jù)權(quán)利要求1，2或3所述的消息處理方法，其特征在于，所述將該消息提供給訂閱該消息的客戶端的步驟之后，還包括: 所述服務(wù)器確認(rèn)該消息發(fā)送失敗，然后記錄發(fā)送失敗的時(shí)間； 所述服務(wù)器確認(rèn)與該客戶端的長連接恢復(fù)，然后向該客戶端發(fā)送包含所述發(fā)送失敗的時(shí)間的丟包消息，以供所述客戶端根據(jù)所述丟包消息查詢所述發(fā)送失敗的消息。
6.一種基于長連接的消息處理裝置，設(shè)置在服務(wù)器集群中的各個(gè)服務(wù)器中，其特征在于，所述消息處理裝置包括: 長連接管理模塊，用于使用一個(gè)或多個(gè)線程管理所述服務(wù)器與客戶端的長連接，每個(gè)所述線程用于維持預(yù)設(shè)數(shù)目個(gè)所述長連接； 獲取發(fā)送模塊，用于獲取來自于消息源的消息，然后將該消息提供給訂閱該消息的客戶端。
7.根據(jù)權(quán)利要求6所述的消息處理裝置，其特征在于，所述獲取發(fā)送模塊還用于: 從所述服務(wù)器連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器連接，然后將該消息發(fā)送給該客戶端。
8.根據(jù)權(quán)利要求6所述的消息處理裝置，其特征在于，所述獲取發(fā)送模塊還用于: 所述服務(wù)器從自身連接的消息源獲取消息，確認(rèn)訂閱該消息的客戶端與所述服務(wù)器集群中的另一服務(wù)器連接，然后將該消息發(fā)送給該另一服務(wù)器；以及， 接收另一服務(wù)器發(fā)送的消息，然后將該消息發(fā)送給自身連接的訂閱該消息的客戶端。
9.根據(jù)權(quán)利要求6，7或8所述的消息處理裝置，其特征在于，所述獲取發(fā)送模塊還用于對獲取的所述客戶端訂閱的消息根據(jù)所述客戶端的配置信息對該客戶端訂閱的消息進(jìn)行過濾。
10.根據(jù)權(quán)利要求6，7或8所述的消息處理裝置，其特征在于，還包括失敗處理模塊，用于在所述獲取發(fā)送模塊將客戶端訂閱的消息發(fā)送給該客戶端之后，確認(rèn)該消息發(fā)送失敗，然后記錄發(fā)送失敗的時(shí)間，以及確認(rèn)與該客戶端的長連接恢復(fù)，然后向該客戶端發(fā)送包含所述發(fā)送 失敗的時(shí)間的丟包消息，以供所述客戶端根據(jù)所述丟包消息查詢所述發(fā)送失敗的消息。
【文檔編號】H04L29/08GK103457841SQ201310425410
【公開日】2013年12月18日 申請日期:2013年9月17日 優(yōu)先權(quán)日:2013年9月17日
【發(fā)明者】李睿 申請人:北京京東尚科信息技術(shù)有限公司