CN105871966A - 消息分发的方法、装置及系统 - Google Patents

Abstract

本发明公开了一种消息分发的方法、装置及系统，涉及数字信息传输领域，为解决分发平台侧分发逻辑复杂的问题而发明。本发明的方法包括：消息分发器接收消息提供平台发送的应用程序APP消息，APP消息中包含APP上线或APP更新的索引信息；将接收的APP消息进行复制，并向每一个与消息分发器连接的消息队列写入一份APP消息，消息队列为数据传输通道，一端与终端业务平台连接，另一端与消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取APP消息，进而根据索引信息确定APP消息是否为各终端业务平台自身所需的APP消息。本发明主要应用于分发APP上线或更新消息的过程中。

Description

消息分发的方法、装置及系统

技术领域

本发明涉及数字信息传输领域，尤其涉及一种消息分发的方法、装置及系统。

背景技术

随着移动互联网的发展以及智能移动设备的普及，越来越多的用户习惯使用终端下载安装应用程序(Application，简称APP)，这些该终端包括但不仅限于：PC、手机、PAD、TV、车载设备以及可穿戴设备。用户通过终端登录应用商店(APP Store)，选择并下载需要的APP或APP更新包。

在网络侧，应用商店是由以终端业务平台为后端实现管理的，不同类型的应用商店对应不同的终端业务平台。例如，手机业务平台用于手机应用商店的管理，TV业务平台用于TV应用商店的管理等。终端业务平台接收分发平台下发的APP消息，并根据接收的APP消息对应用商店中的APP产品进行上线、更新、下线等管理。

在分发平台向终端业务平台分发APP消息的过程中，现有的分发机制以同步分发为主，即分发平台同时或顺序向多个终端业务平台发送APP消息。这种消息分发机制需要以终端业务平台处于可用(available)状态为前提，如果部分终端业务平台因某些原因发生瘫痪，则需要消息重发、消息丢弃等机制对消息分发失败予以补救，由此使得分发平台侧的分发逻辑复杂化。

例如，在基于HTTP协议的消息同步分发过程中，当某个终端业务平台无法接收APP消息时，分发平台需要决定是否启动消息重发机制；如果启动消息重发机制，那么分发平台还需要决定是向所有终端业务平台全部重发APP消息，还是仅向消息接收失败的终端业务平台重发APP消息。对于后者方式，考虑到信息幂等性(idempotent)的问题，分发平台还需要丢弃向已成功接收消息的终端业务平台重发的消息，以避免APP消息的重复接收；同时，在进行消息重发时，分发平台的分发逻辑还进一步涉及到重发时机、重发次数等具体策略。由此可以看出，现有的同步分发机制需要一套复杂的分发逻辑来保证APP消息的正常分发，不利于分发平台的轻量化实现。

发明内容

本发明提供了一种消息分发的方法、装置及系统，能够解决分发平台侧分发逻辑复杂的问题。

为解决上述技术问题，本发明提供如下的技术方案：

第一方面，本发明提供一种消息分发的方法，包括：

消息分发器接收消息提供平台发送的应用程序APP消息，所述APP消息中包含APP上线或APP更新的索引信息；

将接收的所述APP消息进行复制，并向每一个与所述消息分发器连接的消息队列写入一份所述APP消息，所述消息队列为数据传输通道，一端与终端业务平台连接，另一端与所述消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取所述APP消息，进而根据所述索引信息确定所述APP消息是否为各终端业务平台自身所需的APP消息。

第二方面，本发明还提供一种消息分发的方法，包括：

终端业务平台监听其对应的消息队列中是否写入APP消息，所述消息队列为数据传输通道，一端与所述终端业务平台连接，另一端与消息分发器连接；所述APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与所述消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息；

若监听到其连接的消息队列中写入APP消息，则从所述消息队列中将所述APP消息读出，并根据所述索引信息确定所述APP消息是否为所述终端业务平台自身所需的APP消息；

若确定为所述终端业务平台自身所需的APP消息，则按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP。

第三方面，本发明还提供一种消息分发器，包括：

接收单元，用于接收消息提供平台发送的应用程序APP消息，所述APP消息中包含APP上线或APP更新的索引信息；

复制单元，用于将所述接收单元接收的所述APP消息进行复制；

写入单元，用于向每一个与所述消息分发器连接的消息队列写入一份所述复制单元复制的所述APP消息，所述消息队列为数据传输通道，一端与终端业务平台连接，另一端与所述消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取所述APP消息，进而根据所述索引信息确定所述APP消息是否为各终端业务平台自身所需的APP消息。

第四方面，本发明还提供一种终端业务平台，包括：

监听单元，用于监听其对应的消息队列中是否写入APP消息，所述消息队列为数据传输通道，一端与所述终端业务平台连接，另一端与消息分发器连接；所述APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与所述消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息；

读取单元，用于当所述监听单元监听到其连接的消息队列中写入APP消息时，从所述消息队列中将所述APP消息读出；

确定单元，用于根据所述索引信息确定所述读取单元读取的所述APP消息是否为所述终端业务平台自身所需的APP消息；

处理单元，用于当所述确定单元确定为所述终端业务平台自身所需的APP消息时，按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP。

第五方面，本发明还提供一种消息分发系统，包括：消息提供平台、如上所述的消息分发器、消息队列和如上所述的终端业务平台；

所述消息提供平台，用于产生APP消息，并将所述APP消息发送给所述消息分发器；

每个消息队列具有区别其他消息队列的唯一标识。

借由上述技术方案，本发明提供的消息分发的方法、装置及系统，为终端业务平台建立对应的消息队列，当消息提供平台需要发送APP消息时，直接由消息分发器向每一个消息队列发送一份相同的APP消息，该种向消息队列发送APP消息的方式属于无区分发送，只要消息队列与消息分发器连接，APP消息就会发送到连接的消息队列中，该种消息分发的方式无需关心分发对象、分发方式等具体策略，简单易操作，避免了消息提供平台发送APP消息的复杂逻辑。

并且，基于消息队列具有消息持久化保存的特性，APP消息发送到消息队列中之后会暂存在各个消息队列中，各终端业务平台会监听与其对应的消息队列，当监听到消息队列中有APP消息时，才将APP消息从消息队列中取出，并且当对该APP消息进行实际处理后才从该消息队列中删除；所以当APP消息发出但是对应的终端业务平台不正常工作无法成功接收APP消息时，无需部署消息重发、消息丢弃等复杂的策略。

另外，各终端业务平台在监听到各自对应的消息队列中有APP消息时，会对APP消息进行一个识别，只对所述终端业务平台所需的APP消息进行处理，这样对APP消息的识别和分类放在终端业务平台进行，在一定程度上降低了消息提供平台分发消息的逻辑。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种消息分发器侧消息分发的方法流程图；

图2示出了本发明实施例提供的一种终端业务平台侧消息分发的方法流程图；

图3示出了本发明实施例提供的一种消息分发的方法流程图；

图4示出了本发明实施例提供的另一种消息分发的方法流程图；

图5示出了本发明实施例提供的一种消息分发的场景示意图；

图6示出了本发明实施例提供的一种消息队列与终端业务平台对接的示意图；

图7示出了本发明实施例提供的一种APP消息内容的示意图；

图8示出了本发明实施例提供的一种消息分发器的组成框图；

图9示出了本发明实施例提供的另一种消息分发器的组成框图；

图10示出了本发明实施例提供的一种终端业务平台的组成框图；

图11示出了本发明实施例提供的另一种终端业务平台的组成框图；

图12示出了本发明实施例提供的一种消息分发系统的组成框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决分发平台侧分发逻辑复杂的问题，本发明实施例提供了一种消息分发的方法，通过消息队列的建立和使用实现APP消息的异步分发。该消息分发的方法所基于的消息分发系统涉及以下几个组成部分：消息提供平台、消息分发器、消息队列和终端业务平台。其中消息提供平台为APP消息产生方，消息分发器为APP消息分发方，消息队列为连接消息分发器和终端业务平台的数据通道，终端业务平台为APP消息接收方。

在执行本发明实施例之前，需要为各个终端业务平台建立对应的消息队列。一般情况下，可以创建与终端业务平台数量相等的消息队列，一个消息队列对应一个终端业务平台进行消息分发，当出于消息队列冗余备份的考虑时，可以创建多于终端业务平台数量的消息队列，而当出于提高消息队列使用率的考虑时，也可以创建少于终端业务平台数量的消息队列；在创建好消息队列之后，会为每一个消息队列分配一个唯一标识用于区分于其他消息队列，该唯一标识可以为但不局限于key值。

当为终端业务平台创建好消息队列后，需要将终端业务平台对应的消息队列与消息分发器绑定，以便消息分发器向消息队列发送APP消息。在将创建好的消息队列与消息分发器绑定之后，就建立了一个消息分发器对应多个消息队列的对应关系，每一个消息队列一端连接消息分发器，另一端连接各自对应的终端业务平台。

基于上述消息分发系统的布局，本发明实施例以下将具体说明消息分发的相关内容。

本发明实施例提供一种消息分发的方法，该方法为消息分发器侧的方法，如图1所示，该方法包括：

101、消息分发器(exchanger)接收消息提供平台发送的APP消息，所述APP消息中包含APP上线或APP更新的索引信息。

需要说明的是，本实施例中消息提供平台(producer)发送的APP消息是APP上线或更新的索引信息，并非是APP安装包或APP更新包本身。该索引信息可以是一种结构化的索引信息，本发明实施例不对索引信息的信息结构进行限制，例如可以为但不局限于json数据格式。

所述索引信息包括但不局限于APP标识信息和终端业务平台标识信息，其中，该APP标识信息唯一的标示了该APP，用于终端业务平台识别是哪一个APP，其可以是APP的包名或者ID，具体的本发明实施例对此不进行限制，只要唯一的标识该APP区别于其他APP即可。其中，该终端业务平台标识信息唯一的标示了该终端业务平台，以便接收到该APP消息的终端业务平台对该APP消息进行识别，确定其是否为该终端业务平台所需的APP消息，其可以是终端业务平台的名称，该名称可以为中文名称或者英文名称，也可以为ID，具体的本发明实施例对此也不进行限定。

所述索引信息除了上述APP标识信息和终端业务平台标识信息外，还可以包括APP的操作类型，APP的版本号等，具体的本发明实施例对此也不进行限制。

102、消息分发器将接收的所述APP消息进行复制，并向每一个与所述消息分发器连接的消息队列写入一份所述APP消息，所述消息队列为数据传输通道，一端与终端业务平台连接，另一端与所述消息分发器连接；每个终端业务平台分别从其各自连接的消息队列中获取所述APP消息，进而根据所述索引信息确定所述APP消息是否为各终端业务平台自身所需的APP消息。

其中，终端业务平台不限于包括手机应用商店平台、TV应用商店平台、游戏中心平台、智能设备应用商店平台及车联网应用商店平台等，与此同时，该终端业务平台还可以包括第三方开发者开放平台、应用搜索引擎及客户端。为便于表述，本发明后续实施例将包括开发者开放平台等在内的消息接收方统称为终端业务平台。此外，随着业务国际化趋势的发展，为防止本地终端业务平台与海外终端之间的洲际网络延时，越来越多的终端业务平台被部署在海外当地。本实施例中APP消息的接收方还包括了部署在海外的不同语言版本的终端业务平台。

该消息队列为终端业务平台创建的用于暂存APP消息的队列。本步骤中，消息分发器可以通过但不局限于方法调用的方式建立多个消息队列，并将消息提供平台推送的APP消息分别写入到这多个消息队列中。消息分发器在建立多个消息队列时，可以建立与终端业务平台数量相等的消息队列，一个终端业务平台对应一个消息队列。其中，当一个终端业务平台对应一个消息队列时，当终端业务平台数量发生增减时，消息分发器建立或释放对应增减终端业务平台的消息队列。或者进一步的，为减少建立/释放消息队列产生的资源开销，对于终端业务平台数量减少的情况，消息分发器也可以暂时维护与其对应的消息队列，当增加新的终端业务平台时，将待用的消息队列分配给新增加的终端业务平台。

需要说明的是，本实施例中所述的“一个终端业务平台对应一个消息队列”并非是“终端业务平台数量与消息队列数量相等”的充要条件。正如前面所述，消息队列的数量可以多于、少于或等于终端业务平台的数量。当消息队列数量多于终端业务平台数量时，多出的消息队列并不与任何终端业务平台连接，也不会参与APP消息的分发，仅作备份之用；而当消息队列数量少于终端业务平台数量时，多出的终端业务平台可以等待其他终端业务平台接收到APP消息后，通过其他终端业务平台使用过的消息队列进行消息接收，此时仅需改变消息队列与终端业务平台的绑定连接关系即可，这种情况下同一个消息队列可以先后与不同的终端业务平台进行绑定连接及消息发送。但是无论两者数量关系如何，在进行消息接收时，从终端业务平台的角度上看，接收APP消息的终端业务平台都会有一个消息队列对应，但是这并不代表在同一时刻上所有终端业务平台都对应有消息队列，也不代表所有的消息队列全部实现了与终端业务平台的绑定连接。

本实施例中，消息提供平台针对不同终端业务平台对APP所需的不同，会向不同终端业务平台发送不同的APP消息，消息提供平台在产生APP消息时，会将该APP消息对应的终端业务平台标识和APP标识添加在APP消息中，以便接收方能够识别。消息分发器接收到消息提供平台发出的APP消息时，不对该APP消息进行识别确定是哪个终端业务平台的APP消息，而是根据与其连接的消息队列的数量，将该APP消息进行复制得到与消息队列相同数量的APP消息，并将该复制得到的APP消息分别写入到各个消息队列中。

示例性的，4个终端业务平台A、B、C、D分别对应消息队列a，b，c，d；假设消息提供平台需要向终端业务平台A发送APP消息1和APP消息2，向终端业务平台B发送APP消息3。那么消息分发器会将APP消息1、2及3分别复制4分，然后均写入到消息队列a，b，c，d中，使得消息队列a，b，c，d中分别存有APP消息1、2及3。

本发明实施例还提供一种消息分发的方法，该方法为终端业务平台侧的方法，如图2所示，该方法包括：

201、终端业务平台监听其对应的消息队列中是否写入APP消息，所述消息队列为数据传输通道，一端与所述终端业务平台连接，另一端与消息分发器连接；所述APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与所述消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息。

基于消息提供平台将面向所有终端业务平台的APP消息全部推送到消息分发器中，消息分发器会将所有APP消息无区分的写入与消息分发器连接的全部消息队列中。各终端业务平台对各自对应的消息队列进行监听，当监听到消息队列中出现新消息时，进而执行步骤202-204的操作。

202、若监听到其连接的消息队列中写入APP消息，则从所述消息队列中将所述APP消息读出，并根据所述索引信息确定所述APP消息是否为所述终端业务平台自身所需的APP消息；若确定为所述终端业务平台自身所需的APP消息，则执行203；若确定不为所述终端业务平台自身所需的APP消息，则执行204。

其中，如步骤101中相关内容所述，消息提供平台发送APP消息时会将与该APP消息对应的终端业务平台标识和APP标识封装在该APP消息中，以便APP消息接收方识别。本发明实施例此处在监听到终端业务平台对应的消息队列中写入APP消息时，从所述消息队列中将所述APP消息读出，对所述APP消息进行解析，获取所述APP消息中包含的索引信息，所述索引信息中包含APP标识信息和终端业务平台标识信息；将获取的终端业务平台标识信息与所述终端业务平台自身的标识信息进行对比；若两者一致，则确定所述APP消息为所述终端业务平台自身所需的APP消息；若两者不一致，则确定所述APP消息不为所述终端业务平台自身所需的APP消息。

在图1所示示例中，终端业务平台A至D都会接收到APP消息1至3，对于终端业务平台A而言，其分别从APP消息1和2中解析出终端业务平台A的终端业务平台标识，则终端业务平台A将APP消息1和2确定为自身所需的APP消息，而由于APP消息3中解析出的终端业务平台标识为终端业务平台B的标识，因此终端业务平台A确定APP消息3不为自身所需的APP消息。同理，终端业务平台仅将APP消息3确定为自身所需的APP消息，而终端业务平台C和D分别将APP消息1至3全部确定为自身不需要的APP消息。

203、按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP。

其中，当APP消息中包含终端业务平台的标识信息和APP的标识信息时，按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP具体为：按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP，按照所述终端业务平台预定处理流程请求获取所述APP标识信息对应的APP安卓程序包APK信息；根据所述APK信息，对所述APP标识信息对应的APP进行上线或者更新。

在图1所示实施例中，消息提供平台和消息分发器分别扮演了消息生产者和消息分发者的角色(即前述步骤101中提到的producer和exchanger)，在本步骤中，当终端业务平台根据所述APK信息，对所述APP标识信息对应的APP进行上线或者更新时，终端业务平台扮演了消息消费者(consumer)的角色。

204、将所述APP消息丢掉。

本实施例中，为每一个终端业务平台建立一个对应的消息队列，当消息提供平台需要发送APP消息时，直接由消息分发器向每一个终端业务平台对应的消息队列发送一份相同的APP消息，该种向消息队列发送APP消息的方式属于无区分的发送，只要消息队列与消息分发器连接，APP消息就会发送到连接的消息队列中，该种消息分发的方式无需关心分发对象、分发方式等具体策略，简单易操作，避免了消息提供平台发送APP消息的复杂逻辑。

并且，基于消息队列具有消息持久化保存的特性，APP消息发送到消息队列中之后会暂存在各个消息队列中，各终端业务平台会监听与其对应的消息队列，当监听到消息队列中有APP消息时，才将APP消息从消息队列中取出；所以当APP消息发出但是对应的终端业务平台不正常工作无法成功接收APP消息时，无需部署消息重发、消息丢弃等复杂的策略。另外，各终端业务平台在监听到各自对应的消息队列中有APP消息时，会对APP消息进行一个识别，只对所述终端业务平台所需的APP消息进行处理，这样对APP消息的识别和分类放在终端业务平台进行，在一定程度上降低了消息提供平台分发消息的逻辑。综上，与现有技术中的同步分发机制相比，本发明能够大大简化分发平台侧的分发逻辑，实现分发平台的轻量化设计。

本实施例中，APP消息发送给各终端业务平台对应的消息队列后，各终端业务平台从各自对应的消息队列中接收APP消息的过程是相互独立的，终端业务平台可以根据自身的实际情况灵活确定消息接收的时间，各终端业务平台无需同时开始或结束APP消息的接收。同时，由于终端业务平台是基于各自的消息队列接收APP消息的，因此当某个或某几个终端业务平台处于不可用状态时，也不会影响其他终端业务平台对APP消息的正常接收。本质上，消息接收的独立性和抗干扰性有了很大提升。

此外，本方法还具有以下几点优势：

1、异步特性：现有技术中分发平台采用同步机制分发APP消息，同步分发机制可以有两种具体的实现方式，第一，建立多线程同时向多个终端业务平台发送消息；第二，依次向各个终端业务平台顺序发送消息。当系统中的终端业务平台数量增加时，对于前者方式，需要增加分发平台的并发数资源开销，对于后者方式，则会延长消息分发的时间。而在本方法中，通过简单的方法调用即可实现消息队列的建立，并且多个消息队列的消息分发并行进行，无论终端业务平台的数量如何增加，消息提供平台仅需要传递一次APP消息即可，相对现有技术而言，能够大大降低并发数资源开销并缩短分发耗时。

2、灵活性：现有技术中，如果增减终端业务平台的数量，则需要改动分发平台侧的分发逻辑，实现起来复杂耗时，消息分发具有一定的滞后性。而在本发明中，仅通过简单的方法调用就可以实现消息队列的建立和释放，相对现有技术而言，本方法能够灵活便捷的增减终端业务平台的数量，保障APP消息的及时分发。

进一步的，本发明另一实施例还提供了一种消息分发的方法。该方法以消息分发器建立与终端业务平台相同数量的消息队列为基础，如图3所示，该方法包括：

301、消息提供平台接收APP或APP更新包。

消息提供平台接收开发者平台上报的新APP或APP更新包。本实施例中所述的开发者平台包括内容提供商内部的开发者平台，也包括第三方开发者的开放平台。并且，本步骤中接收的APP或APP更新包还可以是通过计算机程序工具在网页页面或第三方应用商店中获取的APP。例如，通过APP爬虫工具抓取的APP或APP更新包。本实施例不对APP或APP更新包的来源不进行限制。

302、消息提供平台后端对接收的APP或APP更新包进行审核。

消息提供平台可以在后端通过机器模型对APP或APP更新包进行自动审核，也可以通过平台前端的人机交互界面向运维人员提供人工审核的功能，再或者将自动审核和人工审核机制结合使用，本实施例对此不作限制。

除此之外，消息提供平台也可以将APP审核的任务分割出去，由独立于消息提供平台的其他平台进行审核，消息提供平台仅接收审核结果即可。

303、消息分发器建立与终端业务平台同等数量的消息队列。

304、消息分发器建立终端业务平台与消息队列之间一一对应的绑定连接。

每个消息队列具有区别其他消息队列的唯一标识。本实施例中，消息分发器可以将预先为终端业务平台分配的key值与消息队列进行绑定，由此实现终端业务平台与消息队列的绑定连接。

在进行消息分发之前，消息分发器需要为终端业务平台分配具有唯一标识作用的key值，该key值用于对对应终端业务平台的消息队列进行唯一标识。实际应用中，key值可以为一串长度不限的字符串，其具体形式可以是终端业务平台的名称或平台标识，或者仅为纯数字形式的代码，本实施例不对key值的具体形式进行限定。

实际应用中，消息分发器可以在后端维护一个key值列表，当终端业务平台的数量发生增减时，消息分发器可以对该列表进行增删改查等更新操作。

本实施例中，消息分发器通过方法调用的方式建立多个消息队列，并为不同的消息队列绑定不同的key值，从而建立key值、终端业务平台及消息队列三者之间一一对应的映射关系。

在本实施例的一种实现方式中，消息分发器可以调用ftok函数获取与消息分发相关的进程间通信(Inter-Process Communication，简称IPC)键值，然后建立一个与IPC键值相对唯一的key值，该key值即为对应终端业务平台的key值。之后，消息分发器调用msgget函数，通过key值创建消息队列，完成消息队列的建立和key值的绑定。

本实施例中，消息分发器建立绑定连接的时机有两种。其一，在分发平台初始化时建立终端业务平台与消息队列的绑定连接；其二，当添加新的终端业务平台时，为新增的终端业务平台建立与消息队列的绑定连接关系。

需要说明的是，实际应用中也可以先执行步骤303至步骤304建立消息队列，然后再执行步骤301至步骤302对APP进行审核，或者同时执行步骤301至步骤302以及步骤303至步骤304。图3所示流程顺序仅为本实施例的一种实现方式，实际应用中，只要保证步骤301至步骤302在步骤305之前执行完毕即可。

305、在APP上线或APP更新审核通过后，消息提供平台生成APP消息，并向消息分发器推送APP消息，由消息分发器将APP消息进行复制，并分别写入到与消息分发器连接的各个消息队列中。

由于分发过程涉及多个终端业务平台和多个消息队列，并且每个消息队列中分发的APP消息是一样的，即一个APP消息需要分发给所有的消息队列。因此本步骤需要对待分发的APP消息进行“复制”，获得多份相同的APP消息。在一种实现方式中，消息“复制”的工作由消息分发器完成，消息提供平台向消息分发器发送一次APP消息，消息分发器通过扇出(fanout)技术将消息提供平台发送的APP消息“复制”为多份相同的APP消息，扇出的APP消息份数与消息队列的数量相同，然后消息分发器调用msgsnd函数，向每个消息队列分别写入一份APP消息。

306、终端业务平台对对应的消息队列进行监听。

如前所述，各终端业务平台接收到的APP消息完全相同，均包含发送给各个终端业务平台的所有APP消息。各个终端业务平台对各自对应的消息队列进行监听。当消息队列中写入新的APP消息时，终端业务平台对该APP消息进行接收和解析，从该APP消息中获取用于标记该条消息的标识，并根据该标识判断该条APP消息是否为其所需的APP消息。若该APP消息为其所需的APP消息，则终端业务平台执行步骤307及步骤308，按照该终端业务平台处理APP消息的处理逻辑对该APP消息进行处理；若该APP消息不为其所需的APP消息，则终端业务平台对该APP消息进行丢弃。

在本实施例的一种实现方式中，上述标识可以为终端业务平台的平台标识，该平台标识能够对终端业务平台进行唯一标识。消息提供平台在将APP消息推送给消息分发器之前，在APP消息中添加接收该APP消息的终端业务平台的平台标识。终端业务平台从APP消息中解析出标识，如果该平台标识为终端业务平台自身的平台标识，则处理该条APP消息；如果该平台标识为其他终端业务平台的平台标识，则丢弃该APP消息。

307、终端业务平台通过APP消息中的APP标识请求APP的APK信息。

如图1步骤101中所述，该APP消息封装有与该APP消息对应的终端业务平台的标识信息和APP消息的标识信息。当消息队列中的APP消息为终端业务平台所需的APP消息时，终端业务平台从该APP消息中解析出APP的标识，并对该APP标识进行上报以获取APP的安卓程序包(AndroidPackage，简称APK)信息。本实施例中，APP标识应当能够对APP起到唯一标识的作用，实际应用中可以以APP名称或APP版本号作为APP标识使用，而将两者组合使用则更为优选。

消息提供平台在接收到终端业务平台上报的APP标识后，据此查找对应APP的APK信息，并将查找到的APK信息下发给终端业务平台。

实际应用中，APK信息具体可以为下述信息中的至少一种：APP分类、APP元数据、APP安装包、APP更新包、APP版本号、APP下载记录、APP适配系统/机型、APP标签、评论、点赞信息、开发者信息、用户信息及国际化信息。

308、终端业务平台根据APK信息对APP进行上线或更新。

终端业务平台在接收到APK信息后，将其上线到应用商店中，供用户查看选择，由此完成APP或APP更新包的整个上线流程。

进一步的，针对APP消息接收失败的情况，本发明另一实施例还给出了一种消息持久化保存机制。在本实施例中，终端业务平台在成功监听并接收到APP消息后，会向消息队列发送一个表征消息接收成功的肯定应答响应，据此响应，消息队列将终端业务平台已成功接收的APP消息从消息队列中删除；而当终端业务平台因处于不可用状态或其他原因无法接收APP消息时，则会向消息队列发送一个表征消息接收失败的否定应答响应，据此响应，消息队列将未成功接收的APP消息持久化保存在消息队列中，等待终端业务平台后续再次接收。实际应用中，可以以ACK信令和NACK信令分别作为肯定应答响应和否定应答响应使用。

再进一步的，考虑到持久保存APP消息会无限增加分发平台的资源开销，因此本发明另一实施例还提供了一种兼顾平台资源开销的消息持久化保存机制。在该实施例中，消息分发器可以采用下述两种方式对消息保存机制进行改进：

方式一：

为写入消息队列中的每一条消息独立设定一个定时器，如果某条消息的定时器到时但该消息仍未发出，则消息分发器将该条消息从消息队列中删除。如果删除消息后的消息队列中不再保存有任何消息，则消息分发器将该消息队列进行释放。

此外，消息分发器还可以针对消息队列设定全局定时器，当定时器到时时，如果该个消息队列中还保存有至少一条消息，则消息分发器清空所有消息并释放消息队列。

方式二：

为消息队列设定消息保存的总数据量上限，若消息队列中存储的所有消息的数据大小之和超过该总数据量上限，则消息分发器以时序为依据，按照保存时间由长到短的顺序对队列中保存的消息进行删除，直至剩余消息的数据大小之和低于该总数据量上限为止。当然，消息分发器也可以一次性将所有消息清空并释放消息队列。

图3所示实施例给出消息队列数量与终端业务平台数量相等时的实现方式，下面本发明另一实施例将基于消息队列数量少于终端业务平台数量的情况，给出一种消息队列复用的实现方式。如图4所示，该实现方式的方法包括：

401、消息提供平台接收APP或APP更新包。

402、消息提供平台后端对接收的APP或APP更新包进行审核。

403、消息分发器建立少于终端业务平台数量的消息队列。

本实施例步骤401至步骤403的实现方式分别与图3中步骤301至步骤303的实现方式对应相同，唯一不同之处在于，步骤403中建立的消息队列的数量小于终端业务平台的数量。例如为5个终端业务平台建立3个消息队列，或者为6个终端业务平台建立2个消息队列。本实施例不对消息队列与终端业务平台之间的数量差异进行限制，极端情况下，可以为任意数量的终端业务平台仅建立一个消息队列。

404、消息分发器建立消息队列与部分终端业务平台之间一一对应的绑定连接。

由于消息队列的数量有限，因此只能通过有限的消息队列先为部分终端业务平台进行消息分发。对应的，消息队列需要先与这部分终端业务平台建立绑定连接。本实施例中，部分终端业务平台的数量由消息队列的数量来决定，例如当为7个终端业务平台建立4个消息队列时，首先将4个终端业务平台绑定到4个消息队列上。

本实施例中首批终端业务平台的选定规则可以由按照终端标识规律决定，例如标识排序顺序，标识种类对应的优先级等；也可以由终端业务平台对用户服务时延的容忍度决定；亦或者可以由运维人员根据实际运营策略人工决定，本实施例对此不作限制。

本步骤的实现方式与图3步骤404的实现方式相同，此处不再赘述。

405、在APP上线或APP更新审核通过后，消息提供平台生成APP消息，并向消息分发器推送APP消息，由消息分发器将APP消息进行复制，并分别写入到与消息分发器连接的各个消息队列中。

406、终端业务平台对对应的消息队列进行监听。

407、终端业务平台通过APP消息中的APP标识请求APP的APK信息。

408、终端业务平台根据APK信息对APP进行上线或更新。

步骤405至步骤408的实现方式分别与图3中步骤305至步骤308的实现方式对应相同，不同之处在于，本实施例截止到步骤408仅实现的首批终端业务平台对APP消息的接收和处理，而剩余终端业务平台对APP消息的接收和处理，则由步骤409起始的后续步骤实现。

409、在终端业务平台从其连接的消息队列中获取APP消息之后，消息分发器解除终端业务平台与消息队列的绑定连接。

410、消息分发器建立其他终端业务平台与消息队列之间一一对应的绑定连接。

步骤409中所述的终端业务平台为首批与消息队列进行绑定并接收APP消息的终端业务平台，而步骤410中所述的其他终端业务平台则为剩余并即将与消息队列进行绑定连接的终端业务平台。在步骤409中，消息分发器可以通过msgget函数的逆向工程函数将在前绑定的终端业务平台的key值从消息队列中删除，由此解除首批终端业务平台与消息队列的绑定连接。需要说明的是，本实施例中绑定连接解除后，消息队列仍然存在，解除绑定关系不等同于释放消息队列。

本实施例中，步骤410的实现方式与步骤404的实现方式相同，此处不再赘述。

411、消息分发器再次复制APP消息，并向消息队列写入再次复制的APP消息，以使得其他终端业务平台通过消息队列获取再次复制的APP消息。

在消息队列完成与其余终端业务平台的绑定连接后，消息分发器按照步骤405的实现方式，对待分发的APP消息再次进行复制，然后将再次复制的多份相同的APP消息分别写入到各个消息队列中，以便其余终端业务平台进行接收和处理。

下面，结合上述图3或图4所示的方法，给出本发明实施例的一种应用场景。图5示出了一种集APP上传、APP审核、APP消息分发为一体的场景示意图。其中，该场景包括了如下几部分对象：

1、APP爬虫工具；

2、开发者开放平台；

3、TV应用商店平台；

4、游戏中心平台；

5、手机应用商店平台；

6、客户端；

7、智能设备应用商店平台；

8、车联网应用商店平台；

9、企业管理信息系统OMS；

10、qpid消息队列；

11、ka(king-arthur)；

12、弹性搜索引擎elastic-search；

13、重申缓存redis；

14、数据库。

其中，APP爬虫工具及开发者开放平台属于APP或APP更新包的来源，用于提供待上线的APP或APP更新包；TV应用商店平台、游戏中心平台、智能设备应用商店平台及车联网应用商店平台作为终端业务平台，用于通过消息队列接收APP消息；值得说明的是，图5中的客户端存在日志分析及数据统计需求，开发者开放平台则存在APP上线信息反馈的需求，而elastic-search则需要同步最新的APK信息以便用户搜索，因此与终端业务平台类似，上述三者也扮演接收APP消息的角色；qpid消息队列包含消息分发器，用于建立消息队列、分配key值、写入APP消息；ka与redis及数据库进行交互，用于为终端业务平台提供APP的APK信息；OMS负责整体运维管理。

在图5所示的场景中，APP爬虫工具或开发者开放平台上报APP或APP更新包进行审核。待审核通过后，qpid消息队列建立8个消息队列，分别对应开发者开放平台、TV应用商店平台等8个终端业务平台。图6为消息队列与终端业务平台对接的示意图，在图6中，每一对消息队列与终端业务平台的组合都分配有一个key值。通过各自的消息队列，终端业务平台接收消息分发器通过消息队列分发的APP消息。

进一步的，结合图5所示场景，本发明的另一实施例对APP消息的具体形式进行示例性说明。如图7所示，APP消息的结构化字段包括：程序包名(Package Name)字段、操作类型(opType)字段、业务平台(Platform)字段及版本号(Verson Code)字段。其中，程序包名字段用于记录APP名称；操作类型字段记录的信息包括Update及Create，其中，Update代表APP更新，Create代表新APP上线；业务平台字段记录终端业务平台的平台标识；版本号字段记录APP的最新版本。

终端业务平台在接收到如图7所示的一条APP消息后，对其进行解析，通过业务平台字段中记录的平台标识判断是否保留该条APP消息。在图7中，业务平台字段记录有“gc1”、“gc2”及“gc3”三个平台标识，表示该条APP消息应当被游戏中心平台1、游戏中心平台2及游戏中心平台3三个终端业务平台接收。可选的，如果业务平台字段为空，则表示该条APP消息应当被所有终端业务平台接收。在获得应当保留的APP消息之后，终端业务平台从该消息的程序包名字段和版本号字段中读取APP的名称及版本号，并将名称及版本号的组合作为APP标识上报给消息提供平台，可选的，版本号字段为空代表该APP为当前最新版本。分发平台接收到APP的名称及版本号后查找对应的APP并通过ka将该APP的APK信息发送给终端业务平台。其中，ka可以在终端业务平台上报APP标识时向数据库请求获取APK信息，也可以通过redis对请求过的APK信息进行缓存，以便在后续反馈APK信息时减少访问数据库的次数。终端业务平台在接收到APK信息后将其上线到应用商店中，完成APP上线流程。

在本实施例中，APP消息可以使用不同的格式，但较为优选的，应当将APP消息设定为jason格式。与传统的消息格式(例如二进制格式)相比，jason格式是一种轻量化的数据交换格式，具有可视化特点，易于编程人员查看和编写。同时相对二进制等传统数据交换格式而言，jason格式无需进行编译转换，易于机器解析。示例性的，一种jason格式的APP消息形式如下：

{＂PackageName＂:＂wb.gc.zzx.axc＂,＂opType＂:＂Update＂,＂Platform＂:＂gc1＂,＂VersonCode＂:＂1.0＂}

进一步的，本发明另一实施例还提供了一种消息分发器。如图8所示，该消息分发器包括：接收单元81、复制单元82和写入单元83；其中，

接收单元81，用于接收消息提供平台发送的应用程序APP消息，APP消息中包含APP上线或APP更新的索引信息；

复制单元82，用于将接收单元81接收的APP消息进行复制；

写入单元83，用于向每一个与消息分发器连接的消息队列写入一份复制单元82复制的APP消息，消息队列为数据传输通道，一端与终端业务平台连接，另一端与消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取APP消息，进而根据索引信息确定APP消息是否为各终端业务平台自身所需的APP消息。

进一步的，如图9所示，该消息分发器还包括：

建立单元84，用于在复制单元82将接收的APP消息进行复制，并由写入单元83向每一个与消息分发器连接的消息队列写入一份复制单元82复制的APP消息之前，建立终端业务平台与消息队列之间一一对应的绑定连接，每个消息队列具有区别其他消息队列的唯一标识。

进一步的，建立单元84用于初始化建立与消息队列的绑定连接，添加建立与消息队列的绑定连接。

进一步的，复制单元82用于通过扇出模式将APP消息扇出为多份相同的APP消息，其中，扇出的APP消息的份数与消息队列的数量相同；

写入单元83，用于分别向每一个与消息分发器连接的消息队列写入一份APP消息。

进一步的，如图9所示，消息分发器还包括：

解除单元85，用于在终端业务平台从其连接的消息队列中获取APP消息之后，解除建立单元84建立的终端业务平台与消息队列的绑定连接；

建立单元84，用于建立其他终端业务平台与消息队列之间一一对应的绑定连接。

进一步的，复制单元82，用于在建立单元84建立其他终端业务平台与消息队列之间一一对应的绑定连接之后，再次复制APP消息；

写入单元83，用于向消息队列写入复制单元82再次复制的APP消息，以使得其他终端业务平台通过消息队列获取再次复制的APP消息。

进一步的，本发明另一实施例还提供了一种终端业务平台。如图10所示，该终端业务平台包括：监听单元101、读取单元102、确定单元103及处理单元104；其中，

监听单元101，用于监听其对应的消息队列中是否写入APP消息，消息队列为数据传输通道，一端与终端业务平台连接，另一端与消息分发器连接；APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息；

读取单元102，用于当监听单元101监听到其连接的消息队列中写入APP消息时，从消息队列中将APP消息读出；

确定单元103，用于根据索引信息确定读取单元102读取的APP消息是否为终端业务平台自身所需的APP消息；

处理单元104，用于当确定单元103确定为终端业务平台自身所需的APP消息时，按照终端业务平台预定处理流程创建或更新APP消息对应的APP。

进一步的，监听单元101监听到的APP信息中的索引信息包括APP标识信息和终端业务平台标识信息。

进一步的，如图11所示，确定单元103包括：

解析模块1031，用于对APP消息进行解析，获取APP消息中包含的索引信息，索引信息中包含APP标识信息和终端业务平台标识信息；

比对模块1032，用于将解析模块1031获取的终端业务平台标识信息与终端业务平台自身的标识信息进行对比；

确定模块1033，用于当比对模块1032比对两者一致时，确定APP消息为终端业务平台自身所需的APP消息，当比对模块1032比对两者不一致时，确定APP消息不为终端业务平台自身所需的APP消息。

进一步的，如图11所示，处理单元104包括：

请求模块1041，用于按照终端业务平台预定处理流程请求获取APP标识信息对应的APP安卓程序包APK信息；

处理模块1042，用于根据请求模块1041请求的APK信息，对APP标识信息对应的APP进行上线或者更新。

进一步的，处理单元104，用于当确定单元103确定不为终端业务平台自身所需的APP消息时，将APP消息丢掉。

进一步的，本发明另一实施例还提供了一种消息分发系统，如图12所示，该系统包括：消息提供平台121、消息分发器122、消息队列123和终端业务平台124；

其中，消息分发器122为上述图8或图9所示的消息分发器，终端业务平台124为上述图10或图11所示的终端业务平台；

消息提供平台121，用于产生APP消息，并将APP消息发送给消息分发器122；

每个消息队列123具有区别其他消息队列的唯一标识。

本实施例中，为每一个终端业务平台建立一个对应的消息队列，当消息提供平台需要发送APP消息时，直接由消息分发器向每一个终端业务平台对应的消息队列发送一份相同的APP消息，该种向消息队列发送APP消息的方式属于无区分发送，只要消息队列与消息分发器连接，APP消息就会发送到连接的消息队列中，该种消息分发的方式无需关心分发对象、分发方式等具体策略，简单易操作，避免了消息提供平台发送APP消息的复杂逻辑。并且，基于消息队列具有消息持久化保存的特性，APP消息发送到消息队列中之后会暂存在各个消息队列中，各终端业务平台会监听与其对应的消息队列，当监听到消息队列中有APP消息时，才将APP消息从消息队列中取出；所以当APP消息发出但是对应的终端业务平台不正常工作无法成功接收APP消息时，无需部署消息重发、消息丢弃等复杂的策略。另外，各终端业务平台在监听到各自对应的消息队列中有APP消息时，会对APP消息进行一个识别，只对所述终端业务平台所需的APP消息进行处理，这样对APP消息的识别和分类放在终端业务平台进行，在一定程度上降低了消息提供平台分发消息的逻辑。综上，与现有技术中的同步分发机制相比，本发明能够大大简化分发平台侧的分发逻辑，实现分发平台的轻量化设计。

本实施例中，APP消息发送给各终端业务平台对应的消息队列后，各终端业务平台从各自对应的消息队列中接收APP消息的过程是相互独立的，终端业务平台可以根据自身的实际情况灵活确定消息接收的时间，各终端业务平台无需同时开始或结束APP消息的接收。同时，由于终端业务平台是基于各自的消息队列接收APP消息的，因此当某个或某几个终端业务平台处于不可用状态时，也不会影响其他终端业务平台对APP消息的正常接收。本质上，消息接收的独立性和抗干扰性有了很大提升。

此外，本方法还具有以下几点优势：

1、异步特性：现有技术中分发平台采用同步机制分发APP消息，同步分发机制可以有两种具体的实现方式，第一，建立多线程同时向多个终端业务平台发送消息；第二，依次向各个终端业务平台顺序发送消息。当系统中的终端业务平台数量增加时，对于前者方式，需要增加分发平台的并发数资源开销，对于后者方式，则会延长消息分发的时间。而在本方法中，通过简单的方法调用即可实现消息队列的建立，并且多个消息队列的消息分发并行进行，无论终端业务平台的数量如何增加，消息提供平台仅需要传递一次APP消息即可，相对现有技术而言，能够大大降低并发数资源开销并缩短分发耗时。

2、灵活性：现有技术中，如果增减终端业务平台的数量，则需要改动分发平台侧的分发逻辑，实现起来复杂耗时，消息分发具有一定的滞后性。而在本发明中，仅通过简单的方法调用就可以实现消息队列的建立和释放，相对现有技术而言，本方法能够灵活便捷的增减终端业务平台的数量，保障APP消息的及时分发。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (24)

1.一种消息分发的方法，其特征在于，包括：

消息分发器接收消息提供平台发送的应用程序APP消息，所述APP消息中包含APP上线或APP更新的索引信息；

将接收的所述APP消息进行复制，并向每一个与所述消息分发器连接的消息队列写入一份所述APP消息，所述消息队列为数据传输通道，一端与终端业务平台连接，另一端与所述消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取所述APP消息，进而根据所述索引信息确定所述APP消息是否为各终端业务平台自身所需的APP消息。

2.根据权利要求1所述的方法，其特征在于，在将接收的所述APP消息进行复制，并向每一个与所述消息分发器连接的消息队列写入一份所述APP消息之前，还包括：

建立终端业务平台与所述消息队列之间一一对应的绑定连接，每个消息队列具有区别其他消息队列的唯一标识。

3.根据权利要求2所述的方法，其特征在于，所述建立终端业务平台与所述消息队列之间一一对应的绑定连接包括：

初始化建立与所述消息队列的绑定连接；

添加建立与所述消息队列的绑定连接。

4.根据权利要求2所述的方法，其特征在于，所述将接收的所述APP消息进行复制，并向每一个与所述消息分发器连接的消息队列写入所述APP消息包括：

通过扇出模式将所述APP消息扇出为多份相同的APP消息，其中，扇出的APP消息的份数与消息队列的数量相同；

分别向每一个与所述消息分发器连接的消息队列写入一份APP消息。

5.根据权利要求2所述的方法，其特征在于，在终端业务平台从其连接的消息队列中获取所述APP消息之后，还包括：

解除所述终端业务平台与所述消息队列的绑定连接；

建立其他终端业务平台与所述消息队列之间一一对应的绑定连接。

6.根据权利要求5所述的方法，其特征在于，在所述建立其他终端业务平台与所述消息队列之间一一对应的绑定连接之后，还包括：

再次复制所述APP消息，并向所述消息队列写入再次复制的所述APP消息，以使得所述其他终端业务平台通过所述消息队列获取所述再次复制的所述APP消息。

7.根据权利要求1-6中任意项所述的方法，其特征在于，所述索引信息包括APP标识信息和终端业务平台标识信息。

8.一种消息分发的方法，其特征在于，包括：

终端业务平台监听其对应的消息队列中是否写入APP消息，所述消息队列为数据传输通道，一端与所述终端业务平台连接，另一端与消息分发器连接；所述APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与所述消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息；

若监听到其连接的消息队列中写入APP消息，则从所述消息队列中将所述APP消息读出，并根据所述索引信息确定所述APP消息是否为所述终端业务平台自身所需的APP消息；

若确定为所述终端业务平台自身所需的APP消息，则按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP。

9.根据权利要求8所述的方法，其特征在于，所述索引信息包括APP标识信息和终端业务平台标识信息。

10.根据权利要求9所述的方法，其特征在于，所述根据所述索引信息确定所述APP消息是否为所述终端业务平台自身所需的APP消息包括：

对所述APP消息进行解析，获取所述APP消息中包含的索引信息，所述索引信息中包含APP标识信息和终端业务平台标识信息；

将获取的终端业务平台标识信息与所述终端业务平台自身的标识信息进行对比；

若两者一致，则确定所述APP消息为所述终端业务平台自身所需的APP消息；

若两者不一致，则确定所述APP消息不为所述终端业务平台自身所需的APP消息。

11.根据权利要求10所述的方法，其特征在于，所述按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP包括：

按照所述终端业务平台预定处理流程请求获取所述APP标识信息对应的APP安卓程序包APK信息；

根据所述APK信息，对所述APP标识信息对应的APP进行上线或者更新。

12.根据权利要求8-11中任一项所述的方法，其特征在于，还包括：

若确定不为所述终端业务平台自身所需的APP消息，则将所述APP消息丢掉。

13.一种消息分发器，其特征在于，包括：

接收单元，用于接收消息提供平台发送的应用程序APP消息，所述APP消息中包含APP上线或APP更新的索引信息；

复制单元，用于将所述接收单元接收的所述APP消息进行复制；

写入单元，用于向每一个与所述消息分发器连接的消息队列写入一份所述复制单元复制的所述APP消息，所述消息队列为数据传输通道，一端与终端业务平台连接，另一端与所述消息分发器连接，每个终端业务平台分别从其各自连接的消息队列中获取所述APP消息，进而根据所述索引信息确定所述APP消息是否为各终端业务平台自身所需的APP消息。

14.根据权利要求13所述的消息分发器，其特征在于，所述消息分发器还包括：

建立单元，用于在所述复制单元将接收的所述APP消息进行复制，并由所述写入单元向每一个与所述消息分发器连接的消息队列写入一份所述复制单元复制的所述APP消息之前，建立终端业务平台与所述消息队列之间一一对应的绑定连接，每个消息队列具有区别其他消息队列的唯一标识。

15.根据权利要求14所述的消息分发器，其特征在于，所述建立单元用于初始化建立与所述消息队列的绑定连接，添加建立与所述消息队列的绑定连接。

16.根据权利要求14所述的消息分发器，其特征在于，所述复制单元用于通过扇出模式将所述APP消息扇出为多份相同的APP消息，其中，扇出的APP消息的份数与消息队列的数量相同；

所述写入单元，用于分别向每一个与所述消息分发器连接的消息队列写入一份APP消息。

17.根据权利要求14所述的消息分发器，其特征在于，所述消息分发器还包括：

解除单元，用于在终端业务平台从其连接的消息队列中获取所述APP消息之后，解除所述建立单元建立的所述终端业务平台与所述消息队列的绑定连接；

所述建立单元，用于建立其他终端业务平台与所述消息队列之间一一对应的绑定连接。

18.根据权利要求17所述的消息分发器，其特征在于，所述复制单元，用于在所述建立单元建立其他终端业务平台与所述消息队列之间一一对应的绑定连接之后，再次复制所述APP消息；

所述写入单元，用于向所述消息队列写入所述复制单元再次复制的所述APP消息，以使得所述其他终端业务平台通过所述消息队列获取所述再次复制的所述APP消息。

19.一种终端业务平台，其特征在于，包括：

监听单元，用于监听其对应的消息队列中是否写入APP消息，所述消息队列为数据传输通道，一端与所述终端业务平台连接，另一端与消息分发器连接；所述APP消息为消息分发器在接收到消息提供平台发送的APP消息后，经复制向每一个与所述消息分发器连接的消息队列写入一份的APP消息，其中包含APP上线或APP更新的索引信息；

读取单元，用于当所述监听单元监听到其连接的消息队列中写入APP消息时，从所述消息队列中将所述APP消息读出；

确定单元，用于根据所述索引信息确定所述读取单元读取的所述APP消息是否为所述终端业务平台自身所需的APP消息；

处理单元，用于当所述确定单元确定为所述终端业务平台自身所需的APP消息时，按照所述终端业务平台预定处理流程创建或更新所述APP消息对应的APP。

20.根据权利要求19所述的终端业务平台，其特征在于，所述监听单元监听到的所述APP信息中的所述索引信息包括APP标识信息和终端业务平台标识信息。

21.根据权利要求20所述的终端业务平台，其特征在于，所述确定单元包括：

解析模块，用于对所述APP消息进行解析，获取所述APP消息中包含的索引信息，所述索引信息中包含APP标识信息和终端业务平台标识信息；

比对模块，用于将所述解析模块获取的终端业务平台标识信息与所述终端业务平台自身的标识信息进行对比；

确定模块，用于当所述比对模块比对两者一致时，确定所述APP消息为所述终端业务平台自身所需的APP消息，当所述比对模块比对两者不一致时，确定所述APP消息不为所述终端业务平台自身所需的APP消息。

22.根据权利要求21所述的终端业务平台，其特征在于，所述处理单元包括：

请求模块，用于按照所述终端业务平台预定处理流程请求获取所述APP标识信息对应的APP安卓程序包APK信息；

处理模块，用于根据所述请求模块请求的所述APK信息，对所述APP标识信息对应的APP进行上线或者更新。

23.根据权利要求19-22中任一项所述的终端业务平台，其特征在于，所述处理单元，用于当所述确定单元确定不为所述终端业务平台自身所需的APP消息时，将所述APP消息丢掉。

24.一种消息分发系统，其特征在于，包括：消息提供平台、如权利要求13-18中任一项所述的消息分发器、消息队列和如权利要求19-23中任一项所述的终端业务平台；

所述消息提供平台，用于产生APP消息，并将所述APP消息发送给所述消息分发器；

每个消息队列具有区别其他消息队列的唯一标识。