CN114244899B - 一种消息传递方法、装置及可读存储介质 - Google Patents

Abstract

本申请公开一种消息传递方法、装置及可读存储介质，涉及电子信息领域，通过控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，并将原消息存储至数据库，通过判断消息接收方是否接收到原消息，若未接收到，则通过数据库将原消息发送给消息接收方，比起之前的直接使用消息中间件进行消息传递，即便遇上消息中间件故障，网络波动等异常状况，也可以通过数据库发送原消息给消息接收方，防止了消息的丢失或流转失败，且数据库的存储量远大于消息中间件的数据存储量，在业务流量大时，可以通过数据库将原消息发送给消息接收方，因此缓解了原消息在消息中间件中的堆积，保证了消息的及时消费和消息传递的可靠性。

Description

一种消息传递方法、装置及可读存储介质

技术领域

本申请涉及电子信息领域，特别是涉及一种消息传递方法、装置及可读存储介质。

背景技术

近年来，随着互联网信息技术的飞速发展，信息传递技术应用在网络上的方方面面，特别在互联网购物这一部分，对于消息的流转的畅通性及可靠性要求十分高。

目前的互联网信息传递技术通常是通过消息发送方发送给消息中间件然后转发给消息接收方，如此一来没有保障措施，如果遇上消息中间件故障，网络波动等异常状况，消息的流转可能会中断，影响业务线的正常运转，造成消息丢失或消息流转失败导致无法正确反馈等问题，且消息中间件的工作效率有限，在业务流量大的情况下，也会存在消息堆积等问题。

鉴于上述技术，寻找一种能提高消息传递的可靠性的消息传递方法是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种消息传递方法，以便于解决消息传递可靠性不高的问题。

为解决上述技术问题，本申请提供一种消息传递方法，包括：

控制消息发送方将原消息发送给中间组件，再由所述中间组件将所述原消息转发给消息中间件以便于所述消息中间件将所述原消息发送给消息接收方，并将所述原消息储存至数据库；

判断所述消息接收方是否接收到所述原消息；

若否，则将所述数据库中的所述原消息发送至所述消息接收方。

优选地，所述判断所述消息接收方是否接收到所述原消息包括：

判断是否接收到所述消息接收方发送的接收成功信号，所述接收成功信号为所述消息接收方接收到所述原消息后生成的反馈信号；

若是，则表征所述消息接收方接收到所述原消息；

若否，则表征所述消息接收方未接收到所述原消息。

优选地，该方法还包括：

将所述原消息存储至所述数据库时，将所述原消息的状态设定为待确认状态；

接收到所述原消息对应的所述接收成功信号后，将所述原消息的状态由待确认状态改为已确认状态；

每隔第一预设时间，将所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方。

优选地，该方法还包括：

若所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方的次数达到阈值，则停止发送所述原消息给所述消息接收方，并将所述原消息的状态由待确认状态改为确认失败状态。

优选地，该方法还包括：

每隔第二预设时间，清除所述数据库中所有的达到设定时间阈值的所述原消息。

优选地，所述将所述原消息储存至数据库包括：

将所述原消息放入线程池和/或缓冲区中；将通过所述线程池和/或所述缓冲区处理过的所述原消息存入所述数据库中；

接收所述消息接收方发送的所述接收成功信号包括：

将所述接收成功信号放入所述线程池和/或所述缓冲区中；

将通过所述线程池和/或所述缓冲区处理过的所述接收成功信号存入所述数据库中。

优选地，所述控制消息发送方将原消息发送给所述中间组件，再由所述中间组件将原消息转发给消息中间件，并将所述原消息储存至数据库包括：

通过异步方式控制所述消息发送方将所述原消息发送给所述中间组件，再由中间组件将所述原消息转发给所述消息中间件，并将所述原消息储存至所述数据库。

为解决上述问题，本申请还提供一种消息传递装置，该装置包括：

控制模块，用于控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件以便于所述消息中间件将所述原消息发送给消息接收方，并将所述原消息储存至数据库；

判断模块，用于判断所述消息接收方是否接收到所述原消息，在判断结果为否时启动发送模块；

发送模块，用于将所述数据库中的所述原消息发送至所述消息接收方。

优选地，该装置还包括：

设定模块，用于将所述原消息存储至所述数据库时，将所述原消息的状态设定为待确认状态；

修改模块，用于接收到所述原消息对应的所述接收成功信号后，将所述原消息的状态由待确认状态改为已确认状态；

周期发送模块，用于每隔第一预设时间，将所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方。

优选地，该装置还包括：

停止模块，若所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方的次数达到阈值，则停止发送所述原消息给所述消息接收方，并将所述原消息的状态由待确认状态改为确认失败状态。

优选地，该装置还包括：

清除模块，用于每隔第二预设时间，清除所述数据库中所有的达到设定时间阈值的所述原消息。

为解决上述问题，本申请还提供一种消息传递装置，该装置包括存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述的消息传递方法的步骤。

为解决上述问题，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的消息传递方法的步骤。

本申请所提供的消息传递方法，通过控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，并将原消息存储至数据库，通过判断消息接收方是否接收到原消息，若未接收到，则通过数据库将原消息发送给消息接收方，比起之前的直接使用消息中间件进行消息传递，即便遇上消息中间件故障，网络波动等异常状况，也可以通过数据库发送原消息给消息接收方，防止了消息的丢失或流转失败，且数据库的存储量远大于消息中间件的数据存储量，在业务流量大时，可以通过数据库将原消息发送给消息接收方，因此缓解了原消息的堆积，保证了消息传递的可靠性。

本申请所提供的消息传递装置与可读存储介质与上述方法对应，有益效果相同。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种消息传递方法流程图；

图2为本申请实施例提供的一种优选消息传递***结构图；

图3为本申请实施例提供的一种消息传递装置示意图；

图4为本申请另一实施例提供的消息传递装置的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本申请保护范围。

本申请的核心是提供一种消息传递方法，以便于解决消息传递可靠性不高的问题。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。

图1为本申请实施例提供的一种消息传递方法流程图，如图1所示，该方法包括：

S10：控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件以便于消息中间件将原消息发送给消息接收方，并将原消息储存至数据库；

需要说明的是，中间组件即本申请中新提出的用于消息传递***中的一种包含有数据库，控制装置的组件。

实际应用中，消息发送方即产生原消息一方，消息接收方即接收原消息的一方，例如，在网络购物中，确认商品是否送达，需用户确认时，商家则是消息发送方，买家即是消息接收方。需要说明的是，原消息可以是一个消息发送方发送，也可以是多个消息发送方发送的组合信息，原消息可以是只发送给一个消息接收方，也可以同时发送给多个消息接收方，考虑到存在多个消息发送方和消息接收方，优选方案通过提供一个消息发送接口和一个消息接收接口进行信息处理，在此对于原消息的发送和接收方式不进行限定。

需要说明的是，消息中间件是基于队列与消息传递技术，在网络环境中为应用***提供同步或异步、可靠的消息传输的支撑性软件。消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。在本实施例中，对于消息中间件的具体类型不进行限定。

本实施例中，对于数据库的类型不进行限定，但考虑到运行速度，成本即移植等等多方面因素，一般优选采用MySQL数据库，运行速度快，成本低且操作简单，移植便利。本实施例中对于原消息发送给消息中间件和原消息发送给数据库的可以是同步发送，也可以是异步发送，且对于发送的先后顺序不进行限定。

S11：判断消息接收方是否接收到原消息，若否，进入S12；

需要说明的是，本实施例中对于消息接收方是否接收到原消息的判断方法不进行限定，例如，可以是消息发送方询问消息接收方，也可以是消息接收方自行反馈已接收等等。

S12：则将数据库中的原消息发送至消息接收方。

需要说明的是，在检测到消息接收方未接收到原消息后，由数据库补发，在本实施例中，对于数据库中的原消息的发送次数以及发送时间等均不进行限定，例如可以为每隔一段时间，向未收到原消息的消息接收方发送一次原消息，直到确认消息接收方接收到原消息为止。

在实际应用中，上述步骤均由控制组件控制进行，本实施例对于控制组件的具体形式即类型不进行限定，考虑到实际应用情况一般优选分布式控制***。本实施例中，对于消息的发送可以为单个发送或批量发送，在此不进行限定。

本实施例所提供的消息传递方法，控制消息发送方将原消息发送给消息中间件，并将原消息存储至数据库，通过判断消息接收方是否接收到原消息，若未接收到，则通过数据库将原消息发送给消息接收方，比起之前的直接使用消息中间件进行消息传递，即便遇上消息中间件故障，网络波动等异常状况，也可以通过数据库发送原消息给消息接收方，防止了消息的丢失或流转失败，且数据库的存储量远大于消息中间件的数据存储量，在业务流量大时，可以通过数据库将原消息发送给消息接收方，因此缓解了原消息的堆积，保证了消息传递的可靠性。

上述实施例中对于如何判断消息接收方是否接收到原消息未进行限定，在此提出优选方案，判断消息接收方是否接收到原消息包括：

判断是否接收到消息接收方发送的接收成功信号，接收成功信号为消息接收方接收到原消息后生成的反馈信号；

若是，则表征消息接收方接收到原消息；

若否，则表征消息接收方未接收到原消息。

需要说明的是，判断是否接收到消息接收方发送的接收成功信号有多种方式，例如，可以是设定预设时间，在消息发送方发送消息起预设时间之内未接收到消息接收方发送的接收成功信号，即可判断消息接收方未发送成功信号，或者一共有A、B、C三条原消息依次发送，且接收到了A与C的接收成功信号，那么即可判断B的接收成功信号未接收到。

在本实施例中，对于如何判断消息接收方接收到原消息进行了限定，通过判断是否接收到消息接收方发送的接收成功信号，接收成功信号为消息接收方接收到原消息后生成的反馈信号，因此，无需其他组件用以确认消息接收方是否接收到原消息，而是通过消息接收方的反馈，保证了信息的准确性的同时，也确保了信息传递的效率。

考虑到数据库中可能同时存在多条原消息，其中存在一些被消息接收方接收，另一些未被消息接收方接收，为了准确发送未被消息接收方接收的原消息，在此提出优选方案，该方法还包括：

将原消息存储至数据库时，将原消息的状态设定为待确认状态；

接收到原消息对应的接收成功信号后，将原消息的状态由待确认状态改为已确认状态；

每隔第一预设时间，将数据库中的处于待确认状态的原消息发送给消息接收方。

需要说明的是，这里的数据的状态可以通过附上标识符来设定，也可以通过数据库进行标记分类，在此对于如何设定原消息的状态不进行限定，且对于将处于待确认状态的原消息发送给消息接收方的次数不进行限定，对于第一预设时间的具体时间不进行限定。

本实施例中，将数据库中的原消息进行了状态分类，通过将未确定原消息的设置为待确认状态，已确定的原消息设定为已确认状态，随后周期性向消息接收方发送待确认的原消息，通过上述方案，即可达到批量发送待确认原消息的效果，防止了已确认原消息的无意义发送或待确认原消息漏发送等情况，提高了整个消息传递***的工作效率。

考虑到实际应用中的数据库资源利用问题，在本实施例中提出优选方案，该方法还包括：

若数据库中的处于待确认状态的原消息发送给消息接收方的次数达到阈值，则停止发送原消息给消息接收方，并将原消息的状态由待确认状态改为确认失败状态。

需要说明的是，本实施例中提出待确认状态的原消息发送给消息接收方的次数存在阈值，在此对于阈值的具体数值不进行限定。在发送次数达到阈值后，则确认该原消息发送失败，并将状态修改为确认失败状态，考虑到部分消息的时效性，从而避免了原消息无意义发送，例如订单信息未被确认多次，则视为该订单信息确认失败，本实施例合理地优化了原消息的发送方案，增强了原消息在数据库中被处理的效率。

在实际应用中，由于数据库容量有限，且已确认和确认失败的原消息的存在性价值不高，在此提出优选方案，该方法还包括：

每隔第二预设时间，清除数据库中达到设定时间阈值的原消息。

结合上述实施例，图2为本申请实施例提供的一种优选消息传递***结构图，如图2所示，先通过消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，并将原消息储存至数据库，然后通过消息接收方反馈接收成功信号给控制组件来确认消息接收方是否接收到原消息，从而控制组件周期性将待确认的原消息由数据库发往消息接收方，并定期清理达到时间阈值，即已确认或确认失败的原消息。

需要说明的是，本实施例中，对于第二预设时间及时间阈值的具体时长不进行限定，且通过清除掉所有的达到设定时间阈值的无意义原消息，考虑到旧数据也有一定的利用性，优选方案可以建立一个回收旧数据的数据库来回收已确认和确认失败的原消息。

本实施例提出的方案避免了数据库中存储量的浪费，优化了整个数据库中对于待确认原消息的存储量。

上述实施例中，对于将原消息存储至数据库和获取接收成功信号的方式未进行限定，在此提出优选方案，将原消息储存至数据库包括：

将原消息放入线程池和/或缓冲区中；

将通过线程池和/或缓冲区处理过的原消息存入数据库中；

接收消息接收方发送的接收成功信号包括：

将接收成功信号放入线程池和/或缓冲区中；

将通过线程池和/或缓冲区处理过的接收成功信号存入数据库中。

线程池是一种多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务，缓冲器为暂时置放输出或输入资料的内存，在本实施例中，对于线程池和缓冲区的个数及具体处理方式不进行限定，考虑到编程的可行性和优化问题，优选方案采取3个线程池和一个缓冲区，通过第一个线程池将原消息或接收成功信号放入缓冲区进行缓冲，随后第二个线程池从缓冲区中拉取部分数据，并进行构造处理，之后再放入第三个线程池中进行数据持久化处理，之后将原消息存入数据库或将接收成功信号传达并对原数据的状态进行批量更新。

在实际应用中，由于交易业务场景中数据流量比较大，因此本实施例采用线程池和缓冲区能大大提升***的吞吐能力，使得***能流畅处理较大流量的业务。

上述实施例中对于消息发送方发送原消息给消息中间件以及将原消息储存至数据库的具体方式未进行限定，在此提出优选方案，控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件以便于消息中间件将原消息发送给消息接收方，并将原消息储存至数据库包括：

通过异步方式控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，并将原消息储存至数据库。

需要说明的是，由于数据读取需要时间，同步处理时两个端口同时读取消息发送方发送的原消息的数据，会由于对消息发送的性能造成影响，本实施例读取由于保存和发送操作是异步的，所以不会对消息发送造成性能影响。

在上述实施例中，对于消息传递方法进行了详细描述，本申请还提供消息传递装置对应的实施例。需要说明的是，本申请从两个角度对装置部分的实施例进行描述，一种是基于功能模块的角度，另一种是基于硬件的角度。

图3为本申请实施例提供的一种消息传递装置示意图，如图3所示，该装置包括：

控制模块10，用于控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，以便于消息中间件将原消息发送给消息接收方，并将原消息储存至数据库；

判断模块11，用于判断消息接收方是否接收到原消息，在判断结果为否时启动发送模块；

发送模块12，用于将数据库中的原消息发送至消息接收方。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

优选地，该装置还包括：

设定模块，用于将原消息存储至数据库时，将原消息的状态设定为待确认状态；

修改模块，用于接收到原消息对应的接收成功信号后，将原消息的状态由待确认状态改为已确认状态；

周期发送模块，用于每隔第一预设时间，将数据库中的处于待确认状态的原消息发送给消息接收方。

优选地，该装置还包括：

停止模块，若数据库中的处于待确认状态的原消息发送给消息接收方的次数达到阈值，则停止发送原消息给消息接收方，并将原消息的状态由待确认状态改为确认失败状态。

优选地，该装置还包括：

清除模块，用于每隔第二预设时间，清除数据库中所有的达到设定时间阈值的原消息。

本实施例所提供的消息传递装置，包括控制模块10、判断模块11、发送模块12，通过控制消息发送方将原消息发送给中间组件，再由中间组件将原消息转发给消息中间件，并将原消息存储至数据库，通过判断消息接收方是否接收到原消息，若未接收到，则通过数据库将原消息发送给消息接收方，比起之前的直接使用消息中间件进行消息传递，即便遇上消息中间件故障，网络波动等异常状况，也可以通过数据库发送原消息给消息接收方，防止了消息的丢失或流转失败，且数据库的存储量远大于消息中间件的数据存储量，在业务流量大时，可以通过数据库将原消息发送给消息接收方，因此缓解了原消息的堆积，保证了消息传递的可靠性。

图4为本申请另一实施例提供的消息传递装置的结构图，如图4所示，消息传递装置包括：存储器20，用于存储计算机程序；

处理器21，用于执行计算机程序时实现如上述实施例中所提到的消息传递方法的步骤。

本实施例提供的消息传递装置可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的消息传递方法的相关步骤。另外，存储器20所存储的资源还可以包括操作***202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作***202可以包括Windows、Unix、Linux等。数据203可以包括但不限于消息传递方法中涉及的数据等。

在一些实施例中，消息传递装置还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。

本领域技术人员可以理解，图4中示出的结构并不构成对消息传递装置的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的消息传递装置，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如下方法：上述实施例提到的消息传递方法。

由于本消息传递装置的实施例与上述的方法实施例对应，因此有益效果相同，在此不再赘述。

最后，本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述方法实施例中记载的步骤。

可以理解的是，如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本申请所提供的一种消息传递方法、装置及可读存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种消息传递方法，其特征在于，应用于包含中间组件的消息传递***，所述方法包括：

控制消息发送方将原消息发送给所述中间组件，再由所述中间组件将所述原消息转发给消息中间件以便于所述消息中间件将所述原消息发送给消息接收方，并将所述原消息储存至数据库；

判断所述消息接收方是否接收到所述原消息；

若否，则将所述数据库中的所述原消息发送至所述消息接收方；

其中，所述中间组件为一种包含有所述数据库，控制装置的组件；

所述判断所述消息接收方是否接收到所述原消息，若否，则将所述数据库中的所述原消息发送至所述消息接收方，包括：在检测到所述消息接收方未接收到所述原消息后，由所述数据库补发；具体的，每隔一段时间，向未收到所述原消息的所述消息接收方发送一次所述原消息，直到确认所述消息接收方接收到所述原消息为止。

2.根据权利要求1所述的消息传递方法，其特征在于，所述判断所述消息接收方是否接收到所述原消息包括：

判断是否接收到所述消息接收方发送的接收成功信号，所述接收成功信号为所述消息接收方接收到所述原消息后生成的反馈信号；

若是，则表征所述消息接收方接收到所述原消息；

若否，则表征所述消息接收方未接收到所述原消息。

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

将所述原消息存储至所述数据库时，将所述原消息的状态设定为待确认状态；

接收到所述原消息对应的所述接收成功信号后，将所述原消息的状态由待确认状态改为已确认状态；

每隔第一预设时间，将所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方。

4.根据权利要求3所述的消息传递方法，其特征在于，还包括：

若所述数据库中的处于待确认状态的所述原消息发送给所述消息接收方的次数达到阈值，则停止发送所述原消息给所述消息接收方，并将所述原消息的状态由待确认状态改为确认失败状态。

5.根据权利要求4所述的消息传递方法，其特征在于，还包括：

每隔第二预设时间，清除所述数据库中所有的达到设定时间阈值的所述原消息。

6.根据权利要求2至5任意一项所述的消息传递方法，其特征在于，所述将所述原消息储存至数据库包括：

将所述原消息放入线程池和/或缓冲区中；

将通过所述线程池和/或所述缓冲区处理过的所述原消息存入所述数据库中；

接收所述消息接收方发送的所述接收成功信号包括：

将所述接收成功信号放入所述线程池和/或所述缓冲区中；

将通过所述线程池和/或所述缓冲区处理过的所述接收成功信号存入所述数据库中。

7.根据权利要求1至5任意一项所述的消息传递方法，其特征在于，所述控制消息发送方将原消息发送给所述中间组件，再由所述中间组件将所述原消息转发给消息中间件以便于所述消息中间件将所述原消息发送给消息接收方，并将所述原消息储存至数据库包括：

通过异步方式控制所述消息发送方将所述原消息发送给中间组件，再由中间组件将所述原消息转发给所述消息中间件，将所述原消息储存至所述数据库。

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

控制模块，用于控制消息发送方将原消息发送给中间组件，再由所述中间组件将所述原消息转发给消息中间件以便于所述消息中间件将所述原消息发送给消息接收方，并由所述中间组件将所述原消息储存至数据库；

判断模块，用于判断所述消息接收方是否接收到所述原消息，在判断结果为否时启动发送模块；

发送模块，用于将所述数据库中的所述原消息发送至所述消息接收方；

其中，所述中间组件为一种包含有所述数据库，控制装置的组件；

所述判断所述消息接收方是否接收到所述原消息，若否，则将所述数据库中的所述原消息发送至所述消息接收方，包括：在检测到所述消息接收方未接收到所述原消息后，由所述数据库补发；具体的，每隔一段时间，向未收到所述原消息的所述消息接收方发送一次所述原消息，直到确认所述消息接收方接收到所述原消息为止。

9.一种消息传递装置，其特征在于，包括存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述的消息传递方法的步骤。

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