消息推送方法及装置与流程

本发明涉及通信技术领域，尤其涉及一种消息推送方法及装置。

背景技术：

kafka是一个消息系统，原本开发自LinkedIn，用作LinkedIn的活动流(Activity Stream)和运营数据处理管道(Pipeline)的基础。现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。

现有技术中，可将应用程序所请求的消息推送到kafka集群上，在正常情形下，推送都是可以成功完成的，但因运维需要或网络故障等特殊情况下，会出现推送失败，从而引起消息丢失，影响用户体验。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

技术实现要素：

本发明的主要目的在于提供一种消息推送方法及装置，旨在解决现有技术中由于特殊情况下消息推送失败引起消息丢弃的技术问题。

为实现上述目的，本发明提供一种消息推送方法，所述方法包括以下步骤：

将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息；

将所述待推送消息推送至目标集群；在所述待推送消息推送失败时，

将预设失败原因的待推送消息添加至所述消息队列中。

优选地，所述将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，具体包括：

计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息。

优选地，所述根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，具体包括：

将应用程序发送的实时消息作为第一待推送消息；

判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出预设数量的历史消息作为第二待推送消息；

返回所述将应用程序发送的实时消息作为第一待推送消息的步骤，直至在所述当前周期的末尾时，判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出数量为剩余带宽的历史消息作为第三待推送消息，所述剩余带宽为当前周期的估计带宽与所述实际带宽之差。

优选地，所述预设数量通过下式进行计算，

其中，N为所述预设数量，A为所述估计带宽，B为实时消息的预计带宽。

优选地，所述估计带宽根据上一周期的实际带宽和所述消息队列的消息数量确定。

此外，为实现上述目的，本发明还提供一种消息推送装置，所述装置包括：扩展模块和消息库模块；

所述扩展模块，用于将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，并将所述待推送消息传输至所述消息库模块；

所述消息库模块，用于将接收到的待推送消息进行缓存，并将所述待推送消息推送至目标集群；在所述待推送消息推送失败时，将所述待推送消息回传至所述扩展模块，并将缓存的待推送消息删除；

所述扩展模块，还用于在接收到消息库模块回传的待推送消息时，将预设失败原因的待推送消息添加至所述消息队列中。

优选地，所述扩展模块，还用于计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，并将所述待推送消息传输至消息库模块。

优选地，所述扩展模块，还用于将应用程序发送的实时消息作为第一待推送消息，并将所述第一待推送消息传输至消息库模块；判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出预设数量的历史消息作为第二待推送消息，将所述第二待推送消息传输至消息库模块；在所述当前周期的末尾时，判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出数量为剩余带宽的历史消息作为第三待推送消息，将所述第三待推送消息传输至消息库模块，所述剩余带宽为当前周期的估计带宽与所述实际带宽之差。

优选地，所述预设数量通过下式进行计算，

其中，N为所述预设数量，A为所述估计带宽，B为实时消息的预计带宽。

优选地，所述估计带宽根据上一周期的实际带宽和所述消息队列的消息数量确定。

本发明将待推送消息推送至目标集群，在所述待推送消息推送失败时，将预设失败原因的待推送消息添加至所述消息队列中，从而避免了消息丢失，提高了用户体验。

附图说明

图1为本发明消息推送方法第一实施例的流程示意图；

图2为本发明消息推送方法第二实施例的流程示意图；

图3为本发明消息推送系统第一实施例的功能模块示意图；

图4为本发明消息推送系统第二实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，本发明第一实施例提供一种消息推送方法，所述方法包括：

S10：将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息；

需要说明的是，本实施例的方法的执行主体可为服务器，当然，也可为具有类似功能的其他设备，本实施例对此不加以限制。

可理解的是，所述实时消息为由应用程序刚发送的消息，所述历史消息为位于所述消息队列中的消息。

S20：将所述待推送消息推送至目标集群；

可理解的是，所述目标集群可为kafka集群，当然，也可为其他类型的集群，本实施例对此不加以限制。

S30：在所述待推送消息推送失败时，将预设失败原因的待推送消息添加至所述消息队列中。

在具体实现中，对于推送失败的消息而言，通常情况下需要重新发送，故而，本实施例中，将预设失败原因的待推送消息添加至所述消息队列中。

当然，对于topic类型的消息、消息相应分区被删除或消息太大等永久性错误所导致的推送失败，对应的待推送消息会直接丢弃，而不再添加至所述消息队列中，故而，所述预设失败原因为非永久性错误所导致的推送失败，例如：消息超时。

本实施例将待推送消息推送至目标集群，在所述待推送消息推送失败时，将预设失败原因的待推送消息添加至所述消息队列中，从而避免了消息丢失，提高了用户体验。

参照图2，图2为本发明消息推送方法第二实施例的流程示意图，基于上述图1所示的实施例，基于第一实施例提出本发明消息推送方法的第二实施例。

本实施例中，步骤S10，具体包括：

S10’：计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息。

需要说明的是，本实施例中，会接收到实时消息，而消息队列中还存在历史消息，但所述带宽通常有限，为了保证实时消息和历史消息的有效传输，本实施例中，可计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息。

可理解的是，所述估计带宽根据上一周期的实际带宽和所述消息队列的消息数量确定，所述实际带宽为一个周期内完成推送的消息条数(含推送成功或推送失败的消息，但不含超时的)来定义。

应理解的是，在确定所述估计带宽时，可根据多种方式进行确定，为保证所述估计带宽的合理性，本实施例中，可通过以下方式进行确定：

在所述消息队列的消息数量占实际带宽的比值小于第一数量阈值时，设置估计带宽为上一周期的实际带宽的第一预设倍数，所述第一预设倍数大于1，例如：所述第一预设倍数为1.1，所述第一数量阈值可设置为上一周期的实际带宽的第一比例(所述第一比例为0～1之间的值)，当然，在设置的估计带宽低于估计带宽下限时，将所述估计带宽重新调整为所述估计带宽下限。

在所述消息队列的消息数量占实际带宽的比值大于第二数量阈值时，设置估计带宽为上一周期的实际带宽的第二预设倍数，所述第二预设倍数小于1，例如：所述第二预设倍数为0.9，所述第二数量阈值可设置为上一周期的实际带宽的第二比例(所述第二比例为0～1之间的值)，当然，在设置的估计带宽高于估计带宽上限时，将所述估计带宽重新调整为所述估计带宽上限。

在所述消息队列的消息数量位于所述第一数量阈值和第二数量阈值之间时，可将设置估计带宽为上一周期的实际带宽。

在具体实现中，可能会出现断网状态，在本实施例中，当联网状况为断网时，可继续探测能否联网，并将所述估计带宽设置为0；当上一周期的实际带宽为0，且联网状态持续超过一个周期时，可设置联网状态为断网，并将所述估计带宽设置为0；

当然，在估计带宽设置为0的情况下，不会推送待推送消息，而是将应用程序发送的实时消息直接添加至所述消息队列中。

为了进一步保证实时消息和历史消息的有效传输，步骤S10’中，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，具体包括：

S11：将应用程序发送的实时消息作为第一待推送消息；

S12：判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出预设数量的历史消息作为第二待推送消息；

在具体实现中，所述预设数量通过下式进行计算，

其中，N为所述预设数量，A为所述估计带宽，B为当前周期的实时消息的预计带宽。

S13：返回步骤S11，直至在所述当前周期的末尾时，判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出数量为剩余带宽的历史消息作为第三待推送消息，所述剩余带宽为当前周期的估计带宽与所述实际带宽之差。

参照图3，本发明第一实施例提供一种消息推送装置，所述装置包括：扩展模块10和消息库模块20；

所述扩展模块10，用于将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，并将所述待推送消息传输至所述消息库模块20；

需要说明的是，本实施例的装置可部署于服务器上，当然，也可部署于具有类似功能的其他设备，本实施例对此不加以限制。

可理解的是，所述实时消息为由应用程序刚发送的消息，所述历史消息为位于所述消息队列中的消息。

所述消息库模块20，用于将接收到的待推送消息进行缓存，并将所述待推送消息推送至目标集群；在所述待推送消息推送失败时，将所述待推送消息回传至所述扩展模块10，并将缓存的待推送消息删除；

在具体实现中，由于待推送消息在推送至所述目标集群时，可能存在推送失败等问题，假设对待推送消息不进行缓存，而直接推送至目标集群，会导致所述待推送消息在推送失败的情况下被直接丢失，从而导致丢包等情况出现，本实施例中，会将所述待推送消息进行缓存，在所述待推送消息推送失败时，将预设失败原因的待推送消息添加至所述消息队列中。

可理解的是，所述目标集群可为kafka集群，当然，也可为其他类型的集群，本实施例对此不加以限制。

所述扩展模块10，还用于在接收到消息库模块回传的待推送消息时，将预设失败原因的待推送消息添加至所述消息队列中。

在具体实现中，对于推送失败的消息而言，通常情况下需要重新发送，故而，本实施例中，将预设失败原因的待推送消息添加至所述消息队列中。

当然，对于topic类型的消息、消息相应分区被删除或消息太大等永久性错误所导致的推送失败，对应的待推送消息会直接丢弃，而不再添加至所述消息队列中，故而，所述预设失败原因为非永久性错误所导致的推送失败，例如：消息超时。

本实施例将待推送消息推送至目标集群，在所述待推送消息推送失败时，将预设失败原因的待推送消息添加至所述消息队列中，从而避免了消息丢失，提高了用户体验。

参照图4，图4为本发明消息推送装置第二实施例的流程示意图，基于上述图3所示的实施例，基于第一实施例提出本发明消息推送装置的第二实施例。

本实施例中，所述扩展模块10’，还用于计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，并将所述待推送消息传输至消息库模块。

需要说明的是，本实施例中，会接收到实时消息，而消息队列中还存在历史消息，但所述带宽通常有限，为了保证实时消息和历史消息的有效传输，本实施例中，可计算当前周期的估计带宽，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息。

可理解的是，所述估计带宽根据上一周期的实际带宽和所述消息队列的消息数量确定，所述实际带宽为一个周期内完成推送的消息条数(含推送成功或推送失败的消息，但不含超时的)来定义。

应理解的是，在确定所述估计带宽时，可根据多种方式进行确定，为保证所述估计带宽的合理性，本实施例中，可通过以下方式进行确定：

在所述消息队列的消息数量占实际带宽的比值小于第一数量阈值时，设置估计带宽为上一周期的实际带宽的第一预设倍数，所述第一预设倍数大于1，例如：所述第一预设倍数为1.1，所述第一数量阈值可设置为上一周期的实际带宽的第一比例(所述第一比例为0～1之间的值)，当然，在设置的估计带宽低于估计带宽下限时，将所述估计带宽重新调整为所述估计带宽下限。

在所述消息队列的消息数量占实际带宽的比值大于第二数量阈值时，设置估计带宽为上一周期的实际带宽的第二预设倍数，所述第二预设倍数小于1，例如：所述第二预设倍数为0.9，所述第二数量阈值可设置为上一周期的实际带宽的第二比例(所述第二比例为0～1之间的值)，当然，在设置的估计带宽高于估计带宽上限时，将所述估计带宽重新调整为所述估计带宽上限。

在所述消息队列的消息数量位于所述第一数量阈值和第二数量阈值之间时，可将设置估计带宽为上一周期的实际带宽。

在具体实现中，可能会出现断网状态，在本实施例中，当联网状况为断网时，可继续探测能否联网，并将所述估计带宽设置为0；当上一周期的实际带宽为0，且联网状态持续超过一个周期时，可设置联网状态为断网，并将所述估计带宽设置为0；

当然，在估计带宽设置为0的情况下，不会推送待推送消息，而是将应用程序发送的实时消息直接添加至所述消息队列中。

为了进一步保证实时消息和历史消息的有效传输，步骤S10’中，根据所述估计带宽将应用程序发送的实时消息或从消息队列中取出的历史消息作为待推送消息，具体包括：

S11：将应用程序发送的实时消息作为第一待推送消息；

S12：判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出预设数量的历史消息作为第二待推送消息；

在具体实现中，所述预设数量通过下式进行计算，

其中，N为所述预设数量，A为所述估计带宽，B为实时消息的预计带宽。

S13：返回步骤S11，直至在所述当前周期的末尾时，判断当前周期的实际带宽是否超过所述估计带宽，若否，则将从消息队列中取出数量为剩余带宽的历史消息作为第三待推送消息，所述剩余带宽为当前周期的估计带宽与所述实际带宽之差。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。