CN111835467B - 消息发送方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本发明提供一种消息发送方法，包括：在预设的消息记录表中记录待发送消息的关键参数和消息类型；向目标下游业务系统发送待发送消息，待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；当接收到目标下游业务系统返回的消息重发请求，消息重发请求包含下游系统前次消息接收时间时，查找下游系统前次消息接收时间到上游系统本次消息发送时间之间向目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回向目标下游业务系统发送待发送消息的步骤，同时将各新待发送消息的历史发送次数加1。本发明能够在不影响上游业务系统进程性能的前提下确认消息是否丢失。

Description

消息发送方法、装置、计算机设备和存储介质

技术领域

本发明涉及消息传输技术领域，尤其涉及一种消息发送方法、装置、计算机设备和存储介质。

背景技术

当两个关联系统交互时，为了解耦或是避免消息洪峰，上游业务系统会有很多需要通过MQ(Message Queue，消息队列)向下游业务系统发送消息的场景，但是系统间通过MQ进行交互并不是100％可靠的，不管是activeMq、rabbitMq或是rocketMq、Kafka，都无法保证消息可以100％发送成功。目前，一般通过下游业务系统向上游业务系统发送回执来确认消息是否发送成功。当接收消息的下游业务系统较多时，较多的回执会影响上游业务系统的进程性能。

此外，当消息发送失败时，对于上游业务系统就很有必要支持消息重发。传统方案一般是在捕获到异常消息后直接重新发送消息，重试多次，如果多次重试均失败，那么该消息便被丢弃不再重发，等下游业务系统发现问题再通知上游业务系统，上游业务系统再通知人工构造消息，并将人工构造的消息重新发送至下游业务系统，由于此种方案需要人工构造消息，耗时较长且存在人为失误的情况。对此，现有技术提供了另外一种方案，当某消息经多次重发仍失败后，将该消息存入缓存系统，再利用定时器，每隔一段时间，定时从缓存系统中取出缓存消息重新进行发送，由于此种方案需要将每条发送失败消息的完整内容进行缓存，因此存储成本较高。

发明内容

针对上述现有技术的不足，本发明提供一种消息发送方法、装置、计算机设备和存储介质，能够在不影响上游业务系统进程性能的前提下确认消息是否丢失，同时在消息发送失败时无需对消息进行缓存，节约存储成本。

为了实现上述目的，本发明提供一种消息发送方法，包括：

在预设的消息记录表中记录待发送消息的关键参数和消息类型；

向目标下游业务系统发送所述待发送消息，其中，在所述待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；

当接收到所述目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回所述向目标下游业务系统发送所述待发送消息的步骤，同时将各所述新待发送消息的历史发送次数加1；

当某新待发送消息的历史发送次数达到预设的第一重发次数阈值时，将所述新待发送消息的消息状态设置为失败，同时丢弃所述新待发送消息；

定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统发送所述目标消息。

在本发明一个实施例中，所述在预设的消息记录表中记录待发送消息的关键参数和消息类型之前，还包括：

建立所述消息记录表，以记录消息的关键参数、消息类型、消息状态、历史发送次数和发送时间。

在本发明一个实施例中，所述目标消息中携带回执请求；

在所述向所述目标下游业务系统发送所述目标消息之后，所述方法还包括：

当接收到所述目标下游业务系统返回的回执时，将所述目标消息对应的消息状态更新为成功。

在本发明一个实施例中，在所述向所述目标下游业务系统发送所述目标消息之后，所述方法还包括：

当未接收到所述目标下游业务系统返回的回执时，更新所述目标消息的历史重发次数。

在本发明一个实施例中，在所述更新所述目标消息的历史重发次数后，所述方法还包括：判断所述目标消息的历史重发次数是否达到预定的第二重发次数阈值，若是，则输出对应的告警信息。

在本发明一个实施例中，所述方法还包括：

接收用户输入的关键参数和消息类型；

根据用户输入的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统重发所述目标消息。

在本发明一个实施例中，所述方法还包括：

接收用户输入的批量重发文档，所述批量重发文档中包含多个目标消息对应的关键参数和消息类型；

根据每个目标消息对应的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到多个所述目标消息，并向所述目标下游业务系统重发所述多个目标消息。

本发明还提供一种消息发送装置，包括：

记录模块，用于记录在预设的消息记录表中记录待发送消息的关键参数和消息类型；

第一消息发送模块，用于向目标下游业务系统发送所述待发送消息，其中，在所述待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；

重发模块，用于在接收到所述目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回所述向目标下游业务系统发送所述待发送消息的步骤，同时将各所述新待发送消息的历史发送次数加1；

重发失败处理模块，用于在某新待发送消息的历史发送次数达到预设的第一重发次数阈值时，将所述新待发送消息的消息状态设置为失败，同时丢弃所述新待发送消息；

任务调度模块，用于定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统发送所述目标消息。

在本发明一个实施例中，所述装置还包括：

记录表建立模块，用于建立所述消息记录表，以记录消息的关键参数、消息类型、消息状态、历史发送次数和发送时间。

在本发明一个实施例中，所述目标消息中携带回执请求；

所述装置还包括：

状态更新模块，用于在接收到所述目标下游业务系统返回的回执时，将所述目标消息对应的消息状态更新为成功。

在本发明一个实施例中，所述装置还包括：

次数更新模块，用于在未接收到所述目标下游业务系统返回的回执时，更新所述目标消息的历史重发次数。

在本发明一个实施例中，所述装置还包括：

告警模块，用于判断所述目标消息的历史重发次数是否达到预定的第二重发次数阈值，若是，输出对应的告警信息。

在本发明一个实施例中，所述装置还包括：

手动重发指令接收模块，用于接收用户输入的关键参数和消息类型；

手动重发处理模块，用于根据用户输入的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统重发所述目标消息。

在本发明一个实施例中，所述装置还包括：

批量重发指令接收模块，用于接收用户输入的批量重发文档，所述批量重发文档中包含多个目标消息对应的关键参数和消息类型；

批量重发处理模块，用于根据每个目标消息对应的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到多个所述目标消息，并向所述目标下游业务系统重发所述多个目标消息。

为了实现上述目的，本发明还提供一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现前述方法的步骤。

为了实现上述目的，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现前述方法的步骤。

通过上述技术方案，本发明具有如下有益效果：

采用本发明的方案以后，下游业务系统无需每次接收消息后都对上游业务系统发送回执，减少发送回执对上游业务系统造成的性能影响；同时，当某消息多次重发失败时，将所述待发送消息的消息状态设置为失败，并丢弃所述待发送消息；而后通过定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述消息并下发。从而，本发明无需将每条发送失败消息的完整内容进行缓存，降低了存储成本，同时无需人工构造消息，避免耗时较长且存在人为失误的情况。

附图说明

图1为本发明消息发送方法的一个实施例的流程图；

图2为本发明消息发送装置的一个实施例的结构框图；

图3为本发明计算机设备的一个实施例的硬件架构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

实施例一

本实施例提供一种消息发送方法，适用于上游业务系统，如图1所示，该方法包括以下步骤：

S1，建立消息记录表，用以记录各消息的关键参数、消息类型、消息状态、历史发送次数和发送时间，其中，消息状态可初始化为空。

S2，在所述消息记录表中记录待发送消息的关键参数和消息类型。例如，假设某待发送消息为保单消息，其包括保单号、被保人名称、被保人身份证号码、保险起始时间、保险截止时间、投保人名称、投保人身份证号码等，则可以将其中的保单号作为该待发送消息的关键参数进行记录，将对应消息类型记录为“保单”。

S3，向目标下游业务系统发送所述待发送消息，并将当前时间作为所述待发送消息的发送时间记录于消息记录表中，其中所述待发送消息中携带上游系统本次消息发送时间(即当前时间)和上游系统前次消息发送时间(即上游业务系统上一次发送消息的时间)。

通过在待发送消息中增加上游系统本次消息发送时间和上游系统前次消息发送时间，使得目标下游业务系统可以将消息中的上游系统前次消息发送时间与下游系统前次消息接收时间(即目标下游业务系统上一次接收该上游业务系统所发送的消息的时间)进行匹配，若不一致，说明下游系统前次消息接收时间到上游系统本次消息发送时间之间的消息丢失，则向上游业务系统发送消息重发请求，以请求上游业务系统将这些丢失的消息作为待重发消息进行重新发送。从而，下游业务系统无需每次接收消息后都对上游业务系统发送回执，减少发送回执对上游业务系统造成的性能影响。

S4，当接收到目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后根据所述消息记录表判断查找到消息的消息状态是否为失败，若否，将查找到的消息作为新待发送消息返回步骤S3，以向目标下游业务系统重新发送该消息，同时将各新待发送消息的历史发送次数加1。

具体地，本实施例通过如下步骤获取所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息：首先，根据所述消息重发请求，获取所述下游系统前次消息接收时间；而后，从历史发送消息库中查找从所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息。其中，历史发送消息库中保存有预定时间内向目标下游业务发送的完整消息。

S5，当某新待发送消息的历史发送次数达到预设的第一重发次数阈值(如6次)时，在所述消息记录表中将所述新待发送消息的消息状态设置为失败，以避免在短时间内进行多次无效的重发，同时丢弃所述新待发送消息，以释放该消息占用的存储空间。

S6，通过Quartz定时进行任务调度，以定时从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统重新发送所述目标消息，所述目标消息中携带回执请求。

例如，可以设定每天2：00、12:00、20:00进行三次任务调度，从所述消息记录表中查询所有消息状态为失败的消息所对应的关键参数和消息类型。假设查询到某条失败消息状态对应的消息类型为保单、关键参数为保单号1234567，则从预设的业务数据库中查找生成保单号“1234567”所对应的保单消息的必要参数，如保单号“1234567”对应的被保人名称、被保人身份证号码、保险起始时间、保险截止时间、投保人名称、投保人身份证号码等。而后，按照预设的协议规则组装所有的必要参数，以复原保单号“1234567”所对应的保单消息作为目标消息，并向目标下游业务系统重发所述目标消息，目标下游业务系统接收到目标消息后将返回成功接收的回执。应该理解，本申请中的关键参数为必要参数的一部分。

由于失败消息的数量一般远小于上游业务系统向下游业务发送的消息总数量，所以上游业务系统处理这些消息的回执造成的性能影响较小。

S7，当接收到所述目标下游业务系统返回的成功接收目标消息的回执时，在所述消息记录表中将所述目标消息对应的消息状态更新为成功，并删除所述目标消息，流程结束。例如，若前述保单号“1234567”所对应的保单消息重发成功，则在消息记录表中将消息类型为保单、关键参数为保单号“1234567”对应的消息状态更新为成功。

S8，当未接收到所述目标下游业务系统返回的成功接收目标消息的回执时，更新所述目标消息的历史重发次数并等待下一次所述任务调度。当所述目标消息的历史重发次数达到预定的第二重发次数阈值(例如20次)时，则输出对应的告警信息，例如向相应的开发人员或运营人员发送告警邮件，以通知人工定位原因并进行修复。

可见，本发明下游业务系统无需每次接收消息后都对上游业务系统发送回执，减少发送回执对上游业务系统造成的性能影响。同时，设置了消息记录表来记录消息的关键参数、消息类型和消息状态，当消息多次重发失败时，在所述消息记录表中将所述待发送消息的消息状态设置为失败，并丢弃所述待发送消息；而后通过定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述消息并下发。从而，本发明无需将每条发送失败消息的完整内容进行缓存，降低了存储成本，同时无需人工构造消息，避免耗时较长且存在人为失误的情况。此外，消息记录表可以记录每条消息的消息状态，便于追溯、消息对账及数据统计分析。

优选地，如果有紧急消息需要尽快重发，本发明还支持人工触发。在一种情况下，用户输入的是消息的关键参数和消息类型，此时本发明的方法可以包括：接收用户输入的关键参数和消息类型；根据用户输入的关键参数和消息类型，从所述业务数据库中查找生成对应待发送消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述待发送消息，并向所述目标下游业务系统重发所述待发送消息。在另一种情况下，用户可以直接上传完整的消息进行重发，此时本发明的方法可以包括：接收用户输入的待发送消息，并向所述目标下游业务系统重发所述待发送消息。

此外，本发明还支持用户上传批量重发文档进行批量重发。在一种情况下，批量重发文档中记录多个消息对应的关键参数和消息类型，此时本发明的方法可以包括：接收用户输入的批量重发文档，所述批量重发文档中包含多个待发送消息对应的关键参数和消息类型；对所述消息重发文档进行解析，以获取每个待发送消息对应的关键参数和消息类型；根据每个待发送消息对应的关键参数和消息类型，从所述业务数据库中查找生成对应待发送消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到多个所述待发送消息，并向所述目标下游业务系统重发所述多个待发送消息。在另一种情况下，批量重发文档中记录多个完整的消息，此时本发明的方法还可以包括：接收用户输入的批量重发文档，所述批量重发文档中包含多个待发送消息；对所述消息重发文档进行解析，以获取所述多个待发送消息；向所述目标下游业务系统重发所述多个待发送消息。在本实施例中，批量重发文档可以是CVS(Comma-Separated Values，逗号分隔值)文档，可以通过java8的parallelStream对其进行解析。

需要说明的是，对于本实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明所必须的。

实施例二

本实施例提供一种消息发送装置10，如图2所示，该装置10包括：

记录模块101，用于记录在预设的消息记录表中记录待发送消息的关键参数和消息类型；

第一消息发送模块102，用于向目标下游业务系统发送所述待发送消息，其中，在所述待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；

重发模块103，用于在接收到所述目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回所述向目标下游业务系统发送所述待发送消息的步骤，同时将各所述新待发送消息的历史发送次数加1；

重发失败处理模块104，用于在某新待发送消息的历史发送次数达到预设的第一重发次数阈值时，将所述新待发送消息的消息状态设置为失败，同时丢弃所述新待发送消息；

任务调度模块105，用于定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统发送所述目标消息。

在本实施例中，所述装置10还包括：

记录表建立模块106，用于建立所述消息记录表，以记录消息的关键参数、消息类型、消息状态、历史发送次数和发送时间。

在本实施例中，所述目标消息中携带回执请求；

所述装置10还包括：

状态更新模块107，用于在接收到所述目标下游业务系统返回的回执时，将所述目标消息对应的消息状态更新为成功。

在本实施例中，所述装置10还包括：

次数更新模块108，用于在未接收到所述目标下游业务系统返回的回执时，更新所述目标消息的历史重发次数。

在本实施例中，所述装置10还包括：

告警模块109，用于判断所述目标消息的历史重发次数是否达到预定的第二重发次数阈值，若是，输出对应的告警信息。

在本实施例中，所述装置10还包括：

手动重发指令接收模块110，用于接收用户输入的关键参数和消息类型；

手动重发处理模块111，用于根据用户输入的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统重发所述目标消息。

在本实施例中，所述装置10还包括：

批量重发指令接收模块112，用于接收用户输入的批量重发文档，所述批量重发文档中包含多个目标消息对应的关键参数和消息类型；

批量重发处理模块113，用于根据每个目标消息对应的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到多个所述目标消息，并向所述目标下游业务系统重发所述多个目标消息。

对于本装置实施例而言，其与实施例一的方法实施例基本相似，所以在此描述的比较简单，相关之处参见方法实施例的部分说明即可。同时，本领域技术人员也应该知悉，说明书中所描述的实施例属于优选实施例，所涉及的模块作并不一定是本发明所必须的。

实施例三

本实施例提供一种计算机设备，如可以执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。本实施例的计算机设备20至少包括但不限于：可通过系统总线相互通信连接的存储器21、处理器22，如图3所示。需要指出的是，图3仅示出了具有组件21-22的计算机设备20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

本实施例中，存储器21(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器21可以是计算机设备20的内部存储单元，例如该计算机设备20的硬盘或内存。在另一些实施例中，存储器21也可以是计算机设备20的外部存储设备，例如该计算机设备20上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。当然，存储器21还可以既包括计算机设备20的内部存储单元也包括其外部存储设备。本实施例中，存储器21通常用于存储安装于计算机设备20的操作系统和各类应用软件，例如实施例二的消息发送装置10的程序代码等。此外，存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制计算机设备20的总体操作。本实施例中，处理器22用于运行存储器21中存储的程序代码或者处理数据，例如运行消息发送装置10，以实现实施例一的消息发送方法。

实施例四

本实施例提供一种计算机可读存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等，其上存储有计算机程序，程序被处理器执行时实现相应功能。本实施例的计算机可读存储介质用于存储消息发送装置10，被处理器执行时实现实施例一的消息发送方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。

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

Claims (10)

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

在预设的消息记录表中记录待发送消息的关键参数和消息类型；

向目标下游业务系统发送所述待发送消息，其中，所述待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；

当接收到所述目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回所述向目标下游业务系统发送所述待发送消息的步骤，同时将各所述新待发送消息的历史发送次数加1；

当某新待发送消息的历史发送次数达到预设的第一重发次数阈值时，将所述新待发送消息的消息状态设置为失败，同时丢弃所述新待发送消息；

定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统发送所述目标消息。

2.根据权利要求1所述的消息发送方法，其特征在于，所述在预设的消息记录表中记录待发送消息的关键参数和消息类型之前，还包括：

建立所述消息记录表，以记录消息的关键参数、消息类型、消息状态、历史发送次数和发送时间。

3.根据权利要求1所述的消息发送方法，其特征在于，所述目标消息中携带回执请求；

在所述向所述目标下游业务系统发送所述目标消息之后，所述方法还包括：

当接收到所述目标下游业务系统返回的回执时，将所述目标消息对应的消息状态更新为成功。

4.根据权利要求3所述的消息发送方法，其特征在于，在所述向所述目标下游业务系统发送所述目标消息之后，所述方法还包括：

当未接收到所述目标下游业务系统返回的回执时，更新所述目标消息的历史重发次数。

5.根据权利要求4所述的消息发送方法，其特征在于，在所述更新所述目标消息的历史重发次数后，所述方法还包括：判断所述目标消息的历史重发次数是否达到预定的第二重发次数阈值，若是，则输出对应的告警信息。

6.根据权利要求1所述的消息发送方法，其特征在于，所述方法还包括：

接收用户输入的关键参数和消息类型；

根据用户输入的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统重发所述目标消息。

7.根据权利要求1所述的消息发送方法，其特征在于，所述方法还包括：

接收用户输入的批量重发文档，所述批量重发文档中包含多个目标消息对应的关键参数和消息类型；

根据每个目标消息对应的关键参数和消息类型，从所述业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到多个所述目标消息，并向所述目标下游业务系统重发所述多个目标消息。

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

记录模块，用于记录在预设的消息记录表中记录待发送消息的关键参数和消息类型；

第一消息发送模块，用于向目标下游业务系统发送所述待发送消息，其中，在所述待发送消息中携带上游系统本次消息发送时间和上游系统前次消息发送时间；

重发模块，用于在接收到所述目标下游业务系统返回的消息重发请求，所述消息重发请求包含下游系统前次消息接收时间时，查找所述下游系统前次消息接收时间到上游系统本次消息发送时间之间向所述目标下游业务系统发送的消息，而后判断查找到消息的消息状态是否为失败，若否，则将查找到的消息作为新待发送消息并返回所述向目标下游业务系统发送所述待发送消息的步骤，同时将各所述新待发送消息的历史发送次数加1；

重发失败处理模块，用于在某新待发送消息的历史发送次数达到预设的第一重发次数阈值时，将所述新待发送消息的消息状态设置为失败，同时丢弃所述新待发送消息；

任务调度模块，用于定时进行任务调度，以从所述消息记录表中，获取失败消息状态所对应的关键参数和消息类型，并根据获取到的关键参数和消息类型，从预设的业务数据库中查找生成对应目标消息所需的必要参数，而后按照预设的协议规则组装所述必要参数得到所述目标消息，并向所述目标下游业务系统发送所述目标消息。

9.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7任一项所述方法的步骤。

Images