CN106453613A - 消息重发方法及装置 - Google Patents

Abstract

本公开是关于一种消息重发方法及装置，包括：步骤S101服务器向终端发送至少一条应用消息，并对每条应用消息从发送时刻开始计时；步骤S102服务器判断第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；步骤S103若服务器需要重发至少一条应用消息时，则对需要重发的应用消息继续执行步骤S101至步骤S103；否则，则服务器停止重发，从而提高应用消息重发效率。

Description

消息重发方法及装置

技术领域

本公开涉及通信领域，尤其涉及一种消息重发方法及装置。

背景技术

目前，随着计算机软件技术的发展，终端中的应用(Application，简称APP)越来越多，从而丰富用户的日常生活。

APP对应的运营商服务器经常需要向用户推送各种应用消息，例如：更新消息、优惠消息等。但是由于移动网络环境的影响，可能会存在有些消息无法发送至用户，从而降低通信可靠性，为了提高消息的到达率，服务器可以采取重发消息的方式，通常服务器推送的消息数量庞大，因此如何重发应用消息至关重要。

发明内容

为克服相关技术中存在的问题，本公开提供一种消息重发方法及装置。所述技术方案如下：

根据本公开实施例的第一方面，提供一种消息重发方法，包括：

步骤S101：服务器向至少一个终端发送至少一条应用消息，并对至少一条应用消息中的每条应用消息从发送时刻开始计时；

步骤S102：服务器判断第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

步骤S103：若服务器需要重发至少一条应用消息时，则对需要重发的至少一条应用消息继续执行步骤S101至步骤S103；否则，则服务器停止重发。

本公开的实施例提供的技术方案可以包括以下有益效果：现有技术中服务器不区分应用消息的先后发送顺序，周期性的或者非周期性的要对所有应用消息的计时时间进行判断，当任一条应用消息的计时时间达到预设时间，则判断是否重发该应用消息。本公开实施例中，由于当服务器确定第一条应用消息的计时时间达到第一预设时间时，才继续判断第二条应用消息的计时时间是否达到第一预设时间，依次类推，当服务器确定倒数第二条应用消息的计时时间达到第一预设时间时，才继续判断倒数第一条应用消息的计时时间是否达到第一预设时间，从而可以提高重发效率。

可选地，还包括：服务器将至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；

相应的，服务器向至少一个终端发送至少一条应用消息，包括：

服务器按照第一队列从对头到对尾的顺序依次发送至少一条应用消息。

可选地，还包括：服务器将需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；

相应的，服务器向至少一个终端发送所述需要重发的至少一条应用消息，包括：

服务器按照所述第二队列从对头到对尾的顺序依次发送所述需要重发的至少一条应用消息。

可选地，服务器判断是否要重发第一条应用消息，包括：

服务器判断是否接收到第一条应用消息对应的确认Ack消息；

若服务器未接收到第一条应用消息对应的确认Ack消息，则服务器判断第一条应用消息的计时时间是否小于第二预设时间，其中第二预设时间大于第一预设时间；或者，判断第一条应用消息的重发次数是否小于预设次数。

通过该方法可以有效判断是否要重发第一条应用消息。

可选地，服务器向至少一个终端发送至少一条应用消息之前，还包括：

服务器生成每条应用消息的序列号，将序列号携带至所述每条应用消息中，序列号包括：每条应用消息的待发送时间和待发送时间内服务器为每条应用消息设置的编号。

可选地，判断是否接收到第一条应用消息对应的确认Ack消息之前，还包括：

服务器接收至少一个终端发送的至少一个确认Ack消息；

服务器将所述至少一个确认Ack消息以哈希表的形式存储至本地数据库中，哈希表的每一项包括：每条应用消息对应的序列号和用于表示每条应用消息是否被成功接收的标识信息；

相应的，判断是否接收到第一条应用消息对应的确认Ack消息，包括：

服务器查询哈希表判断是否接收到第一条应用消息对应的确认Ack消息。

通过哈希表存储方式可以提高查询效率，进而提高重发效率。

可选地，判断是否接收到第一条应用消息对应的确认Ack消息之前，还包括：

服务器接收至少一个终端发送的至少一个确认Ack消息；

服务器将至少一个确认Ack消息以位图的形式存储至本地数据库中，位图的每一项包括：用于表示每条应用消息是否被成功接收的标识信息；

相应的，判断是否接收到第一条应用消息对应的确认Ack消息，包括：

服务器查询位图判断是否接收到第一条应用消息对应的确认Ack消息。

通过位图方式可以达到节省内存空间的目的。

下面将介绍发明实施例提供一种消息重发装置，其中装置部分与上述消息重发方法对应，对应技术效果相同，在此不再赘述。

根据本公开实施例的第二方面，提供一种消息重发装置，包括：

发送模块，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对至少一条应用消息中的每条应用消息从发送时刻开始计时；

判断模块，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

发送模块，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则发送模块和判断模块继续执行步骤S101至步骤S103；否则，则发送模块停止重发。

可选地，还包括：第一存储模块，被配置为将至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；

相应的，发送模块，具体被配置为按照第一队列从对头到对尾的顺序依次发送至少一条应用消息。

可选地，还包括：第二存储模块，被配置为将需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；

相应的，发送模块，具体被配置为按照第二队列从对头到对尾的顺序依次发送所述需要重发的至少一条应用消息。

可选地，判断模块具体被配置为：判断是否接收到所述第一条应用消息对应的确认Ack消息；

若判断未接收到所述第一条应用消息对应的确认Ack消息，则判断所述第一条应用消息的计时时间是否小于第二预设时间，其中所述第二预设时间大于所述第一预设时间；或者，判断所述第一条应用消息的重发次数是否小于预设次数。

可选地，还包括：生成模块，被配置为生成所述每条应用消息的序列号，将所述序列号携带至所述每条应用消息中，所述序列号包括：所述每条应用消息的待发送时间和所述待发送时间内所述装置为所述每条应用消息设置的编号。

可选地，还包括：第一接收模块，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第三存储模块，被位置为将所述至少一个确认Ack消息以哈希表的形式存储至本地数据库中，所述哈希表的每一项包括：所述每条应用消息对应的序列号和用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块，具体被配置为查询所述哈希表判断是否接收到所述第一条应用消息对应的确认Ack消息。

可选地，还包括：第二接收模块，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第四存储模块，被配置为将所述至少一个确认Ack消息以位图的形式存储至本地数据库中，所述位图的每一项包括：用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块，具体被配置为查询所述位图判断是否接收到所述第一条应用消息对应的确认Ack消息。

根据本公开实施例的第三方面，提供一种消息重发装置，包括：处理器、发送器和用于存储所述处理器的可执行指令的存储器；

其中，发送器，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

处理器，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

发送器，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则所述发送器和所述处理器继续执行步骤S101至步骤S103；否则，则所述发送器停止重发。

本公开的实施例提供的技术方案可以包括以下有益效果：步骤S101：服务器向至少一个终端发送至少一条应用消息，并对至少一条应用消息中的每条应用消息从发送时刻开始计时；步骤S102：服务器判断第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；步骤S103：若服务器需要重发至少一条应用消息时，则对需要重发的至少一条应用消息继续执行步骤S101至步骤S103；否则，则服务器停止重发，从而提高应用消息重发效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种消息重发方法的流程图；

图2A和图2B是根据一示例性实施例示出的队列示意图；

图3是根据另一示例性实施例示出的一种消息重发方法的流程图；

图4是根据再一示例性实施例示出的一种消息重发方法的流程图；

图5是根据又一示例性实施例示出的一种消息重发方法的流程图；

图6是根据一示例性实施例示出的一种消息重发装置的框图；

图7是根据另一示例性实施例示出的一种消息重发装置的框图；

图8是根据另一示例性实施例示出的一种用于消息重发装置的框图；

图9是根据一示例性实施例示出的一种用于消息重发装置900的框图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种消息重发方法的流程图，本实施例以该消息重发方法应用于服务器中来举例说明，该方法的应用场景为：服务器向至少一个终端发送应用消息的场景，该消息重发方法可以包括如下几个步骤：

在步骤S101中：服务器向至少一个终端发送至少一条应用消息，并对至少一条应用消息中的每条应用消息从发送时刻开始计时；

其中，该服务器为APP对应的服务器，该应用消息可以是更新消息、优惠消息等，该应用消息中携带用于唯一标识该应用消息的序列号，当终端向服务器发送该应用消息对应的确认(Acknoledge，简称Ack)消息时，则该Ack消息中也携带该序列号，以表示该Ack消息为该应用消息对应的Ack消息。

在步骤S102中：服务器判断第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

所谓第一条应用消息是指按照时间顺序，至少一条应用消息中第一个被服务器发送的应用消息，所述第一预设时间根据应用消息到达终端的时间以及Ack消息到达服务器的时间和设置，该第一预设时间可以是30秒(Second，简称S)，60s等，本公开实施例对此不做限制。当服务器确定第一条应用消息的计时时间达到第一预设时间时，一方面服务器判断是否要重发第一条应用消息，另一方面将第二条应用消息作为新的第一条应用消息，继续判断新的第一条应用消息的计时时间是否达到所述第一预设时间，也就是说，服务器确定第一条应用消息的计时时间还未达到第一预设时间时，服务器不判断第二条应用消息的计时时间是否达到第一预设时间，其中这样做的原因是：实际上终端性能通常相同，与服务器之间的距离也基本相同，由于第一条应用消息的发送时刻早于第二条应用消息的发送时刻，因此当第一条应用消息的计时时间还未达到第一预设时间，通常第二条应用消息的计时时间更不会达到第一预设时间。

依次类推，当服务器确定第二条应用消息的计时时间达到第一预设时间时，服务器判断是否要重发第二条应用消息，继续判断第三条应用消息的计时时间是否达到第一预设时间，当服务器确定第三条应用消息的计时时间达到第一预设时间时，服务器判断是否要重发第三条应用消息，直至判断完是否要重发最后一条应用消息为止。

在步骤S103中：若服务器需要重发至少一条应用消息时，则对需要重发的至少一条应用消息继续执行步骤S101至步骤S103；否则，则服务器停止重发。

也就是说，将需要重发的至少一条应用消息作为步骤S101中的至少一条应用消息，则对需要重发的至少一条应用消息继续执行步骤S101至步骤S103；否则，则服务器停止重发。

示例性的：服务器向至少一个终端发送应用消息1、应用消息2和应用消息3，并对三条应用消息中的每条应用消息从发送时刻开始计时；服务器判断第一条应用消息，即应用消息1的计时时间，如果该计时时间达到第一预设时间，则服务器判断是否要重发应用消息1，并判断应用消息2的计时时间是否达到第一预设时间，若是，则判断是否要重发应用消息2，并继续判断应用消息3的计时时间是否达到第一预设时间，若是，则判断是否要重发应用消息3，假设第一轮结束后，服务器确定要重发应用消息1和应用消息2，则继续对应用消息1和应用消息2从重发时刻开始计时，服务器判断应用消息1的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发应用消息1，并且判断应用消息2的计时时间是否达到第一预设时间，若是，则服务器判断是否要重发应用消息2，若应用消息1和应用消息2都不需要重发了，则服务器停止重发应用消息。

现有技术中服务器不区分应用消息的先后发送顺序，周期性的或者非周期性的要对所有应用消息的计时时间进行判断，当任一条应用消息的计时时间达到预设时间，则判断是否重发该应用消息。本公开实施例中，由于当服务器确定第一条应用消息的计时时间达到第一预设时间时，才继续判断第二条应用消息的计时时间是否达到第一预设时间，依次类推，当服务器确定倒数第二条应用消息的计时时间达到第一预设时间时，才继续判断倒数第一条应用消息的计时时间是否达到第一预设时间，从而可以提高重发效率。

可选地，服务器将至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；相应的，所述服务器向至少一个终端发送至少一条应用消息，包括：所述服务器按照所述第一队列从对头到对尾的顺序依次发送所述至少一条应用消息。

可选地，服务器将需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；相应的，所述服务器向至少一个终端发送所述需要重发的至少一条应用消息，包括：服务器按照第二队列从对头到对尾的顺序依次发送需要重发的至少一条应用消息。

示例性的，图2A和图2B是根据一示例性实施例示出的队列示意图，如图2A所示，第一队列包括：从对头至对尾的应用消息1、应用消息2和应用消息3，基于该存储结构，服务器当然先发送应用消息1，再发送应用消息2，最后发送应用消息3；如图2B所示，假设应用消息1和应用消息2都需要重发，则按照发送顺序，将应用消息1排列在第二队列的对头，然后将应用消息2排列在应用消息1之后。

基于上述实施例的基础，进一步地，本公开实施例还提供如何判断是否要重发所述第一条应用消息，具体地，图3是根据另一示例性实施例示出的一种消息重发方法的流程图，本实施例以该消息重发方法应用于服务器中来举例说明，该方法的应用场景为：服务器向至少一个终端发送应用消息的场景，该消息重发方法可以包括如下几个步骤：

在步骤S301中：服务器判断是否接收到第一条应用消息对应的确认Ack消息；

在步骤S302中：若服务器未接收到第一条应用消息对应的确认Ack消息，则服务器判断第一条应用消息的计时时间是否小于第二预设时间，其中第二预设时间大于第一预设时间；或者，判断第一条应用消息的重发次数是否小于预设次数。

需要说明的是，上述仅说明了如何判断是否要重发第一条应用消息，可以采用同样的方法判断是否要重发第i条应用消息，其中i＝2，3……N，N为待发送应用消息的数目，N为大于或者等于1的正整数。

其中，服务器判断第一条应用消息的计时时间是否小于第二预设时间，一旦确定第一条应用消息的计时时间大于或者等于第二预设时间，则认为超时，这种情况下，服务器不再重发第一条应用消息；

或者，

服务器判断第一条应用消息的重发次数是否小于预设次数，一旦确定第一条应用消息的重发次数大于或者等于预设次数，这种情况下，服务器也不再重发第一条应用消息。

本公开实施例中，服务器通过第一条应用消息的计时时间是否小于第二预设时间，或者，判断第一条应用消息的重发次数是否小于预设次数来确认是否要重发第一条应用消息。

基于上述实施例的基础，可选地，在步骤S101之前，消息重发方法还包括：

服务器生成每条应用消息的序列号，将序列号携带至每条应用消息中，该序列号包括：每条应用消息的待发送时间和待发送时间内服务器为每条应用消息设置的编号。

通常服务器可以精确到毫秒的时间戳，也就是说所述每条应用消息的待发送时间的单位可以是毫秒，当然也可以是秒，本公开实施例对此不做限制。而待发送时间内服务器为每条应用消息设置的编号，以用于在同一个待发送时间下生成不同的序列号。

示例性的，假设应用消息1的待发送时间为：1455508709秒，543毫秒，表示待发送时间为：11:58:29.543，应用消息1对应的编号为50，通常编号是从0开始，因此编号50表示在待发送时间1455508709秒，543毫秒下生成的第51个序列号，如果待发送时间发生变化，则编号部分从0开始递增，本公开实施例对编号位数不限。

基于上述序列号的基础，本公开实施例进一步提供如何判断是否接收到所述第一条应用消息对应的确认Ack消息。

一种可选方式：图4是根据再一示例性实施例示出的一种消息重发方法的流程图，本实施例以该消息重发方法应用于服务器中来举例说明，该方法的应用场景为：服务器向至少一个终端发送应用消息的场景，该消息重发方法可以包括如下几个步骤：

在步骤S401中：服务器接收至少一个终端发送的至少一个确认Ack消息；

在步骤S402中：服务器将至少一个确认Ack消息以哈希表的形式存储至本地数据库中，该哈希表的每一项包括：每条应用消息对应的序列号和用于表示每条应用消息是否被成功接收的标识信息；

示例性的：如表1所示：

表1

关键字(Key)	145550870954350	145550870954351	145550870954352
				值(Value)	0	0	1

其中，每条应用消息对应的序列号作为关键字，0表示该条应用消息未被成功接收，1表示该条应用消息被成功接收。

在步骤S403中：服务器查询哈希表判断是否接收到第一条应用消息对应的确认Ack消息。

例如：查询序列号为145550870954350的应用消息未被成功接收，序列号为145550870954351的应用消息也未被成功接收，序列号为145550870954352的应用消息被成功接收。

另一种可选方式：图5是根据又一示例性实施例示出的一种消息重发方法的流程图，本实施例以该消息重发方法应用于服务器中来举例说明，该方法的应用场景为：服务器向至少一个终端发送应用消息的场景，该消息重发方法可以包括如下几个步骤：

在步骤S501中：服务器接收至少一个终端发送的至少一个确认Ack消息；

在步骤S502中：服务器将至少一个确认Ack消息以位图的形式存储至本地数据库中，该位图的每一项包括：用于表示每条应用消息是否被成功接收的标识信息；

在步骤S503中：服务器查询位图判断是否接收到第一条应用消息对应的确认Ack消息。

具体的，由于服务器向终端发送的应用消息数量庞大，因此为了避免内存占用过高的问题，并保证服务器确定终端是否接收到Ack消息的速度，服务器使用位图bitmap的数据结构记录Ack消息。

一种可选方式，具有相同的待发送时间的应用消息对应同一个位图，标识信息按照每条应用消息对应的编号顺序排列在位图中，例如：结合表1所示，应用消息1的序列号为145550870954350，待发送时间为1455508709543，编号为50，应用消息2的序列号为145550870954351，待发送时间为1455508709543，编号为51，应用消息3的序列号为145550870954352，待发送时间为1455508709543，编号为52，因此应用消息1、应用消息2和应用消息3对应同一个位图，它们的标识信息分别位于位图的第51、52和53个位置。

另一种可选方式，将具有相同的秒数的应用消息对应同一个位图，应用消息的毫秒数和编号决定它们对应的标识信息在位图中的位置。例如：上述应用消息1、应用消息2和应用消息3对应同一个位图，它们的标识信息分别位于位图的第54351、54352和54353个位置。

需要说明的是；位图中的每一个比特位可以存储一个0或1的标识信息，通过偏移量offset指示不同的比特位，其中偏移量从0开始计，假设位图中偏移量为0的比特位被置为1，其它位置均未设置标识信息，则位图的存储即为1，如果继续设置偏移量为5的比特位为1，并且设置偏移量为6的比特位为1，则该位图的存储即为1000011。因此位图存储占用的空间是和比特位为1的最大偏移量相关，假设该最大偏移量为N，则存储即占用N+1个比特位，即(N+1)/8个字节、(N+1)/8192个千字节。

假设服务器在500秒内推送了1000万条应用消息，则平均每毫秒推送20条应用消息，应用消息偏置量的长度平均为5位数，假设在第1455508709秒的999毫秒推送了20条消息，则该偏置量即为99920，假设该偏置量为第1455508709秒内所有消息中的最大偏置量，那么这该位图将占用12千字节的内存空间。

而在redis数据库中，使用位图方式存储1000万条应用消息对应的标识消息，只占用16兆字节的内存空间，为不使用位图方式的五十分之一，因此，位图存储方式可以节省内存空间。

本公开实施例中，提供了存储应用消息对应标识信息的两种方式，一种为哈希表方式，另一种是位图方式，通过哈希表存储方式可以提高查询效率，进而提高重发效率，通过位图方式可以达到节省内存空间的目的。

图6是根据一示例性实施例示出的一种消息重发装置的框图，该消息重发装置可以通过软件、硬件或者两者的结合实现成为服务器的部分或者全部。所述装置的应用场景为：该消息重发装置向至少一个终端发送应用消息的场景，其中该装置包括：

发送模块61，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

判断模块62，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

发送模块61，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则发送模块61和判断模块62继续执行步骤S101至步骤S103；否则，则发送模块61停止重发。也就是说，当需要重发至少一条应用消息时，则发送模块61继续执行步骤S101，然后判断模块62继续执行步骤102，发送模块61继续执行步骤S103，否则，则发送模块61停止重发。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

基于上一实施例的基础，进一步地，图7是根据另一示例性实施例示出的一种消息重发装置的框图，该消息重发装置可以通过软件、硬件或者两者的结合实现成为服务器的部分或者全部。所述装置的应用场景为：该消息重发装置向至少一个终端发送应用消息的场景，其中该装置还包括：

第一存储模块63，被配置为将所述至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；

相应的，所述发送模块61，具体被配置为按照所述第一队列从对头到对尾的顺序依次发送所述至少一条应用消息。

可选地，还包括：第二存储模块64，被配置为将所述需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；

相应的，所述发送模块61，具体被配置为按照所述第二队列从对头到对尾的顺序依次发送所述需要重发的至少一条应用消息。

可选地，所述判断模块62具体被配置为：

判断是否接收到所述第一条应用消息对应的确认Ack消息；

若判断未接收到所述第一条应用消息对应的确认Ack消息，则判断所述第一条应用消息的计时时间是否小于第二预设时间，其中所述第二预设时间大于所述第一预设时间；或者，判断所述第一条应用消息的重发次数是否小于预设次数。

可选地，还包括生成模块65，被配置为生成所述每条应用消息的序列号，将所述序列号携带至所述每条应用消息中，所述序列号包括：所述每条应用消息的待发送时间和所述待发送时间内所述装置为所述每条应用消息设置的编号。

可选地，还包括：第一接收模块66，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第三存储模块67，被位置为将所述至少一个确认Ack消息以哈希表的形式存储至本地数据库中，所述哈希表的每一项包括：所述每条应用消息对应的序列号和用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块62，具体被配置为查询所述哈希表判断是否接收到所述第一条应用消息对应的确认Ack消息。

可选地，还包括：第二接收模块68，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第四存储模块69，被配置为将所述至少一个确认Ack消息以位图的形式存储至本地数据库中，所述位图的每一项包括：用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块62，具体被配置为查询所述位图判断是否接收到所述第一条应用消息对应的确认Ack消息。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图8是根据另一示例性实施例示出的一种用于消息重发装置的框图，该消息重发装置可以通过软件、硬件或者两者的结合实现成为服务器的部分或者全部。所述装置的应用场景为：该消息重发装置向至少一个终端发送应用消息的场景，其中该装置包括：处理器81、发送器82和用于存储所述处理器81的可执行指令的存储器83；

其中，所述发送器82，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

所述处理器81，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

所述发送器82，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则所述发送器和所述处理器继续执行步骤S101至步骤S103；否则，则所述发送器82停止重发。

关于上述实施例中的装置，其中各个器件执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9是根据一示例性实施例示出的一种用于消息重发装置900的框图，例如，装置900可以被提供为一服务器。参照图9，装置900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理组件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。

装置900还可以包括一个电源组件926被配置为执行装置900的电源管理，一个有线或无线网络接口950被配置为将装置900连接到网络，和一个输入输出(I/O)接口958。装置900可以操作基于存储在存储器932的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

输入输出(I/O)接口958，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始；处理组件922被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；输入输出(I/O)接口958，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则所述输入输出(I/O)接口958，和处理组件922继续执行步骤S101至步骤S103；否则，则输入输出(I/O)接口958停止重发。

关于上述实施例中的装置，其中各个器件执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims (15)

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

步骤S101：服务器向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

步骤S102：所述服务器判断第一条应用消息的计时时间是否达到第一预设时间，若是，则所述服务器判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则所述服务器判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

步骤S103：若所述服务器需要重发至少一条应用消息时，则对需要重发的至少一条应用消息继续执行步骤S101至步骤S103；否则，则所述服务器停止重发。

2.根据权利要求1所述的方法，其特征在于，还包括：

所述服务器将所述至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；

相应的，所述服务器向至少一个终端发送至少一条应用消息，包括：

所述服务器按照所述第一队列从对头到对尾的顺序依次发送所述至少一条应用消息。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

所述服务器将所述需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；

相应的，所述服务器向至少一个终端发送所述需要重发的至少一条应用消息，包括：

所述服务器按照所述第二队列从对头到对尾的顺序依次发送所述需要重发的至少一条应用消息。

4.根据权利要求1或2所述的方法，其特征在于，所述服务器判断是否要重发所述第一条应用消息，包括：

所述服务器判断是否接收到所述第一条应用消息对应的确认Ack消息；

若所述服务器未接收到所述第一条应用消息对应的确认Ack消息，则所述服务器判断所述第一条应用消息的计时时间是否小于第二预设时间，其中所述第二预设时间大于所述第一预设时间；或者，判断所述第一条应用消息的重发次数是否小于预设次数。

5.根据权利要求4所述的方法，其特征在于，所述服务器向至少一个终端发送至少一条应用消息之前，还包括：

所述服务器生成所述每条应用消息的序列号，将所述序列号携带至所述每条应用消息中，所述序列号包括：所述每条应用消息的待发送时间和所述待发送时间内所述服务器为所述每条应用消息设置的编号。

6.根据权利要求5所述的方法，其特征在于，所述判断是否接收到所述第一条应用消息对应的确认Ack消息之前，还包括：

所述服务器接收所述至少一个终端发送的至少一个确认Ack消息；

所述服务器将所述至少一个确认Ack消息以哈希表的形式存储至本地数据库中，所述哈希表的每一项包括：所述每条应用消息对应的序列号和用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断是否接收到所述第一条应用消息对应的确认Ack消息，包括：

所述服务器查询所述哈希表判断是否接收到所述第一条应用消息对应的确认Ack消息。

7.根据权利要求5所述的方法，其特征在于，所述判断是否接收到所述第一条应用消息对应的确认Ack消息之前，还包括：

所述服务器接收所述至少一个终端发送的至少一个确认Ack消息；

所述服务器将所述至少一个确认Ack消息以位图的形式存储至本地数据库中，所述位图的每一项包括：用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断是否接收到所述第一条应用消息对应的确认Ack消息，包括：

所述服务器查询所述位图判断是否接收到所述第一条应用消息对应的确认Ack消息。

8.一种消息重发装置，其特征在于，包括：

发送模块，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

判断模块，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

所述发送模块，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则所述发送模块和所述判断模块继续执行步骤S101至步骤S103；否则，则所述发送模块停止重发。

9.根据权利要求8所述的装置，其特征在于，还包括：

第一存储模块，被配置为将所述至少一条应用消息按照发送顺序依次存储至第一队列的对尾中；

相应的，所述发送模块，具体被配置为按照所述第一队列从对头到对尾的顺序依次发送所述至少一条应用消息。

10.根据权利要求8或9所述的装置，其特征在于，还包括：

第二存储模块，被配置为将所述需要重发的至少一条应用消息按照发送顺序依次存储至第二队列的对尾中；

相应的，所述发送模块，具体被配置为按照所述第二队列从对头到对尾的顺序依次发送所述需要重发的至少一条应用消息。

11.根据权利要求8或9所述的装置，其特征在于，所述判断模块具体被配置为：

判断是否接收到所述第一条应用消息对应的确认Ack消息；

若判断未接收到所述第一条应用消息对应的确认Ack消息，则判断所述第一条应用消息的计时时间是否小于第二预设时间，其中所述第二预设时间大于所述第一预设时间；或者，判断所述第一条应用消息的重发次数是否小于预设次数。

12.根据权利要求11所述的装置，其特征在于，还包括：

生成模块，被配置为生成所述每条应用消息的序列号，将所述序列号携带至所述每条应用消息中，所述序列号包括：所述每条应用消息的待发送时间和所述待发送时间内所述装置为所述每条应用消息设置的编号。

13.根据权利要求12所述的装置，其特征在于，还包括：

第一接收模块，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第三存储模块，被位置为将所述至少一个确认Ack消息以哈希表的形式存储至本地数据库中，所述哈希表的每一项包括：所述每条应用消息对应的序列号和用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块，具体被配置为查询所述哈希表判断是否接收到所述第一条应用消息对应的确认Ack消息。

14.根据权利要求12所述的装置，其特征在于，还包括：

第二接收模块，被配置为接收所述至少一个终端发送的至少一个确认Ack消息；

第四存储模块，被配置为将所述至少一个确认Ack消息以位图的形式存储至本地数据库中，所述位图的每一项包括：用于表示所述每条应用消息是否被成功接收的标识信息；

相应的，所述判断模块，具体被配置为查询所述位图判断是否接收到所述第一条应用消息对应的确认Ack消息。

15.一种消息重发装置，其特征在于，所述装置包括：处理器、发送器和用于存储所述处理器的可执行指令的存储器；

其中，所述发送器，被配置为执行步骤S101：向至少一个终端发送至少一条应用消息，并对所述至少一条应用消息中的每条应用消息从发送时刻开始计时；

所述处理器，被配置为执行步骤S102：判断第一条应用消息的计时时间是否达到第一预设时间，若是，则判断是否要重发所述第一条应用消息，并且将第二条应用消息作为新的第一条应用消息，继续判断所述新的第一条应用消息的计时时间是否达到所述第一预设时间，若是，则判断是否要重发所述新的第一条应用消息，直至判断完是否要重发最后一条应用消息为止；

所述发送器，还被配置为执行步骤S103：当需要重发至少一条应用消息时，则所述发送器和所述处理器继续执行步骤S101至步骤S103；否则，则所述发送器停止重发。