消息分發(fā)的方法、裝置及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種消息分發(fā)的方法、裝置及系統(tǒng)，涉及數(shù)字信息傳輸領(lǐng)域，為解決分發(fā)平臺側(cè)分發(fā)邏輯復(fù)雜的問題而發(fā)明。本發(fā)明的方法包括：消息分發(fā)器接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，APP消息中包含APP上線或APP更新的索引信息；將接收的APP消息進(jìn)行復(fù)制，并向每一個與消息分發(fā)器連接的消息隊列寫入一份APP消息，消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取APP消息，進(jìn)而根據(jù)索引信息確定APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。本發(fā)明主要應(yīng)用于分發(fā)APP上線或更新消息的過程中。
【專利說明】
消息分發(fā)的方法、裝置及系統(tǒng)
技術(shù)領(lǐng)域
[0001]本發(fā)明涉及數(shù)字信息傳輸領(lǐng)域，尤其涉及一種消息分發(fā)的方法、裝置及系統(tǒng)。
【背景技術(shù)】
[0002]隨著移動互聯(lián)網(wǎng)的發(fā)展以及智能移動設(shè)備的普及，越來越多的用戶習(xí)慣使用終端下載安裝應(yīng)用程序(Applicat1n，簡稱APP)，這些該終端包括但不僅限于:PC、手機(jī)、PAD、TV、車載設(shè)備以及可穿戴設(shè)備。用戶通過終端登錄應(yīng)用商店(APP Store)，選擇并下載需要的APP或APP更新包。
[0003]在網(wǎng)絡(luò)側(cè)，應(yīng)用商店是由以終端業(yè)務(wù)平臺為后端實現(xiàn)管理的，不同類型的應(yīng)用商店對應(yīng)不同的終端業(yè)務(wù)平臺。例如，手機(jī)業(yè)務(wù)平臺用于手機(jī)應(yīng)用商店的管理，TV業(yè)務(wù)平臺用于TV應(yīng)用商店的管理等。終端業(yè)務(wù)平臺接收分發(fā)平臺下發(fā)的APP消息，并根據(jù)接收的APP消息對應(yīng)用商店中的APP產(chǎn)品進(jìn)行上線、更新、下線等管理。
[0004]在分發(fā)平臺向終端業(yè)務(wù)平臺分發(fā)APP消息的過程中，現(xiàn)有的分發(fā)機(jī)制以同步分發(fā)為主，即分發(fā)平臺同時或順序向多個終端業(yè)務(wù)平臺發(fā)送APP消息。這種消息分發(fā)機(jī)制需要以終端業(yè)務(wù)平臺處于可用(available)狀態(tài)為前提，如果部分終端業(yè)務(wù)平臺因某些原因發(fā)生癱瘓，則需要消息重發(fā)、消息丟棄等機(jī)制對消息分發(fā)失敗予以補(bǔ)救，由此使得分發(fā)平臺側(cè)的分發(fā)邏輯復(fù)雜化。
[0005]例如，在基于HTTP協(xié)議的消息同步分發(fā)過程中，當(dāng)某個終端業(yè)務(wù)平臺無法接收APP消息時，分發(fā)平臺需要決定是否啟動消息重發(fā)機(jī)制；如果啟動消息重發(fā)機(jī)制，那么分發(fā)平臺還需要決定是向所有終端業(yè)務(wù)平臺全部重發(fā)APP消息，還是僅向消息接收失敗的終端業(yè)務(wù)平臺重發(fā)APP消息。對于后者方式，考慮到信息冪等性(idempotent)的問題，分發(fā)平臺還需要丟棄向已成功接收消息的終端業(yè)務(wù)平臺重發(fā)的消息，以避免APP消息的重復(fù)接收；同時，在進(jìn)行消息重發(fā)時，分發(fā)平臺的分發(fā)邏輯還進(jìn)一步涉及到重發(fā)時機(jī)、重發(fā)次數(shù)等具體策略。由此可以看出，現(xiàn)有的同步分發(fā)機(jī)制需要一套復(fù)雜的分發(fā)邏輯來保證APP消息的正常分發(fā)，不利于分發(fā)平臺的輕量化實現(xiàn)。

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

[0006]本發(fā)明提供了一種消息分發(fā)的方法、裝置及系統(tǒng)，能夠解決分發(fā)平臺側(cè)分發(fā)邏輯復(fù)雜的問題。
[0007]為解決上述技術(shù)問題，本發(fā)明提供如下的技術(shù)方案:
[0008]第一方面，本發(fā)明提供一種消息分發(fā)的方法，包括:
[0009]消息分發(fā)器接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，所述APP消息中包含APP上線或APP更新的索引信息；
[0010]將接收的所述APP消息進(jìn)行復(fù)制，并向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與所述消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取所述APP消息，進(jìn)而根據(jù)所述索引信息確定所述APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。
[0011]第二方面，本發(fā)明還提供一種消息分發(fā)的方法，包括:
[0012]終端業(yè)務(wù)平臺監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與所述終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；所述APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與所述消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息；
[0013]若監(jiān)聽到其連接的消息隊列中寫入APP消息，則從所述消息隊列中將所述APP消息讀出，并根據(jù)所述索引信息確定所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息；
[0014]若確定為所述終端業(yè)務(wù)平臺自身所需的APP消息，則按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP。
[0015]第三方面，本發(fā)明還提供一種消息分發(fā)器，包括:
[0016]接收單元，用于接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，所述APP消息中包含APP上線或APP更新的索引信息；
[0017]復(fù)制單元，用于將所述接收單元接收的所述APP消息進(jìn)行復(fù)制；
[0018]寫入單元，用于向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述復(fù)制單元復(fù)制的所述APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與所述消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取所述APP消息，進(jìn)而根據(jù)所述索引信息確定所述APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。
[0019]第四方面，本發(fā)明還提供一種終端業(yè)務(wù)平臺，包括:
[0020]監(jiān)聽單元，用于監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與所述終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；所述APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與所述消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息；
[0021]讀取單元，用于當(dāng)所述監(jiān)聽單元監(jiān)聽到其連接的消息隊列中寫入APP消息時，從所述消息隊列中將所述APP消息讀出；
[0022]確定單元，用于根據(jù)所述索引信息確定所述讀取單元讀取的所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息；
[0023]處理單元，用于當(dāng)所述確定單元確定為所述終端業(yè)務(wù)平臺自身所需的APP消息時，按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP。
[0024]第五方面，本發(fā)明還提供一種消息分發(fā)系統(tǒng)，包括:消息提供平臺、如上所述的消息分發(fā)器、消息隊列和如上所述的終端業(yè)務(wù)平臺；
[0025]所述消息提供平臺，用于產(chǎn)生APP消息，并將所述APP消息發(fā)送給所述消息分發(fā)器;
[0026]每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識。
[0027]借由上述技術(shù)方案，本發(fā)明提供的消息分發(fā)的方法、裝置及系統(tǒng)，為終端業(yè)務(wù)平臺建立對應(yīng)的消息隊列，當(dāng)消息提供平臺需要發(fā)送APP消息時，直接由消息分發(fā)器向每一個消息隊列發(fā)送一份相同的APP消息，該種向消息隊列發(fā)送APP消息的方式屬于無區(qū)分發(fā)送，只要消息隊列與消息分發(fā)器連接，APP消息就會發(fā)送到連接的消息隊列中，該種消息分發(fā)的方式無需關(guān)心分發(fā)對象、分發(fā)方式等具體策略，簡單易操作，避免了消息提供平臺發(fā)送APP消息的復(fù)雜邏輯。
[0028]并且，基于消息隊列具有消息持久化保存的特性，APP消息發(fā)送到消息隊列中之后會暫存在各個消息隊列中，各終端業(yè)務(wù)平臺會監(jiān)聽與其對應(yīng)的消息隊列，當(dāng)監(jiān)聽到消息隊列中有APP消息時，才將APP消息從消息隊列中取出，并且當(dāng)對該APP消息進(jìn)行實際處理后才從該消息隊列中刪除；所以當(dāng)APP消息發(fā)出但是對應(yīng)的終端業(yè)務(wù)平臺不正常工作無法成功接收APP消息時，無需部署消息重發(fā)、消息丟棄等復(fù)雜的策略。
[0029]另外，各終端業(yè)務(wù)平臺在監(jiān)聽到各自對應(yīng)的消息隊列中有APP消息時，會對APP消息進(jìn)行一個識別，只對所述終端業(yè)務(wù)平臺所需的APP消息進(jìn)行處理，這樣對APP消息的識別和分類放在終端業(yè)務(wù)平臺進(jìn)行，在一定程度上降低了消息提供平臺分發(fā)消息的邏輯。
【附圖說明】
[0030]通過閱讀下文優(yōu)選實施方式的詳細(xì)描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認(rèn)為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中:
[0031]圖1示出了本發(fā)明實施例提供的一種消息分發(fā)器側(cè)消息分發(fā)的方法流程圖；
[0032]圖2示出了本發(fā)明實施例提供的一種終端業(yè)務(wù)平臺側(cè)消息分發(fā)的方法流程圖；
[0033]圖3示出了本發(fā)明實施例提供的一種消息分發(fā)的方法流程圖；
[0034]圖4示出了本發(fā)明實施例提供的另一種消息分發(fā)的方法流程圖；
[0035]圖5示出了本發(fā)明實施例提供的一種消息分發(fā)的場景示意圖；
[0036]圖6示出了本發(fā)明實施例提供的一種消息隊列與終端業(yè)務(wù)平臺對接的示意圖；
[0037]圖7示出了本發(fā)明實施例提供的一種APP消息內(nèi)容的示意圖；
[0038]圖8示出了本發(fā)明實施例提供的一種消息分發(fā)器的組成框圖；
[0039]圖9示出了本發(fā)明實施例提供的另一種消息分發(fā)器的組成框圖；
[0040]圖10示出了本發(fā)明實施例提供的一種終端業(yè)務(wù)平臺的組成框圖；
[0041]圖11示出了本發(fā)明實施例提供的另一種終端業(yè)務(wù)平臺的組成框圖；
[0042]圖12示出了本發(fā)明實施例提供的一種消息分發(fā)系統(tǒng)的組成框圖。
【具體實施方式】
[0043]下面將參照附圖更詳細(xì)地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應(yīng)當(dāng)理解，可以以各種形式實現(xiàn)本公開而不應(yīng)被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。
[0044]為了解決分發(fā)平臺側(cè)分發(fā)邏輯復(fù)雜的問題，本發(fā)明實施例提供了一種消息分發(fā)的方法，通過消息隊列的建立和使用實現(xiàn)APP消息的異步分發(fā)。該消息分發(fā)的方法所基于的消息分發(fā)系統(tǒng)涉及以下幾個組成部分:消息提供平臺、消息分發(fā)器、消息隊列和終端業(yè)務(wù)平臺。其中消息提供平臺為APP消息產(chǎn)生方，消息分發(fā)器為APP消息分發(fā)方，消息隊列為連接消息分發(fā)器和終端業(yè)務(wù)平臺的數(shù)據(jù)通道，終端業(yè)務(wù)平臺為APP消息接收方。
[0045]在執(zhí)行本發(fā)明實施例之前，需要為各個終端業(yè)務(wù)平臺建立對應(yīng)的消息隊列。一般情況下，可以創(chuàng)建與終端業(yè)務(wù)平臺數(shù)量相等的消息隊列，一個消息隊列對應(yīng)一個終端業(yè)務(wù)平臺進(jìn)行消息分發(fā)，當(dāng)出于消息隊列冗余備份的考慮時，可以創(chuàng)建多于終端業(yè)務(wù)平臺數(shù)量的消息隊列，而當(dāng)出于提高消息隊列使用率的考慮時，也可以創(chuàng)建少于終端業(yè)務(wù)平臺數(shù)量的消息隊列；在創(chuàng)建好消息隊列之后，會為每一個消息隊列分配一個唯一標(biāo)識用于區(qū)分于其他消息隊列，該唯一標(biāo)識可以為但不局限于key值。
[0046]當(dāng)為終端業(yè)務(wù)平臺創(chuàng)建好消息隊列后，需要將終端業(yè)務(wù)平臺對應(yīng)的消息隊列與消息分發(fā)器綁定，以便消息分發(fā)器向消息隊列發(fā)送APP消息。在將創(chuàng)建好的消息隊列與消息分發(fā)器綁定之后，就建立了一個消息分發(fā)器對應(yīng)多個消息隊列的對應(yīng)關(guān)系，每一個消息隊列一端連接消息分發(fā)器，另一端連接各自對應(yīng)的終端業(yè)務(wù)平臺。
[0047]基于上述消息分發(fā)系統(tǒng)的布局，本發(fā)明實施例以下將具體說明消息分發(fā)的相關(guān)內(nèi)容。
[0048]本發(fā)明實施例提供一種消息分發(fā)的方法，該方法為消息分發(fā)器側(cè)的方法，如圖1所示，該方法包括:
[0049]101、消息分發(fā)器(exchanger)接收消息提供平臺發(fā)送的APP消息，所述APP消息中包含APP上線或APP更新的索引信息。
[0050]需要說明的是，本實施例中消息提供平臺(producer)發(fā)送的APP消息是APP上線或更新的索引信息，并非是APP安裝包或APP更新包本身。該索引信息可以是一種結(jié)構(gòu)化的索引信息，本發(fā)明實施例不對索引信息的信息結(jié)構(gòu)進(jìn)行限制，例如可以為但不局限于json數(shù)據(jù)格式。
[0051]所述索引信息包括但不局限于APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息，其中，該APP標(biāo)識信息唯一的標(biāo)示了該APP，用于終端業(yè)務(wù)平臺識別是哪一個APP，其可以是APP的包名或者ID，具體的本發(fā)明實施例對此不進(jìn)行限制，只要唯一的標(biāo)識該APP區(qū)別于其他APP即可。其中，該終端業(yè)務(wù)平臺標(biāo)識信息唯一的標(biāo)示了該終端業(yè)務(wù)平臺，以便接收到該APP消息的終端業(yè)務(wù)平臺對該APP消息進(jìn)行識別，確定其是否為該終端業(yè)務(wù)平臺所需的APP消息，其可以是終端業(yè)務(wù)平臺的名稱，該名稱可以為中文名稱或者英文名稱，也可以為ID，具體的本發(fā)明實施例對此也不進(jìn)行限定。
[0052]所述索引信息除了上述APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息外，還可以包括APP的操作類型，APP的版本號等，具體的本發(fā)明實施例對此也不進(jìn)行限制。
[0053]102、消息分發(fā)器將接收的所述APP消息進(jìn)行復(fù)制，并向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與所述消息分發(fā)器連接；每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取所述APP消息，進(jìn)而根據(jù)所述索引信息確定所述APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。
[0054]其中，終端業(yè)務(wù)平臺不限于包括手機(jī)應(yīng)用商店平臺、TV應(yīng)用商店平臺、游戲中心平臺、智能設(shè)備應(yīng)用商店平臺及車聯(lián)網(wǎng)應(yīng)用商店平臺等，與此同時，該終端業(yè)務(wù)平臺還可以包括第三方開發(fā)者開放平臺、應(yīng)用搜索引擎及客戶端。為便于表述，本發(fā)明后續(xù)實施例將包括開發(fā)者開放平臺等在內(nèi)的消息接收方統(tǒng)稱為終端業(yè)務(wù)平臺。此外，隨著業(yè)務(wù)國際化趨勢的發(fā)展，為防止本地終端業(yè)務(wù)平臺與海外終端之間的洲際網(wǎng)絡(luò)延時，越來越多的終端業(yè)務(wù)平臺被部署在海外當(dāng)?shù)?。本實施例中APP消息的接收方還包括了部署在海外的不同語言版本的終端業(yè)務(wù)平臺。
[0055]該消息隊列為終端業(yè)務(wù)平臺創(chuàng)建的用于暫存APP消息的隊列。本步驟中，消息分發(fā)器可以通過但不局限于方法調(diào)用的方式建立多個消息隊列，并將消息提供平臺推送的APP消息分別寫入到這多個消息隊列中。消息分發(fā)器在建立多個消息隊列時，可以建立與終端業(yè)務(wù)平臺數(shù)量相等的消息隊列，一個終端業(yè)務(wù)平臺對應(yīng)一個消息隊列。其中，當(dāng)一個終端業(yè)務(wù)平臺對應(yīng)一個消息隊列時，當(dāng)終端業(yè)務(wù)平臺數(shù)量發(fā)生增減時，消息分發(fā)器建立或釋放對應(yīng)增減終端業(yè)務(wù)平臺的消息隊列?；蛘哌M(jìn)一步的，為減少建立/釋放消息隊列產(chǎn)生的資源開銷，對于終端業(yè)務(wù)平臺數(shù)量減少的情況，消息分發(fā)器也可以暫時維護(hù)與其對應(yīng)的消息隊列，當(dāng)增加新的終端業(yè)務(wù)平臺時，將待用的消息隊列分配給新增加的終端業(yè)務(wù)平臺。
[0056]需要說明的是，本實施例中所述的“一個終端業(yè)務(wù)平臺對應(yīng)一個消息隊列”并非是“終端業(yè)務(wù)平臺數(shù)量與消息隊列數(shù)量相等”的充要條件。正如前面所述，消息隊列的數(shù)量可以多于、少于或等于終端業(yè)務(wù)平臺的數(shù)量。當(dāng)消息隊列數(shù)量多于終端業(yè)務(wù)平臺數(shù)量時，多出的消息隊列并不與任何終端業(yè)務(wù)平臺連接，也不會參與APP消息的分發(fā)，僅作備份之用；而當(dāng)消息隊列數(shù)量少于終端業(yè)務(wù)平臺數(shù)量時，多出的終端業(yè)務(wù)平臺可以等待其他終端業(yè)務(wù)平臺接收到APP消息后，通過其他終端業(yè)務(wù)平臺使用過的消息隊列進(jìn)行消息接收，此時僅需改變消息隊列與終端業(yè)務(wù)平臺的綁定連接關(guān)系即可，這種情況下同一個消息隊列可以先后與不同的終端業(yè)務(wù)平臺進(jìn)行綁定連接及消息發(fā)送。但是無論兩者數(shù)量關(guān)系如何，在進(jìn)行消息接收時，從終端業(yè)務(wù)平臺的角度上看，接收APP消息的終端業(yè)務(wù)平臺都會有一個消息隊列對應(yīng)，但是這并不代表在同一時刻上所有終端業(yè)務(wù)平臺都對應(yīng)有消息隊列，也不代表所有的消息隊列全部實現(xiàn)了與終端業(yè)務(wù)平臺的綁定連接。
[0057]本實施例中，消息提供平臺針對不同終端業(yè)務(wù)平臺對APP所需的不同，會向不同終端業(yè)務(wù)平臺發(fā)送不同的APP消息，消息提供平臺在產(chǎn)生APP消息時，會將該APP消息對應(yīng)的終端業(yè)務(wù)平臺標(biāo)識和APP標(biāo)識添加在APP消息中，以便接收方能夠識別。消息分發(fā)器接收到消息提供平臺發(fā)出的APP消息時，不對該APP消息進(jìn)行識別確定是哪個終端業(yè)務(wù)平臺的APP消息，而是根據(jù)與其連接的消息隊列的數(shù)量，將該APP消息進(jìn)行復(fù)制得到與消息隊列相同數(shù)量的APP消息，并將該復(fù)制得到的APP消息分別寫入到各個消息隊列中。
[0058]示例性的，4個終端業(yè)務(wù)平臺A、B、C、D分別對應(yīng)消息隊列a，b，c，d ;假設(shè)消息提供平臺需要向終端業(yè)務(wù)平臺A發(fā)送APP消息I和APP消息2，向終端業(yè)務(wù)平臺B發(fā)送APP消息3。那么消息分發(fā)器會將APP消息1、2及3分別復(fù)制4分，然后均寫入到消息隊列a，b，c，d中，使得消息隊列a，b，c，d中分別存有APP消息1、2及3。
[0059]本發(fā)明實施例還提供一種消息分發(fā)的方法，該方法為終端業(yè)務(wù)平臺側(cè)的方法，如圖2所示，該方法包括:
[0060]201、終端業(yè)務(wù)平臺監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與所述終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；所述APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與所述消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息。
[0061]基于消息提供平臺將面向所有終端業(yè)務(wù)平臺的APP消息全部推送到消息分發(fā)器中，消息分發(fā)器會將所有APP消息無區(qū)分的寫入與消息分發(fā)器連接的全部消息隊列中。各終端業(yè)務(wù)平臺對各自對應(yīng)的消息隊列進(jìn)行監(jiān)聽，當(dāng)監(jiān)聽到消息隊列中出現(xiàn)新消息時，進(jìn)而執(zhí)行步驟202-204的操作。
[0062]202、若監(jiān)聽到其連接的消息隊列中寫入APP消息，則從所述消息隊列中將所述APP消息讀出，并根據(jù)所述索引信息確定所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息；若確定為所述終端業(yè)務(wù)平臺自身所需的APP消息，則執(zhí)行203 ;若確定不為所述終端業(yè)務(wù)平臺自身所需的APP消息，則執(zhí)行204。
[0063]其中，如步驟101中相關(guān)內(nèi)容所述，消息提供平臺發(fā)送APP消息時會將與該APP消息對應(yīng)的終端業(yè)務(wù)平臺標(biāo)識和APP標(biāo)識封裝在該APP消息中，以便APP消息接收方識別。本發(fā)明實施例此處在監(jiān)聽到終端業(yè)務(wù)平臺對應(yīng)的消息隊列中寫入APP消息時，從所述消息隊列中將所述APP消息讀出，對所述APP消息進(jìn)行解析，獲取所述APP消息中包含的索引信息，所述索引信息中包含APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息；將獲取的終端業(yè)務(wù)平臺標(biāo)識信息與所述終端業(yè)務(wù)平臺自身的標(biāo)識信息進(jìn)行對比；若兩者一致，則確定所述APP消息為所述終端業(yè)務(wù)平臺自身所需的APP消息；若兩者不一致，則確定所述APP消息不為所述終端業(yè)務(wù)平臺自身所需的APP消息。
[0064]在圖1所示示例中，終端業(yè)務(wù)平臺A至D都會接收到APP消息I至3，對于終端業(yè)務(wù)平臺A而言，其分別從APP消息I和2中解析出終端業(yè)務(wù)平臺A的終端業(yè)務(wù)平臺標(biāo)識，則終端業(yè)務(wù)平臺A將APP消息I和2確定為自身所需的APP消息，而由于APP消息3中解析出的終端業(yè)務(wù)平臺標(biāo)識為終端業(yè)務(wù)平臺B的標(biāo)識，因此終端業(yè)務(wù)平臺A確定APP消息3不為自身所需的APP消息。同理，終端業(yè)務(wù)平臺僅將APP消息3確定為自身所需的APP消息，而終端業(yè)務(wù)平臺C和D分別將APP消息I至3全部確定為自身不需要的APP消息。
[0065]203、按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP。
[0066]其中，當(dāng)APP消息中包含終端業(yè)務(wù)平臺的標(biāo)識信息和APP的標(biāo)識信息時，按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP具體為:按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP，按照所述終端業(yè)務(wù)平臺預(yù)定處理流程請求獲取所述APP標(biāo)識信息對應(yīng)的APP安卓程序包APK信息；根據(jù)所述APK信息，對所述APP標(biāo)識信息對應(yīng)的APP進(jìn)行上線或者更新。
[0067]在圖1所示實施例中，消息提供平臺和消息分發(fā)器分別扮演了消息生產(chǎn)者和消息分發(fā)者的角色(即前述步驟101中提到的producer和exchanger)，在本步驟中，當(dāng)終端業(yè)務(wù)平臺根據(jù)所述APK信息，對所述APP標(biāo)識信息對應(yīng)的APP進(jìn)行上線或者更新時，終端業(yè)務(wù)平臺扮演了消息消費者(consumer)的角色。
[0068]204、將所述APP消息丟掉。
[0069]本實施例中，為每一個終端業(yè)務(wù)平臺建立一個對應(yīng)的消息隊列，當(dāng)消息提供平臺需要發(fā)送APP消息時，直接由消息分發(fā)器向每一個終端業(yè)務(wù)平臺對應(yīng)的消息隊列發(fā)送一份相同的APP消息，該種向消息隊列發(fā)送APP消息的方式屬于無區(qū)分的發(fā)送，只要消息隊列與消息分發(fā)器連接，APP消息就會發(fā)送到連接的消息隊列中，該種消息分發(fā)的方式無需關(guān)心分發(fā)對象、分發(fā)方式等具體策略，簡單易操作，避免了消息提供平臺發(fā)送APP消息的復(fù)雜邏輯。
[0070]并且，基于消息隊列具有消息持久化保存的特性，APP消息發(fā)送到消息隊列中之后會暫存在各個消息隊列中，各終端業(yè)務(wù)平臺會監(jiān)聽與其對應(yīng)的消息隊列，當(dāng)監(jiān)聽到消息隊列中有APP消息時，才將APP消息從消息隊列中取出；所以當(dāng)APP消息發(fā)出但是對應(yīng)的終端業(yè)務(wù)平臺不正常工作無法成功接收APP消息時，無需部署消息重發(fā)、消息丟棄等復(fù)雜的策略。另外，各終端業(yè)務(wù)平臺在監(jiān)聽到各自對應(yīng)的消息隊列中有APP消息時，會對APP消息進(jìn)行一個識別，只對所述終端業(yè)務(wù)平臺所需的APP消息進(jìn)行處理，這樣對APP消息的識別和分類放在終端業(yè)務(wù)平臺進(jìn)行，在一定程度上降低了消息提供平臺分發(fā)消息的邏輯。綜上，與現(xiàn)有技術(shù)中的同步分發(fā)機(jī)制相比，本發(fā)明能夠大大簡化分發(fā)平臺側(cè)的分發(fā)邏輯，實現(xiàn)分發(fā)平臺的輕量化設(shè)計。
[0071]本實施例中，APP消息發(fā)送給各終端業(yè)務(wù)平臺對應(yīng)的消息隊列后，各終端業(yè)務(wù)平臺從各自對應(yīng)的消息隊列中接收APP消息的過程是相互獨立的，終端業(yè)務(wù)平臺可以根據(jù)自身的實際情況靈活確定消息接收的時間，各終端業(yè)務(wù)平臺無需同時開始或結(jié)束APP消息的接收。同時，由于終端業(yè)務(wù)平臺是基于各自的消息隊列接收APP消息的，因此當(dāng)某個或某幾個終端業(yè)務(wù)平臺處于不可用狀態(tài)時，也不會影響其他終端業(yè)務(wù)平臺對APP消息的正常接收。本質(zhì)上，消息接收的獨立性和抗干擾性有了很大提升。
[0072]此外，本方法還具有以下幾點優(yōu)勢:
[0073]1、異步特性:現(xiàn)有技術(shù)中分發(fā)平臺采用同步機(jī)制分發(fā)APP消息，同步分發(fā)機(jī)制可以有兩種具體的實現(xiàn)方式，第一，建立多線程同時向多個終端業(yè)務(wù)平臺發(fā)送消息；第二，依次向各個終端業(yè)務(wù)平臺順序發(fā)送消息。當(dāng)系統(tǒng)中的終端業(yè)務(wù)平臺數(shù)量增加時，對于前者方式，需要增加分發(fā)平臺的并發(fā)數(shù)資源開銷，對于后者方式，則會延長消息分發(fā)的時間。而在本方法中，通過簡單的方法調(diào)用即可實現(xiàn)消息隊列的建立，并且多個消息隊列的消息分發(fā)并行進(jìn)行，無論終端業(yè)務(wù)平臺的數(shù)量如何增加，消息提供平臺僅需要傳遞一次APP消息即可，相對現(xiàn)有技術(shù)而言，能夠大大降低并發(fā)數(shù)資源開銷并縮短分發(fā)耗時。
[0074]2、靈活性:現(xiàn)有技術(shù)中，如果增減終端業(yè)務(wù)平臺的數(shù)量，則需要改動分發(fā)平臺側(cè)的分發(fā)邏輯，實現(xiàn)起來復(fù)雜耗時，消息分發(fā)具有一定的滯后性。而在本發(fā)明中，僅通過簡單的方法調(diào)用就可以實現(xiàn)消息隊列的建立和釋放，相對現(xiàn)有技術(shù)而言，本方法能夠靈活便捷的增減終端業(yè)務(wù)平臺的數(shù)量，保障APP消息的及時分發(fā)。
[0075]進(jìn)一步的，本發(fā)明另一實施例還提供了一種消息分發(fā)的方法。該方法以消息分發(fā)器建立與終端業(yè)務(wù)平臺相同數(shù)量的消息隊列為基礎(chǔ)，如圖3所示，該方法包括:
[0076]301、消息提供平臺接收APP或APP更新包。
[0077]消息提供平臺接收開發(fā)者平臺上報的新APP或APP更新包。本實施例中所述的開發(fā)者平臺包括內(nèi)容提供商內(nèi)部的開發(fā)者平臺，也包括第三方開發(fā)者的開放平臺。并且，本步驟中接收的APP或APP更新包還可以是通過計算機(jī)程序工具在網(wǎng)頁頁面或第三方應(yīng)用商店中獲取的APP。例如，通過APP爬蟲工具抓取的APP或APP更新包。本實施例不對APP或APP更新包的來源不進(jìn)行限制。
[0078]302、消息提供平臺后端對接收的APP或APP更新包進(jìn)行審核。
[0079]消息提供平臺可以在后端通過機(jī)器模型對APP或APP更新包進(jìn)行自動審核，也可以通過平臺前端的人機(jī)交互界面向運維人員提供人工審核的功能，再或者將自動審核和人工審核機(jī)制結(jié)合使用，本實施例對此不作限制。
[0080]除此之外，消息提供平臺也可以將APP審核的任務(wù)分割出去，由獨立于消息提供平臺的其他平臺進(jìn)行審核，消息提供平臺僅接收審核結(jié)果即可。
[0081]303、消息分發(fā)器建立與終端業(yè)務(wù)平臺同等數(shù)量的消息隊列。
[0082]304、消息分發(fā)器建立終端業(yè)務(wù)平臺與消息隊列之間一一對應(yīng)的綁定連接。
[0083]每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識。本實施例中，消息分發(fā)器可以將預(yù)先為終端業(yè)務(wù)平臺分配的key值與消息隊列進(jìn)行綁定，由此實現(xiàn)終端業(yè)務(wù)平臺與消息隊列的綁定連接。
[0084]在進(jìn)行消息分發(fā)之前，消息分發(fā)器需要為終端業(yè)務(wù)平臺分配具有唯一標(biāo)識作用的key值，該key值用于對對應(yīng)終端業(yè)務(wù)平臺的消息隊列進(jìn)行唯一標(biāo)識。實際應(yīng)用中，key值可以為一串長度不限的字符串，其具體形式可以是終端業(yè)務(wù)平臺的名稱或平臺標(biāo)識，或者僅為純數(shù)字形式的代碼，本實施例不對key值的具體形式進(jìn)行限定。
[0085]實際應(yīng)用中，消息分發(fā)器可以在后端維護(hù)一個key值列表，當(dāng)終端業(yè)務(wù)平臺的數(shù)量發(fā)生增減時，消息分發(fā)器可以對該列表進(jìn)行增刪改查等更新操作。
[0086]本實施例中，消息分發(fā)器通過方法調(diào)用的方式建立多個消息隊列，并為不同的消息隊列綁定不同的key值，從而建立key值、終端業(yè)務(wù)平臺及消息隊列三者之間一一對應(yīng)的映射關(guān)系。
[0087]在本實施例的一種實現(xiàn)方式中，消息分發(fā)器可以調(diào)用ftok函數(shù)獲取與消息分發(fā)相關(guān)的進(jìn)程間通信(Inter-Process Communicat1n，簡稱IPC)鍵值，然后建立一個與IPC鍵值相對唯一的key值，該key值即為對應(yīng)終端業(yè)務(wù)平臺的key值。之后，消息分發(fā)器調(diào)用msgget函數(shù)，通過key值創(chuàng)建消息隊列，完成消息隊列的建立和key值的綁定。
[0088]本實施例中，消息分發(fā)器建立綁定連接的時機(jī)有兩種。其一，在分發(fā)平臺初始化時建立終端業(yè)務(wù)平臺與消息隊列的綁定連接；其二，當(dāng)添加新的終端業(yè)務(wù)平臺時，為新增的終端業(yè)務(wù)平臺建立與消息隊列的綁定連接關(guān)系。
[0089]需要說明的是，實際應(yīng)用中也可以先執(zhí)行步驟303至步驟304建立消息隊列，然后再執(zhí)行步驟301至步驟302對APP進(jìn)行審核，或者同時執(zhí)行步驟301至步驟302以及步驟303至步驟304。圖3所示流程順序僅為本實施例的一種實現(xiàn)方式，實際應(yīng)用中，只要保證步驟301至步驟302在步驟305之前執(zhí)行完畢即可。
[0090]305、在APP上線或APP更新審核通過后，消息提供平臺生成APP消息，并向消息分發(fā)器推送APP消息，由消息分發(fā)器將APP消息進(jìn)行復(fù)制，并分別寫入到與消息分發(fā)器連接的各個消息隊列中。
[0091]由于分發(fā)過程涉及多個終端業(yè)務(wù)平臺和多個消息隊列，并且每個消息隊列中分發(fā)的APP消息是一樣的，即一個APP消息需要分發(fā)給所有的消息隊列。因此本步驟需要對待分發(fā)的APP消息進(jìn)行“復(fù)制”，獲得多份相同的APP消息。在一種實現(xiàn)方式中，消息“復(fù)制”的工作由消息分發(fā)器完成，消息提供平臺向消息分發(fā)器發(fā)送一次APP消息，消息分發(fā)器通過扇出(fanout)技術(shù)將消息提供平臺發(fā)送的APP消息“復(fù)制”為多份相同的APP消息，扇出的APP消息份數(shù)與消息隊列的數(shù)量相同，然后消息分發(fā)器調(diào)用msgsnd函數(shù)，向每個消息隊列分別寫入一份APP消息。
[0092]306、終端業(yè)務(wù)平臺對對應(yīng)的消息隊列進(jìn)行監(jiān)聽。
[0093]如前所述，各終端業(yè)務(wù)平臺接收到的APP消息完全相同，均包含發(fā)送給各個終端業(yè)務(wù)平臺的所有APP消息。各個終端業(yè)務(wù)平臺對各自對應(yīng)的消息隊列進(jìn)行監(jiān)聽。當(dāng)消息隊列中寫入新的APP消息時，終端業(yè)務(wù)平臺對該APP消息進(jìn)行接收和解析，從該APP消息中獲取用于標(biāo)記該條消息的標(biāo)識，并根據(jù)該標(biāo)識判斷該條APP消息是否為其所需的APP消息。若該APP消息為其所需的APP消息，則終端業(yè)務(wù)平臺執(zhí)行步驟307及步驟308，按照該終端業(yè)務(wù)平臺處理APP消息的處理邏輯對該APP消息進(jìn)行處理；若該APP消息不為其所需的APP消息，則終端業(yè)務(wù)平臺對該APP消息進(jìn)行丟棄。
[0094]在本實施例的一種實現(xiàn)方式中，上述標(biāo)識可以為終端業(yè)務(wù)平臺的平臺標(biāo)識，該平臺標(biāo)識能夠?qū)K端業(yè)務(wù)平臺進(jìn)行唯一標(biāo)識。消息提供平臺在將APP消息推送給消息分發(fā)器之前，在APP消息中添加接收該APP消息的終端業(yè)務(wù)平臺的平臺標(biāo)識。終端業(yè)務(wù)平臺從APP消息中解析出標(biāo)識，如果該平臺標(biāo)識為終端業(yè)務(wù)平臺自身的平臺標(biāo)識，則處理該條APP消息；如果該平臺標(biāo)識為其他終端業(yè)務(wù)平臺的平臺標(biāo)識，則丟棄該APP消息。
[0095]307、終端業(yè)務(wù)平臺通過APP消息中的APP標(biāo)識請求APP的APK信息。
[0096]如圖1步驟101中所述，該APP消息封裝有與該APP消息對應(yīng)的終端業(yè)務(wù)平臺的標(biāo)識信息和APP消息的標(biāo)識信息。當(dāng)消息隊列中的APP消息為終端業(yè)務(wù)平臺所需的APP消息時，終端業(yè)務(wù)平臺從該APP消息中解析出APP的標(biāo)識，并對該APP標(biāo)識進(jìn)行上報以獲取APP的安卓程序包(Android Package，簡稱APK)信息。本實施例中，APP標(biāo)識應(yīng)當(dāng)能夠?qū)PP起到唯一標(biāo)識的作用，實際應(yīng)用中可以以APP名稱或APP版本號作為APP標(biāo)識使用，而將兩者組合使用則更為優(yōu)選。
[0097]消息提供平臺在接收到終端業(yè)務(wù)平臺上報的APP標(biāo)識后，據(jù)此查找對應(yīng)APP的APK信息，并將查找到的APK信息下發(fā)給終端業(yè)務(wù)平臺。
[0098]實際應(yīng)用中，APK信息具體可以為下述信息中的至少一種:APP分類、APP元數(shù)據(jù)、APP安裝包、APP更新包、APP版本號、APP下載記錄、APP適配系統(tǒng)/機(jī)型、APP標(biāo)簽、評論、點贊信息、開發(fā)者信息、用戶信息及國際化信息。
[0099]308、終端業(yè)務(wù)平臺根據(jù)APK信息對APP進(jìn)行上線或更新。
[0100]終端業(yè)務(wù)平臺在接收到APK信息后，將其上線到應(yīng)用商店中，供用戶查看選擇，由此完成APP或APP更新包的整個上線流程。
[0101]進(jìn)一步的，針對APP消息接收失敗的情況，本發(fā)明另一實施例還給出了一種消息持久化保存機(jī)制。在本實施例中，終端業(yè)務(wù)平臺在成功監(jiān)聽并接收到APP消息后，會向消息隊列發(fā)送一個表征消息接收成功的肯定應(yīng)答響應(yīng)，據(jù)此響應(yīng)，消息隊列將終端業(yè)務(wù)平臺已成功接收的APP消息從消息隊列中刪除；而當(dāng)終端業(yè)務(wù)平臺因處于不可用狀態(tài)或其他原因無法接收APP消息時，則會向消息隊列發(fā)送一個表征消息接收失敗的否定應(yīng)答響應(yīng)，據(jù)此響應(yīng)，消息隊列將未成功接收的APP消息持久化保存在消息隊列中，等待終端業(yè)務(wù)平臺后續(xù)再次接收。實際應(yīng)用中，可以以ACK信令和NACK信令分別作為肯定應(yīng)答響應(yīng)和否定應(yīng)答響應(yīng)使用。
[0102]再進(jìn)一步的，考慮到持久保存APP消息會無限增加分發(fā)平臺的資源開銷，因此本發(fā)明另一實施例還提供了一種兼顧平臺資源開銷的消息持久化保存機(jī)制。在該實施例中，消息分發(fā)器可以采用下述兩種方式對消息保存機(jī)制進(jìn)行改進(jìn):
[0103]方式一:
[0104]為寫入消息隊列中的每一條消息獨立設(shè)定一個定時器，如果某條消息的定時器到時但該消息仍未發(fā)出，則消息分發(fā)器將該條消息從消息隊列中刪除。如果刪除消息后的消息隊列中不再保存有任何消息，則消息分發(fā)器將該消息隊列進(jìn)行釋放。
[0105]此外，消息分發(fā)器還可以針對消息隊列設(shè)定全局定時器，當(dāng)定時器到時時，如果該個消息隊列中還保存有至少一條消息，則消息分發(fā)器清空所有消息并釋放消息隊列。
[0106]方式二:
[0107]為消息隊列設(shè)定消息保存的總數(shù)據(jù)量上限，若消息隊列中存儲的所有消息的數(shù)據(jù)大小之和超過該總數(shù)據(jù)量上限，則消息分發(fā)器以時序為依據(jù)，按照保存時間由長到短的順序?qū)﹃犃兄斜４娴南⑦M(jìn)行刪除，直至剩余消息的數(shù)據(jù)大小之和低于該總數(shù)據(jù)量上限為止。當(dāng)然，消息分發(fā)器也可以一次性將所有消息清空并釋放消息隊列。
[0108]圖3所示實施例給出消息隊列數(shù)量與終端業(yè)務(wù)平臺數(shù)量相等時的實現(xiàn)方式，下面本發(fā)明另一實施例將基于消息隊列數(shù)量少于終端業(yè)務(wù)平臺數(shù)量的情況，給出一種消息隊列復(fù)用的實現(xiàn)方式。如圖4所示，該實現(xiàn)方式的方法包括:
[0109]401、消息提供平臺接收APP或APP更新包。
[0110]402、消息提供平臺后端對接收的APP或APP更新包進(jìn)行審核。
[0111]403、消息分發(fā)器建立少于終端業(yè)務(wù)平臺數(shù)量的消息隊列。
[0112]本實施例步驟401至步驟403的實現(xiàn)方式分別與圖3中步驟301至步驟303的實現(xiàn)方式對應(yīng)相同，唯一不同之處在于，步驟403中建立的消息隊列的數(shù)量小于終端業(yè)務(wù)平臺的數(shù)量。例如為5個終端業(yè)務(wù)平臺建立3個消息隊列，或者為6個終端業(yè)務(wù)平臺建立2個消息隊列。本實施例不對消息隊列與終端業(yè)務(wù)平臺之間的數(shù)量差異進(jìn)行限制，極端情況下，可以為任意數(shù)量的終端業(yè)務(wù)平臺僅建立一個消息隊列。
[0113]404、消息分發(fā)器建立消息隊列與部分終端業(yè)務(wù)平臺之間一一對應(yīng)的綁定連接。
[0114]由于消息隊列的數(shù)量有限，因此只能通過有限的消息隊列先為部分終端業(yè)務(wù)平臺進(jìn)行消息分發(fā)。對應(yīng)的，消息隊列需要先與這部分終端業(yè)務(wù)平臺建立綁定連接。本實施例中，部分終端業(yè)務(wù)平臺的數(shù)量由消息隊列的數(shù)量來決定，例如當(dāng)為7個終端業(yè)務(wù)平臺建立4個消息隊列時，首先將4個終端業(yè)務(wù)平臺綁定到4個消息隊列上。
[0115]本實施例中首批終端業(yè)務(wù)平臺的選定規(guī)則可以由按照終端標(biāo)識規(guī)律決定，例如標(biāo)識排序順序，標(biāo)識種類對應(yīng)的優(yōu)先級等；也可以由終端業(yè)務(wù)平臺對用戶服務(wù)時延的容忍度決定；亦或者可以由運維人員根據(jù)實際運營策略人工決定，本實施例對此不作限制。
[0116]本步驟的實現(xiàn)方式與圖3步驟404的實現(xiàn)方式相同，此處不再贅述。
[0117]405、在APP上線或APP更新審核通過后，消息提供平臺生成APP消息，并向消息分發(fā)器推送APP消息，由消息分發(fā)器將APP消息進(jìn)行復(fù)制，并分別寫入到與消息分發(fā)器連接的各個消息隊列中。
[0118]406、終端業(yè)務(wù)平臺對對應(yīng)的消息隊列進(jìn)行監(jiān)聽。
[0119]407、終端業(yè)務(wù)平臺通過APP消息中的APP標(biāo)識請求APP的APK信息。
[0120]408、終端業(yè)務(wù)平臺根據(jù)APK信息對APP進(jìn)行上線或更新。
[0121 ] 步驟405至步驟408的實現(xiàn)方式分別與圖3中步驟305至步驟308的實現(xiàn)方式對應(yīng)相同，不同之處在于，本實施例截止到步驟408僅實現(xiàn)的首批終端業(yè)務(wù)平臺對APP消息的接收和處理，而剩余終端業(yè)務(wù)平臺對APP消息的接收和處理，則由步驟409起始的后續(xù)步驟實現(xiàn)。
[0122]409、在終端業(yè)務(wù)平臺從其連接的消息隊列中獲取APP消息之后，消息分發(fā)器解除終端業(yè)務(wù)平臺與消息隊列的綁定連接。
[0123]410、消息分發(fā)器建立其他終端業(yè)務(wù)平臺與消息隊列之間一一對應(yīng)的綁定連接。
[0124]步驟409中所述的終端業(yè)務(wù)平臺為首批與消息隊列進(jìn)行綁定并接收APP消息的終端業(yè)務(wù)平臺，而步驟410中所述的其他終端業(yè)務(wù)平臺則為剩余并即將與消息隊列進(jìn)行綁定連接的終端業(yè)務(wù)平臺。在步驟409中，消息分發(fā)器可以通過msgget函數(shù)的逆向工程函數(shù)將在前綁定的終端業(yè)務(wù)平臺的key值從消息隊列中刪除，由此解除首批終端業(yè)務(wù)平臺與消息隊列的綁定連接。需要說明的是，本實施例中綁定連接解除后，消息隊列仍然存在，解除綁定關(guān)系不等同于釋放消息隊列。
[0125]本實施例中，步驟410的實現(xiàn)方式與步驟404的實現(xiàn)方式相同，此處不再贅述。
[0126]411、消息分發(fā)器再次復(fù)制APP消息，并向消息隊列寫入再次復(fù)制的APP消息，以使得其他終端業(yè)務(wù)平臺通過消息隊列獲取再次復(fù)制的APP消息。
[0127]在消息隊列完成與其余終端業(yè)務(wù)平臺的綁定連接后，消息分發(fā)器按照步驟405的實現(xiàn)方式，對待分發(fā)的APP消息再次進(jìn)行復(fù)制，然后將再次復(fù)制的多份相同的APP消息分別寫入到各個消息隊列中，以便其余終端業(yè)務(wù)平臺進(jìn)行接收和處理。
[0128]下面，結(jié)合上述圖3或圖4所示的方法，給出本發(fā)明實施例的一種應(yīng)用場景。圖5示出了一種集APP上傳、APP審核、APP消息分發(fā)為一體的場景示意圖。其中，該場景包括了如下幾部分對象:
[0129]1、APP爬蟲工具；
[0130]2、開發(fā)者開放平臺；
[0131]3、TV應(yīng)用商店平臺；
[0132]4、游戲中心平臺；
[0133]5、手機(jī)應(yīng)用商店平臺；
[0134]6、客戶端；
[0135]7、智能設(shè)備應(yīng)用商店平臺；
[0136]8、車聯(lián)網(wǎng)應(yīng)用商店平臺；
[0137]9、企業(yè)管理信息系統(tǒng)OMS ;
[0138]10、cipid 消息隊列；
[0139]11、ka(king-arthur)；
[0140]12、彈性搜索引擎 elastic-search ；
[0141]13、重申緩存 redis ;
[0142]14、數(shù)據(jù)庫。
[0143]其中，APP爬蟲工具及開發(fā)者開放平臺屬于APP或APP更新包的來源，用于提供待上線的APP或APP更新包；TV應(yīng)用商店平臺、游戲中心平臺、智能設(shè)備應(yīng)用商店平臺及車聯(lián)網(wǎng)應(yīng)用商店平臺作為終端業(yè)務(wù)平臺，用于通過消息隊列接收APP消息；值得說明的是，圖5中的客戶端存在日志分析及數(shù)據(jù)統(tǒng)計需求，開發(fā)者開放平臺則存在APP上線信息反饋的需求，而elastic-search則需要同步最新的APK信息以便用戶搜索，因此與終端業(yè)務(wù)平臺類似，上述三者也扮演接收APP消息的角色；qpid消息隊列包含消息分發(fā)器，用于建立消息隊列、分配key值、寫入APP消息；ka與redis及數(shù)據(jù)庫進(jìn)行交互，用于為終端業(yè)務(wù)平臺提供APP的APK信息；0MS負(fù)責(zé)整體運維管理。
[0144]在圖5所示的場景中，APP爬蟲工具或開發(fā)者開放平臺上報APP或APP更新包進(jìn)行審核。待審核通過后，qpid消息隊列建立8個消息隊列，分別對應(yīng)開發(fā)者開放平臺、TV應(yīng)用商店平臺等8個終端業(yè)務(wù)平臺。圖6為消息隊列與終端業(yè)務(wù)平臺對接的示意圖，在圖6中，每一對消息隊列與終端業(yè)務(wù)平臺的組合都分配有一個key值。通過各自的消息隊列，終端業(yè)務(wù)平臺接收消息分發(fā)器通過消息隊列分發(fā)的APP消息。
[0145]進(jìn)一步的，結(jié)合圖5所示場景，本發(fā)明的另一實施例對APP消息的具體形式進(jìn)行示例性說明。如圖7所示，APP消息的結(jié)構(gòu)化字段包括:程序包名(Package Name)字段、操作類型(opType)字段、業(yè)務(wù)平臺(Platform)字段及版本號(Verson Code)字段。其中，程序包名字段用于記錄APP名稱；操作類型字段記錄的信息包括Update及Create，其中，Update代表APP更新，Create代表新APP上線；業(yè)務(wù)平臺字段記錄終端業(yè)務(wù)平臺的平臺標(biāo)識；版本號字段記錄APP的最新版本。
[0146]終端業(yè)務(wù)平臺在接收到如圖7所示的一條APP消息后，對其進(jìn)行解析，通過業(yè)務(wù)平臺字段中記錄的平臺標(biāo)識判斷是否保留該條APP消息。在圖7中，業(yè)務(wù)平臺字段記錄有“ gc I ”、“ gc2 ”及“ gc3 ”三個平臺標(biāo)識，表示該條APP消息應(yīng)當(dāng)被游戲中心平臺1、游戲中心平臺2及游戲中心平臺3三個終端業(yè)務(wù)平臺接收。可選的，如果業(yè)務(wù)平臺字段為空，則表示該條APP消息應(yīng)當(dāng)被所有終端業(yè)務(wù)平臺接收。在獲得應(yīng)當(dāng)保留的APP消息之后，終端業(yè)務(wù)平臺從該消息的程序包名字段和版本號字段中讀取APP的名稱及版本號，并將名稱及版本號的組合作為APP標(biāo)識上報給消息提供平臺，可選的，版本號字段為空代表該APP為當(dāng)前最新版本。分發(fā)平臺接收到APP的名稱及版本號后查找對應(yīng)的APP并通過ka將該APP的APK信息發(fā)送給終端業(yè)務(wù)平臺。其中，ka可以在終端業(yè)務(wù)平臺上報APP標(biāo)識時向數(shù)據(jù)庫請求獲取APK信息，也可以通過redis對請求過的APK信息進(jìn)行緩存，以便在后續(xù)反饋APK信息時減少訪問數(shù)據(jù)庫的次數(shù)。終端業(yè)務(wù)平臺在接收到APK信息后將其上線到應(yīng)用商店中，完成APP上線流程。
[0147]在本實施例中，APP消息可以使用不同的格式，但較為優(yōu)選的，應(yīng)當(dāng)將APP消息設(shè)定為jason格式。與傳統(tǒng)的消息格式(例如二進(jìn)制格式)相比，jason格式是一種輕量化的數(shù)據(jù)交換格式，具有可視化特點，易于編程人員查看和編寫。同時相對二進(jìn)制等傳統(tǒng)數(shù)據(jù)交換格式而言，jason格式無需進(jìn)行編譯轉(zhuǎn)換，易于機(jī)器解析。示例性的，一種jason格式的APP消息形式如下:
[0148]{ " PackageName ": " wb.gc.zzx.axe " , " opType ": " Update ","Platform ": " gel " , " VersonCode ": " 1.0 " }
[0149]進(jìn)一步的，本發(fā)明另一實施例還提供了一種消息分發(fā)器。如圖8所示，該消息分發(fā)器包括:接收單元81、復(fù)制單元82和寫入單元83 ;其中，
[0150]接收單元81，用于接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，APP消息中包含APP上線或APP更新的索引信息；
[0151]復(fù)制單元82，用于將接收單元81接收的APP消息進(jìn)行復(fù)制；
[0152]寫入單元83，用于向每一個與消息分發(fā)器連接的消息隊列寫入一份復(fù)制單元82復(fù)制的APP消息，消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取APP消息，進(jìn)而根據(jù)索引信息確定APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。
[0153]進(jìn)一步的，如圖9所示，該消息分發(fā)器還包括:
[0154]建立單元84，用于在復(fù)制單元82將接收的APP消息進(jìn)行復(fù)制，并由寫入單元83向每一個與消息分發(fā)器連接的消息隊列寫入一份復(fù)制單元82復(fù)制的APP消息之前，建立終端業(yè)務(wù)平臺與消息隊列之間一一對應(yīng)的綁定連接，每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識O
[0155]進(jìn)一步的，建立單元84用于初始化建立與消息隊列的綁定連接，添加建立與消息隊列的綁定連接。
[0156]進(jìn)一步的，復(fù)制單元82用于通過扇出模式將APP消息扇出為多份相同的APP消息，其中，扇出的APP消息的份數(shù)與消息隊列的數(shù)量相同；
[0157]寫入單元83，用于分別向每一個與消息分發(fā)器連接的消息隊列寫入一份APP消息。
[0158]進(jìn)一步的，如圖9所示，消息分發(fā)器還包括:
[0159]解除單元85，用于在終端業(yè)務(wù)平臺從其連接的消息隊列中獲取APP消息之后，解除建立單元84建立的終端業(yè)務(wù)平臺與消息隊列的綁定連接；
[0160]建立單元84，用于建立其他終端業(yè)務(wù)平臺與消息隊列之間一一對應(yīng)的綁定連接。
[0161]進(jìn)一步的，復(fù)制單元82，用于在建立單元84建立其他終端業(yè)務(wù)平臺與消息隊列之間一一對應(yīng)的綁定連接之后，再次復(fù)制APP消息；
[0162]寫入單元83，用于向消息隊列寫入復(fù)制單元82再次復(fù)制的APP消息，以使得其他終端業(yè)務(wù)平臺通過消息隊列獲取再次復(fù)制的APP消息。
[0163]進(jìn)一步的，本發(fā)明另一實施例還提供了一種終端業(yè)務(wù)平臺。如圖10所示，該終端業(yè)務(wù)平臺包括:監(jiān)聽單元101、讀取單元102、確定單元103及處理單元104 ;其中，
[0164]監(jiān)聽單元101，用于監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息；
[0165]讀取單元102，用于當(dāng)監(jiān)聽單元101監(jiān)聽到其連接的消息隊列中寫入APP消息時，從消息隊列中將APP消息讀出；
[0166]確定單元103，用于根據(jù)索引信息確定讀取單元102讀取的APP消息是否為終端業(yè)務(wù)平臺自身所需的APP消息；
[0167]處理單元104，用于當(dāng)確定單元103確定為終端業(yè)務(wù)平臺自身所需的APP消息時，按照終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新APP消息對應(yīng)的APP。
[0168]進(jìn)一步的，監(jiān)聽單元101監(jiān)聽到的APP信息中的索引信息包括APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息。
[0169]進(jìn)一步的，如圖11所示，確定單元103包括:
[0170]解析模塊1031，用于對APP消息進(jìn)行解析，獲取APP消息中包含的索引信息，索引信息中包含APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息；
[0171]比對模塊1032，用于將解析模塊1031獲取的終端業(yè)務(wù)平臺標(biāo)識信息與終端業(yè)務(wù)平臺自身的標(biāo)識信息進(jìn)行對比；
[0172]確定模塊1033，用于當(dāng)比對模塊1032比對兩者一致時，確定APP消息為終端業(yè)務(wù)平臺自身所需的APP消息，當(dāng)比對模塊1032比對兩者不一致時，確定APP消息不為終端業(yè)務(wù)平臺自身所需的APP消息。
[0173]進(jìn)一步的，如圖11所示，處理單元104包括:
[0174]請求模塊1041，用于按照終端業(yè)務(wù)平臺預(yù)定處理流程請求獲取APP標(biāo)識信息對應(yīng)的APP安卓程序包APK信息；
[0175]處理模塊1042，用于根據(jù)請求模塊1041請求的APK信息，對APP標(biāo)識信息對應(yīng)的APP進(jìn)行上線或者更新。
[0176]進(jìn)一步的，處理單元104，用于當(dāng)確定單元103確定不為終端業(yè)務(wù)平臺自身所需的APP消息時，將APP消息丟掉。
[0177]進(jìn)一步的，本發(fā)明另一實施例還提供了一種消息分發(fā)系統(tǒng)，如圖12所示，該系統(tǒng)包括:消息提供平臺121、消息分發(fā)器122、消息隊列123和終端業(yè)務(wù)平臺124 ;
[0178]其中，消息分發(fā)器122為上述圖8或圖9所示的消息分發(fā)器，終端業(yè)務(wù)平臺124為上述圖10或圖11所示的終端業(yè)務(wù)平臺；
[0179]消息提供平臺121，用于產(chǎn)生APP消息，并將APP消息發(fā)送給消息分發(fā)器122 ;
[0180]每個消息隊列123具有區(qū)別其他消息隊列的唯一標(biāo)識。
[0181]本實施例中，為每一個終端業(yè)務(wù)平臺建立一個對應(yīng)的消息隊列，當(dāng)消息提供平臺需要發(fā)送APP消息時，直接由消息分發(fā)器向每一個終端業(yè)務(wù)平臺對應(yīng)的消息隊列發(fā)送一份相同的APP消息，該種向消息隊列發(fā)送APP消息的方式屬于無區(qū)分發(fā)送，只要消息隊列與消息分發(fā)器連接，APP消息就會發(fā)送到連接的消息隊列中，該種消息分發(fā)的方式無需關(guān)心分發(fā)對象、分發(fā)方式等具體策略，簡單易操作，避免了消息提供平臺發(fā)送APP消息的復(fù)雜邏輯。并且，基于消息隊列具有消息持久化保存的特性，APP消息發(fā)送到消息隊列中之后會暫存在各個消息隊列中，各終端業(yè)務(wù)平臺會監(jiān)聽與其對應(yīng)的消息隊列，當(dāng)監(jiān)聽到消息隊列中有APP消息時，才將APP消息從消息隊列中取出；所以當(dāng)APP消息發(fā)出但是對應(yīng)的終端業(yè)務(wù)平臺不正常工作無法成功接收APP消息時，無需部署消息重發(fā)、消息丟棄等復(fù)雜的策略。另外，各終端業(yè)務(wù)平臺在監(jiān)聽到各自對應(yīng)的消息隊列中有APP消息時，會對APP消息進(jìn)行一個識別，只對所述終端業(yè)務(wù)平臺所需的APP消息進(jìn)行處理，這樣對APP消息的識別和分類放在終端業(yè)務(wù)平臺進(jìn)行，在一定程度上降低了消息提供平臺分發(fā)消息的邏輯。綜上，與現(xiàn)有技術(shù)中的同步分發(fā)機(jī)制相比，本發(fā)明能夠大大簡化分發(fā)平臺側(cè)的分發(fā)邏輯，實現(xiàn)分發(fā)平臺的輕量化設(shè)計。
[0182]本實施例中，APP消息發(fā)送給各終端業(yè)務(wù)平臺對應(yīng)的消息隊列后，各終端業(yè)務(wù)平臺從各自對應(yīng)的消息隊列中接收APP消息的過程是相互獨立的，終端業(yè)務(wù)平臺可以根據(jù)自身的實際情況靈活確定消息接收的時間，各終端業(yè)務(wù)平臺無需同時開始或結(jié)束APP消息的接收。同時，由于終端業(yè)務(wù)平臺是基于各自的消息隊列接收APP消息的，因此當(dāng)某個或某幾個終端業(yè)務(wù)平臺處于不可用狀態(tài)時，也不會影響其他終端業(yè)務(wù)平臺對APP消息的正常接收。本質(zhì)上，消息接收的獨立性和抗干擾性有了很大提升。
[0183]此外，本方法還具有以下幾點優(yōu)勢:
[0184]1、異步特性:現(xiàn)有技術(shù)中分發(fā)平臺采用同步機(jī)制分發(fā)APP消息，同步分發(fā)機(jī)制可以有兩種具體的實現(xiàn)方式，第一，建立多線程同時向多個終端業(yè)務(wù)平臺發(fā)送消息；第二，依次向各個終端業(yè)務(wù)平臺順序發(fā)送消息。當(dāng)系統(tǒng)中的終端業(yè)務(wù)平臺數(shù)量增加時，對于前者方式，需要增加分發(fā)平臺的并發(fā)數(shù)資源開銷，對于后者方式，則會延長消息分發(fā)的時間。而在本方法中，通過簡單的方法調(diào)用即可實現(xiàn)消息隊列的建立，并且多個消息隊列的消息分發(fā)并行進(jìn)行，無論終端業(yè)務(wù)平臺的數(shù)量如何增加，消息提供平臺僅需要傳遞一次APP消息即可，相對現(xiàn)有技術(shù)而言，能夠大大降低并發(fā)數(shù)資源開銷并縮短分發(fā)耗時。
[0185]2、靈活性:現(xiàn)有技術(shù)中，如果增減終端業(yè)務(wù)平臺的數(shù)量，則需要改動分發(fā)平臺側(cè)的分發(fā)邏輯，實現(xiàn)起來復(fù)雜耗時，消息分發(fā)具有一定的滯后性。而在本發(fā)明中，僅通過簡單的方法調(diào)用就可以實現(xiàn)消息隊列的建立和釋放，相對現(xiàn)有技術(shù)而言，本方法能夠靈活便捷的增減終端業(yè)務(wù)平臺的數(shù)量，保障APP消息的及時分發(fā)。
[0186]在上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關(guān)描述。
[0187]所屬領(lǐng)域的技術(shù)人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統(tǒng)，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應(yīng)過程，在此不再贅述。
[0188]在此提供的算法和顯示不與任何特定計算機(jī)、虛擬系統(tǒng)或者其它設(shè)備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對任何特定編程語言。應(yīng)當(dāng)明白，可以利用各種編程語言實現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對特定語言所做的描述是為了披露本發(fā)明的最佳實施方式。
[0189]在此處所提供的說明書中，說明了大量具體細(xì)節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細(xì)節(jié)的情況下實踐。在一些實例中，并未詳細(xì)示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對本說明書的理解。
[0190]類似地，應(yīng)當(dāng)理解，為了精簡本公開并幫助理解各個發(fā)明方面中的一個或多個，在上面對本發(fā)明的示例性實施例的描述中，本發(fā)明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖:即所要求保護(hù)的本發(fā)明要求比在每個權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個實施例的所有特征。因此，遵循【具體實施方式】的權(quán)利要求書由此明確地并入該【具體實施方式】，其中每個權(quán)利要求本身都作為本發(fā)明的單獨實施例。
[0191]本領(lǐng)域那些技術(shù)人員可以理解，可以對實施例中的設(shè)備中的模塊進(jìn)行自適應(yīng)性地改變并且把它們設(shè)置在與該實施例不同的一個或多個設(shè)備中?？梢园褜嵤├械哪K或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設(shè)備的所有過程或單元進(jìn)行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。
[0192]此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實施例。例如，在下面的權(quán)利要求書中，所要求保護(hù)的實施例的任意之一都可以以任意的組合方式來使用。
[0193]本發(fā)明的各個部件實施例可以以硬件實現(xiàn)，或者以在一個或者多個處理器上運行的軟件模塊實現(xiàn)，或者以它們的組合實現(xiàn)。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以在實踐中使用微處理器或者數(shù)字信號處理器(DSP)來實現(xiàn)根據(jù)本發(fā)明實施例的發(fā)明名稱(如確定網(wǎng)站內(nèi)鏈接等級的裝置)中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設(shè)備或者裝置程序(例如，計算機(jī)程序和計算機(jī)程序產(chǎn)品)。這樣的實現(xiàn)本發(fā)明的程序可以存儲在計算機(jī)可讀介質(zhì)上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。
[0194]應(yīng)該注意的是上述實施例對本發(fā)明進(jìn)行說明而不是對本發(fā)明進(jìn)行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設(shè)計出替換實施例。在權(quán)利要求中，不應(yīng)將位于括號之間的任何參考符號構(gòu)造成對權(quán)利要求的限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當(dāng)編程的計算機(jī)來實現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。
【主權(quán)項】
1.一種消息分發(fā)的方法，其特征在于，包括: 消息分發(fā)器接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，所述APP消息中包含APP上線或APP更新的索引信息； 將接收的所述APP消息進(jìn)行復(fù)制，并向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與所述消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取所述APP消息，進(jìn)而根據(jù)所述索引信息確定所述APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在將接收的所述APP消息進(jìn)行復(fù)制，并向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述APP消息之前，還包括: 建立終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接，每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識。3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述建立終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接包括: 初始化建立與所述消息隊列的綁定連接； 添加建立與所述消息隊列的綁定連接。4.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述將接收的所述APP消息進(jìn)行復(fù)制，并向每一個與所述消息分發(fā)器連接的消息隊列寫入所述APP消息包括: 通過扇出模式將所述APP消息扇出為多份相同的APP消息，其中，扇出的APP消息的份數(shù)與消息隊列的數(shù)量相同； 分別向每一個與所述消息分發(fā)器連接的消息隊列寫入一份APP消息。5.根據(jù)權(quán)利要求2所述的方法，其特征在于，在終端業(yè)務(wù)平臺從其連接的消息隊列中獲取所述APP消息之后，還包括: 解除所述終端業(yè)務(wù)平臺與所述消息隊列的綁定連接； 建立其他終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接。6.根據(jù)權(quán)利要求5所述的方法，其特征在于，在所述建立其他終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接之后，還包括: 再次復(fù)制所述APP消息，并向所述消息隊列寫入再次復(fù)制的所述APP消息，以使得所述其他終端業(yè)務(wù)平臺通過所述消息隊列獲取所述再次復(fù)制的所述APP消息。7.根據(jù)權(quán)利要求1-6中任意項所述的方法，其特征在于，所述索引信息包括APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息。8.一種消息分發(fā)的方法，其特征在于，包括: 終端業(yè)務(wù)平臺監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與所述終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；所述APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與所述消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息； 若監(jiān)聽到其連接的消息隊列中寫入APP消息，則從所述消息隊列中將所述APP消息讀出，并根據(jù)所述索引信息確定所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息; 若確定為所述終端業(yè)務(wù)平臺自身所需的APP消息，則按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP。9.根據(jù)權(quán)利要求8所述的方法，其特征在于，所述索引信息包括APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息。10.根據(jù)權(quán)利要求9所述的方法，其特征在于，所述根據(jù)所述索引信息確定所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息包括: 對所述APP消息進(jìn)行解析，獲取所述APP消息中包含的索引信息，所述索引信息中包含APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息； 將獲取的終端業(yè)務(wù)平臺標(biāo)識信息與所述終端業(yè)務(wù)平臺自身的標(biāo)識信息進(jìn)行對比； 若兩者一致，則確定所述APP消息為所述終端業(yè)務(wù)平臺自身所需的APP消息； 若兩者不一致，則確定所述APP消息不為所述終端業(yè)務(wù)平臺自身所需的APP消息。11.根據(jù)權(quán)利要求10所述的方法，其特征在于，所述按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP包括: 按照所述終端業(yè)務(wù)平臺預(yù)定處理流程請求獲取所述APP標(biāo)識信息對應(yīng)的APP安卓程序包APK信息； 根據(jù)所述APK信息，對所述APP標(biāo)識信息對應(yīng)的APP進(jìn)行上線或者更新。12.根據(jù)權(quán)利要求8-11中任一項所述的方法，其特征在于，還包括: 若確定不為所述終端業(yè)務(wù)平臺自身所需的APP消息，則將所述APP消息丟掉。13.一種消息分發(fā)器，其特征在于，包括: 接收單元，用于接收消息提供平臺發(fā)送的應(yīng)用程序APP消息，所述APP消息中包含APP上線或APP更新的索引信息； 復(fù)制單元，用于將所述接收單元接收的所述APP消息進(jìn)行復(fù)制； 寫入單元，用于向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述復(fù)制單元復(fù)制的所述APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與終端業(yè)務(wù)平臺連接，另一端與所述消息分發(fā)器連接，每個終端業(yè)務(wù)平臺分別從其各自連接的消息隊列中獲取所述APP消息，進(jìn)而根據(jù)所述索引信息確定所述APP消息是否為各終端業(yè)務(wù)平臺自身所需的APP消息。14.根據(jù)權(quán)利要求13所述的消息分發(fā)器，其特征在于，所述消息分發(fā)器還包括: 建立單元，用于在所述復(fù)制單元將接收的所述APP消息進(jìn)行復(fù)制，并由所述寫入單元向每一個與所述消息分發(fā)器連接的消息隊列寫入一份所述復(fù)制單元復(fù)制的所述APP消息之前，建立終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接，每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識。15.根據(jù)權(quán)利要求14所述的消息分發(fā)器，其特征在于，所述建立單元用于初始化建立與所述消息隊列的綁定連接，添加建立與所述消息隊列的綁定連接。16.根據(jù)權(quán)利要求14所述的消息分發(fā)器，其特征在于，所述復(fù)制單元用于通過扇出模式將所述APP消息扇出為多份相同的APP消息，其中，扇出的APP消息的份數(shù)與消息隊列的數(shù)量相同； 所述寫入單元，用于分別向每一個與所述消息分發(fā)器連接的消息隊列寫入一份APP消息。17.根據(jù)權(quán)利要求14所述的消息分發(fā)器，其特征在于，所述消息分發(fā)器還包括: 解除單元，用于在終端業(yè)務(wù)平臺從其連接的消息隊列中獲取所述APP消息之后，解除所述建立單元建立的所述終端業(yè)務(wù)平臺與所述消息隊列的綁定連接； 所述建立單元，用于建立其他終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接。18.根據(jù)權(quán)利要求17所述的消息分發(fā)器，其特征在于，所述復(fù)制單元，用于在所述建立單元建立其他終端業(yè)務(wù)平臺與所述消息隊列之間一一對應(yīng)的綁定連接之后，再次復(fù)制所述APP消息; 所述寫入單元，用于向所述消息隊列寫入所述復(fù)制單元再次復(fù)制的所述APP消息，以使得所述其他終端業(yè)務(wù)平臺通過所述消息隊列獲取所述再次復(fù)制的所述APP消息。19.一種終端業(yè)務(wù)平臺，其特征在于，包括: 監(jiān)聽單元，用于監(jiān)聽其對應(yīng)的消息隊列中是否寫入APP消息，所述消息隊列為數(shù)據(jù)傳輸通道，一端與所述終端業(yè)務(wù)平臺連接，另一端與消息分發(fā)器連接；所述APP消息為消息分發(fā)器在接收到消息提供平臺發(fā)送的APP消息后，經(jīng)復(fù)制向每一個與所述消息分發(fā)器連接的消息隊列寫入一份的APP消息，其中包含APP上線或APP更新的索引信息； 讀取單元，用于當(dāng)所述監(jiān)聽單元監(jiān)聽到其連接的消息隊列中寫入APP消息時，從所述消息隊列中將所述APP消息讀出； 確定單元，用于根據(jù)所述索引信息確定所述讀取單元讀取的所述APP消息是否為所述終端業(yè)務(wù)平臺自身所需的APP消息； 處理單元，用于當(dāng)所述確定單元確定為所述終端業(yè)務(wù)平臺自身所需的APP消息時，按照所述終端業(yè)務(wù)平臺預(yù)定處理流程創(chuàng)建或更新所述APP消息對應(yīng)的APP。20.根據(jù)權(quán)利要求19所述的終端業(yè)務(wù)平臺，其特征在于，所述監(jiān)聽單元監(jiān)聽到的所述APP信息中的所述索引信息包括APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息。21.根據(jù)權(quán)利要求20所述的終端業(yè)務(wù)平臺，其特征在于，所述確定單元包括: 解析模塊，用于對所述APP消息進(jìn)行解析，獲取所述APP消息中包含的索引信息，所述索引信息中包含APP標(biāo)識信息和終端業(yè)務(wù)平臺標(biāo)識信息； 比對模塊，用于將所述解析模塊獲取的終端業(yè)務(wù)平臺標(biāo)識信息與所述終端業(yè)務(wù)平臺自身的標(biāo)識信息進(jìn)行對比； 確定模塊，用于當(dāng)所述比對模塊比對兩者一致時，確定所述APP消息為所述終端業(yè)務(wù)平臺自身所需的APP消息，當(dāng)所述比對模塊比對兩者不一致時，確定所述APP消息不為所述終端業(yè)務(wù)平臺自身所需的APP消息。22.根據(jù)權(quán)利要求21所述的終端業(yè)務(wù)平臺，其特征在于，所述處理單元包括: 請求模塊，用于按照所述終端業(yè)務(wù)平臺預(yù)定處理流程請求獲取所述APP標(biāo)識信息對應(yīng)的APP安卓程序包APK信息； 處理模塊，用于根據(jù)所述請求模塊請求的所述APK信息，對所述APP標(biāo)識信息對應(yīng)的APP進(jìn)行上線或者更新。23.根據(jù)權(quán)利要求19-22中任一項所述的終端業(yè)務(wù)平臺，其特征在于，所述處理單元，用于當(dāng)所述確定單元確定不為所述終端業(yè)務(wù)平臺自身所需的APP消息時，將所述APP消息丟掉。24.一種消息分發(fā)系統(tǒng)，其特征在于，包括:消息提供平臺、如權(quán)利要求13-18中任一項所述的消息分發(fā)器、消息隊列和如權(quán)利要求19-23中任一項所述的終端業(yè)務(wù)平臺；所述消息提供平臺，用于產(chǎn)生APP消息，并將所述APP消息發(fā)送給所述消息分發(fā)器；每個消息隊列具有區(qū)別其他消息隊列的唯一標(biāo)識。
【文檔編號】H04L29/08GK105871966SQ201510609627
【公開日】2016年8月17日
【申請日】2015年9月22日
【發(fā)明人】孟大巍, 王帥, 皮智剛
【申請人】樂視網(wǎng)信息技術(shù)（北京）股份有限公司