一种数据处理方法、装置、设备及计算机存储介质

技术领域

本申请属于数据处理技术领域，尤其涉及一种数据处理方法、装置、设备及计算机存储介质。

背景技术

目前，数据的生产者在向数据的消费者发出数据后，若确定数据发送失败，则需要重新将数据发送给数据的消费者。

通常，在需要重新发送的数据数量较大的情况下，会将待重发的数据存储在数据重发队列中，按照固定的时间或者固定的频率重新发送给数据的消费者，但是在存在高并发、大批量的待重发数据的情况下，按照固定频率或时间重发数据会造成重发次数过多，导致数据重发队列中数据积压，存储资源被过度占用，存在内存崩溃的风险。

发明内容

本申请实施例提供一种数据处理方法、装置、设备及计算机存储介质，能够减少数据重发次数，进而减少了数据重发队列中的数据积压，减少了存储资源被过度占用的情况发生，降低了内存崩溃的风险。

第一方面，本申请实施例提供一种数据处理方法，方法包括：

将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号；

根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值；

利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长；

在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

在一些实施例中，根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值，包括：

对多个第一探测包的发送时长和处理顺序号进行线性回归，得到线性回归模型；

获取目标系统处理数据的目标数据量；

将目标数据量输入至线性回归模型中，输出得到延迟时长预测值。

在一些实施例中，利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长，包括：

基于预设的多个延迟阈值区间，确定延迟时长预测值的所属延迟阈值区间，以及所属延迟阈值区间对应的预设延迟因子；

利用预设延迟因子和预设可重发次数，生成每次数据重发对应的重发间隔时长。

在一些实施例中，预设可重发次数为N次，N为大于0的整数；

利用预设延迟因子和预设可重发次数，生成每次数据重发对应的重发间隔时长，包括：

将预设延迟因子和重发次数k相乘，得到重发次数k对应的重发间隔时长，k为大于0且小于或等于N的整数；

在k小于N的情况下，将k赋值为k+1，返回执行将预设延迟因子和重发次数k相乘，直至k等于N，得到每次数据重发对应的重发间隔时长。

在一些实施例中，在利用延迟时长预测值和预设可重发次数，生成每次数据重发对应的重发间隔时长之后，方法还包括：

在预设时长之后返回执行将多个第一探测包发送至目标系统。

在一些实施例中，目标数据包括目标数据的已重发次数和重发时间节点；

在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据，包括：

在向目标系统发送目标数据失败的情况下，获取每次数据重发对应的重发间隔时长；

根据已重发次数，确定目标数据在下一次数据重发对应的重发间隔时长；

根据目标数据在下一次数据重发对应的重发间隔时长更新重发时间节点，得到更新后的目标数据；

将更新后的目标数据按照重发时间节点存储至重发队列的相应位置，按照位置重新发送目标数据，直至目标数据发送成功，或者已重发次数等于预设可重发次数。

在一些实施例中，将多个探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号，包括：

将多个第一探测包发送至目标系统，每个第一探测包中包括第一探测包发出时的第一时间戳；

接收目标系统返回的多个第二探测包，第二探测包包括目标系统接收第一探测包时的第二时间戳，以及目标系统对与第二探测包对应的第一探测包进行处理的处理顺序号；

确定同一第二探测包中的第一时间戳与第二时间戳之间的时间差，得到每个第一探测包的发送时长。

第二方面，本申请实施例提供一种数据处理装置，包括：

确定模块，用于将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号；

预测模块，用于根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值；

生成模块，用于利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长；

重发模块，用于在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

第三方面，本申请实施例提供一种电子设备，设备包括：处理器以及存储有计算机程序指令的存储器；

处理器执行计算机程序指令时实现如第一方面任意一项的数据处理方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面任意一项的数据处理方法。

第五方面，本申请实施例提供一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行如第一方面任意一项的数据处理方法。

本申请实施例的数据处理方法、装置、设备及计算机存储介质，通过向目标系统发送多个探测包，根据多个探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号，得到目标系统的数据接收延迟情况随接收数据量的变化而变化的规律，以此来预测目标系统的延迟时长，从而根据延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长，按照重发间隔时长重发目标数据，能够在目标系统发生的延迟结束之后再根据数据是否发送成功的结果来判断是否进行下一次的数据重发，有效减少了数据重发次数，进而减少了数据重发队列中的数据积压，减少了存储资源被过度占用的情况发生，降低了内存崩溃的风险。

附图说明

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

图1是本申请一个实施例提供的数据处理方法的流程示意图；

图2是本申请另一个实施例提供的数据处理方法的流程示意图；

图3是本申请实施例中提出的网络延迟线性回归图；

图4是本申请又一个实施例提供的数据处理方法的流程示意图；

图5是本申请再一个实施例提供的数据处理方法的流程示意图；

图6是本申请实施例提供的数据处理方法对应的系统流程图；

图7是本申请实施例提供的数据处理方法对应的系统架构示意图；

图8是本申请一个实施例提供的数据处理装置的结构示意图；

图9是本申请一个实施例提供的电子设备的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

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

目前，数据的生产者在向数据的消费者发出数据后，若确定数据发送失败，则需要重新将数据发送给数据的消费者。

通常，在需要重新发送的数据数量较大的情况下，需要将待重发的数据存储在数据重发队列中，按照固定的时间或者固定的频率重新发送给数据的消费者，但是在存在高并发、大批量的待重发数据的情况下，按照固定频率或时间重发数据会造成重发次数过多，导致数据重发队列中数据积压，存储资源被过度占用，存在内存崩溃的风险。

基于上述问题，本申请提出一种数据处理方法、装置、设备及计算机存储介质，能够通过向目标系统发送多个探测包，根据多个探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号，得到目标系统的数据接收延迟情况随接收数据量的变化而变化的规律，以此来预测目标系统的延迟时长，从而能够根据延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长，按照重发间隔时长重发目标数据，这样能够尽可能在目标系统发生的延迟结束之后再根据是否发送成功的结果来判断是否进行下一次的数据重发，有效减少了重发次数，进而减少了数据重发队列中数据积压和存储资源被过度占用的情况发生，降低了内存崩溃的风险。

下面首先对本申请实施例所提供的数据处理方法进行介绍。

图1是本申请一个实施例提供的数据处理方法的流程示意图。如图1所示，本申请实施例提供的数据处理方法，包括以下步骤：

S101：将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号。

需要说明的是，由于目标系统存在网络波动，而导致网络波动的原因较多，例如临时性的网络抖动造成的偶发性延迟，以及数据的转发等原因造成的固定的延迟，因此可以通过向目标系统发送较多的探测包，以此来探测目标系统的延迟规律，从而根据延迟规律来重发数据，也就是说，可以在延迟结束之后再确定数据是否发送成功，若延迟结束之后还未发送成功，则重新发送数据，从而减少了重发次数。

作为一种示例，服务器将多个第一探测包发送至目标系统，得到服务器发送第一探测包至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理序号。

作为一种示例，目标系统可以按照预设顺序号对多个第一探测包依次进行处理，还可以按照随机顺序处理多个第一探测包，并记录处理每个第一探测包的顺序，得到目标系统对每个第一探测包进行处理的处理顺序号。

S102：根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值。

可以理解，在向目标系统发送多个第一探测包的情况下，第一探测包是依次被目标系统接收的，每接收一个探测包都产生了一定的延迟，因此数据接收延迟时长与目标系统的已处理数据量之间存在关联性。由于处理顺序号代表了目标系统当前已处理的探测包数量，因此可以利用多个第一探测包的发送时长和处理顺序号来预测处理目标数据量的数据时目标系统的数据接收延迟时长。

作为一种示例，可以根据多个第一探测包的发送时长和处理顺序号得到探测包的发送时长随处理的探测包数量之间的关联关系，从而根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值。

S103：利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长。

可以理解的是，为了提高数据重发的合理性，避免无休止的向目标系统重发数据，可以预先设定数据的可重发次数，当重发次数大于预设可重发次数，可以结束重发。

作为一种示例，由于每次数据重发时的延迟时长是不同的，随着数据重发次数的增多，目标系统由于要处理的数据量增多，延迟时长也在随之增加，因此重发次数越多延迟也越长，因此可以根据延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长。

S104：在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

作为一种示例，在向目标系统发送目标数据失败的情况下，可以按照目标系统对应的每次数据重发的重发间隔时长来重发目标数据，从而能够在重发间隔时长结束之后判断是否发送成功，若发送成功，则停止重发，若发送失败，重新发送目标数据。

本申请实施例提供的上述数据处理方法，通过向目标系统发送多个探测包，根据多个探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号，得到目标系统的数据接收延迟情况随接收数据量的变化而变化的规律，以此来预测目标系统的延迟时长，从而能够根据延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长，按照重发间隔时长重发目标数据，这样能够尽可能在目标系统发生的延迟结束之后再根据是否发送成功的结果来判断是否进行下一次的数据重发，有效减少了重发次数，进而减少了数据重发队列中数据积压，以及存储资源被过度占用的情况发生，降低了内存崩溃的风险。

需要说明的是，由于通过处理顺序号可以直接得到目标系统的已处理数据量，也就是说处理顺序号就是目标系统已处理数据的数据量，因此，可以利用多个第一探测包的发送时长和处理顺序号之间的关联关系来预测处理目标数据量的数据时目标系统的数据接收延迟时长。

由此，为进一步提高生成每次数据重发对应的重发间隔时长的准确性，提出另一种数据处理方法，请参见图2，是本申请另一个实施例提供的数据处理方法的流程示意图。如图2所示，该数据处理方法包括：

S201：将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号。

S202：对多个第一探测包的发送时长和处理顺序号进行线性回归，得到线性回归模型。

作为一种示例，可以对多个第一探测包的发送时长和处理顺序号进行线性回归，即将每个第一探测包的发送时长作为纵坐标，将其对应的处理序号作为横坐标，得到多个二维坐标系上的点，从而进行线性回归，得到线性回归模型。

举例来说，如图3所示，对向目标系统发送多个第一探测包的发送时长和处理顺序号进行线性回归后可以得到一条y＝kx+b的直线，其中x表示探测包的处理序号，y表示探测包的发送时长，从而得到该目标系统对应的线性回归模型。

S203：获取目标系统处理数据的目标数据量。

作为一种示例，目标数据量可以是根据目标系统实际的数据处理量预先设定的值，还可以是实时向目标系统获取的当前待处理数据的数据量。

S204：将目标数据量输入至线性回归模型中，输出得到延迟时长预测值。

可以理解，由于通过处理顺序号可以直接得知目标系统的已处理数据量，也就是说处理顺序号就是以处理数据量，因此，可以利用线性回归模型来预测处理目标数据量的数据时目标系统的数据接收延迟时长。

作为一种示例，将目标数据量输入至线性回归模型中，线性回归模型基于目标数据量预测并输出延迟时长预测值。

S205：利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长。

S206：在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

本实施例中步骤S205至S206与本申请实施例中的S103至S104相同，为了简要起见，在此不再详细描述，详细信息请参见本申请实施例中的描述。

以上为本申请实施例提供的数据处理方法，该方法通过对多个第一探测包的发送时长和处理顺序号进行线性回归，得到线性回归模型；获取目标系统处理数据的目标数据量；将目标数据量输入至线性回归模型中，输出得到延迟时长预测值，实现了根据第一探测包的发送时长和处理顺序号预测目标系统处理目标数据量的数据时的数据接收延迟时长，提高了预测数据接收延迟时长的准确性，进而提高了利用延迟时长预测值和向目标系统发送数据的预设可重发次数生成每次数据重发对应的重发间隔时长的准确性；另外，采用线性回归模型来对延迟时长进行预测，降低了学习成本，避免了迭代更新带来的时间消耗；另外，根据目标系统对数据的消费能力，即目标系统的接收数据延迟情况，根据延迟情况来设定目标数据的重发延迟时长，提高了系统的容错性能，保证了目标系统处理任务的稳定性。

为进一步进而提高了数据重发时机的合理性，提出另一种数据处理方法，请参见图4，是本申请又一个实施例提供的数据处理方法的流程示意图。如图4所示，该数据处理方法包括：

S401：将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号。

S402：根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值。

本实施例中S401至S402与本申请实施例中的S101至S102相同，为了简要起见，在此不再详细描述，详细信息请参见本申请实施例中的描述。

S403：基于预设的多个延迟阈值区间，确定延迟时长预测值的所属延迟阈值区间，以及所属延迟阈值区间对应的预设延迟因子。

需要说明的是，多个延迟阈值区间可以是根据目标系统的实际情况预先设定得到的。

举例来说，设定第一延迟阈值区间为0～30ms：数据传输速度极快，几乎察觉不出有延迟，玩任何游戏都特别顺畅，对应预设延迟因子为1；设定第二延迟阈值区间为31～50ms：数据传输速度良好，可以正常游戏，没有明显的延迟情况，对应预设延迟因子为2；设定第三延迟阈值区间为51～100ms：数据传输速度一般，玩对抗类游戏能感觉出明显延迟，稍有停顿，对应预设延迟因子为3；设定第四延迟阈值区间>100ms：数据传输速度慢，无法正常游戏，有卡顿，存在丢包和掉线的现象，对应预设延迟因子为4。

作为一种示例，若延迟时长预测值为40ms，则其所属延迟阈值区间为31～50ms，对应预设延迟因子为2，可以采用二分折中算法来确定延迟时长预测值的所属延迟阈值区间。

S404：利用预设延迟因子和预设可重发次数，生成每次数据重发对应的重发间隔时长。

需要说明的是，可以根据目标系统的实际情况设定生成每次数据重发对应的重发间隔时长的具体方式，除了利用预设延迟因子和预设可重发次数，还可以加入其它影响因子。

在本申请一些实施例中，预设可重发次数为N次，N为大于0的整数，S404具体可以包括：

将预设延迟因子和重发次数k相乘，得到重发次数k对应的重发间隔时长，k为大于0且小于或等于N的整数；

在k小于N的情况下，将k赋值为k+1，返回执行将预设延迟因子和重发次数k相乘，直至k等于N，得到每次数据重发对应的重发间隔时长。

作为一种示例，可以将每个重发次数分别与预设延迟因子相乘，得到每次数据重发所对应的重发间隔时长。

在本申请一些实施例中，在S404之后，还可以包括：

判断是否达到预设时长，在预设时长之后返回执行将多个第一探测包发送至目标系统。

可以理解的是，服务器可以按照预设频率向目标系统发送预设数量的第一探测包，从而根据目标系统的网络波动变化情况，更新每次数据重发对应的重发间隔时长，提高每次数据重发对应的重发间隔时长的准确性。

S405：判断向目标系统发送目标数据是否成功。

S406：在向目标系统发送目标数据失败的情况下，获取每次数据重发对应的重发间隔时长。

可以理解的是，由于每次数据重发对应的重发间隔时长是在不断更新的，因此，在向目标系统发送目标数据失败，并且目标数据的已重发次数小于可重发次数的情况下，需要重新获取每次数据重发对应的重发间隔时长。

S407：根据已重发次数，确定目标数据在下一次数据重发对应的重发间隔时长。

在本申请一些实施例中，目标数据可以包括目标信息、目标系统的唯一标识、目标数据的已重发次数和重发时间节点。目标信息为目标系统所需要处理的信息。

可以理解，同一服务器可能会向多个系统发送数据，不同的系统重发间隔时长不同。因此可以根据目标系统的唯一标识来确定目标数据的发送对象以及目标数据对应的重发间隔时长。

作为一种示例，根据目标数据的已重发次数，查找到每次数据重发对应的重发间隔时长中确定目标数据在下一次数据重发对应的重发间隔时长。

S408：根据目标数据在下一次数据重发对应的重发间隔时长更新重发时间节点，得到更新后的目标数据。

作为一种示例，在目标数据发送失败的情况下，可以记录重发失败的时间，将重发失败的时间与目标数据在下一次数据重发对应的重发间隔时长相加，得到重发时间节点，将上述重发时间节点更新至目标数据中。

S409：将更新后的目标数据按照重发时间节点存储至重发队列的相应位置，按照位置重新发送目标数据，直至目标数据发送成功，或者已重发次数等于预设可重发次数。

S410：判断已重发次数是否等于预设可重发次数，若不等于预设可重发次数，返回执行S405，若已重发次数等预设可重发次数。

作为一种示例，重发队列是按照重发时间节点的先后顺序对多个待重发数据进行排序的，可以将更新后的目标数据按照重发时间节点存储至重发队列的相应位置，按照位置和重发时间节点重新发送目标数据，直至目标数据发送成功，或者已重发次数等于预设可重发次数。通过重发队列来重发数据可以提高系统的容错性，达到异步消峰的效果，进而降低了耦合性，提高了兼容性。

在本申请一些实施例中，在已重发次数大于预设可重发次数的情况下，可以发出预警，以及时对可能出现的故障进行及时处理。

在本申请另一些实施例中，在已重发次数大于预设可重发次数的情况下，可以结束当前周期的重发，将目标数据标记为发送失败的数据并存入数据库中，在下一周期重新进行数据重发，从而保证了数据传输的稳定性和健壮性。例如目标数据的可重发次数为3次，可以在重发3次都发送失败的情况下结束当天对目标数据的重发，在下一天再次重发目标数据。

以上为本申请实施例提供的数据处理方法，该方法基于预设的多个延迟阈值区间，确定延迟时长预测值的所属延迟阈值区间，以及所属延迟阈值区间对应的预设延迟因子；利用预设延迟因子和预设可重发次数，生成每次数据重发对应的重发间隔时长，从而根据每次数据重发对应的重发间隔时长重发目标数据，提高了每次数据重发对应时间间隔的准确性，进而提高了数据重发时机的合理性，减少了数据重发的次数。

为进一步提高每个第一探测包发送至目标系统的发送时长的准确性，提出另一种数据处理方法，请参见图5，是本申请再一个实施例提供的数据处理方法的流程示意图。如图5所示，该数据处理方法包括：

S501：将多个第一探测包发送至目标系统，每个第一探测包中包括第一探测包发出时的第一时间戳。

作为一种示例，在向目标系统发送每个第一探测包时，对该第一探测包打第一时间戳。

S502：接收目标系统返回的多个第二探测包。

在本申请实施例中，第二探测包包括目标系统接收第一探测包时的第二时间戳，以及目标系统对与第二探测包对应的第一探测包进行处理的处理顺序号。

S503：确定同一第二探测包中的第一时间戳与第二时间戳之间的时间差，得到每个第一探测包的发送时长。

可以理解的是，第一探测包发出时的第一时间戳与目标系统接收第一探测包时的第二时间戳之间的时间差，即为每个第一探测包的发送时长。

S504：根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值。

S505：利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长。

S506：在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

本实施例中步骤S504至S506与本申请实施例中的S102至S104相同，为了简要起见，在此不再详细描述，详细信息请参见本申请实施例中的描述。

以上为本申请实施例提供的数据处理方法，该方法将多个第一探测包发送至目标系统，每个第一探测包中包括第一探测包发出时的第一时间戳；接收目标系统返回的多个第二探测包，第二探测包包括目标系统接收第一探测包时的第二时间戳，以及目标系统对与第二探测包对应的第一探测包进行处理的处理顺序号；确定同一第二探测包中的第一时间戳与第二时间戳之间的时间差，得到每个第一探测包的发送时长，提高每个第一探测包发送至目标系统的发送时长的准确性。

在本申请一些实施例中，如图6所示，是本申请实施例提供的数据处理方法对应的系统流程图。

作为一种示例，服务器(即服务器中的程序)将产生的消息发送至消息的生产者，生产者将消息存放至正常队列，从而将消息发送至消息的消费者，以使消费者消费该消息。在消息发送成功的情况下，消费者向生产者反馈已接收消息的确认信息，生产者停止对该消息的发送；在消息失败的情况下，生产者将该消息存放至重试队列，重试队列根据消息中记录的当前已重发次数，确定重发间隔时长，根据重发间隔时长重发该消息；在重发成功的情况下，生产者停止对该消息的发送，在重发失败的情况下，更新该消息中的已重发次数和重发间隔时长，将更新后的消息重新发存放至重试队列。在重试次数达到预设值后，在当天停止重发该消息，并将该消息标记为发送失败后存储到定时消费数据库中，得到数据库信息，从而可以在第二天重新发送该消息。

另外，在重试次数达到预设值后，可以以短信等方式向管理人员发送提醒信息。

需要说明的是，在发送消息失败或者重发消息失败的情况下，可以将消息存储至缓存系统中的重试队列，每1秒定时轮询缓存系统中的结构队列(结构队列包括正常队列和重试队列)。

以政企运营平台为例进行说明，政企平台是一个供给三方产品的一个平台，每一个三方产品都基本对接一个三方应用的服务，三方应用的服务并未部署在政企平台的机房内，基本上跨区或者跨域，曾经出现过这样的情况，在某一个极短的时间段内，大量用户访问政企平台来购买各种类型的三方产品，同一时间内政企平台同时访问多个三方服务系统，因为三方服务系统当前的访问状况处于高峰时间，或者有的服务处于下线或者维护状态，就会造成短时间内，造成访问三方服务系统的失败和政企平台短时间内多次高频率重复访问外部系统造成了系统崩溃。

探针服务的作用就是帮住政企平台针对三方的应用系统的服务状态进行探测(对应本申请实施例中提出的向目标系统发送探测包)，对于三方服务系统的应用数据发送时间的间隔，根据大量的探测，确定出三方服务系统的网络波动范围，从而根据业务确定重发数据的延时时长，政企平台向企信通平台发送信息，通过网络探测确定的第1次至第3次重发信息的延时时长依次为1m、3m、5m；政企平台向互联网专线平台发送信息，通过网络探测确定的第1次至第3次重发信息的延时时长依次为2m、4m、6m。

延时服务的作用就是当政企平台访问三方服务系统失败后，可以将消息放按照已重发次数确定延时时长，比如政企平台和企信通平台之间消费失败后，若已经重发过一次，则将数据延迟3m后再次重发；政企平台和互联网专线平台之间信息消费失败后，若已经重发过两次，则将数据延迟6m后再次重发；如果三次重发都不成功，将重发失败的信息放入数据库，然后短信推送平台管理人员，平台管理人员在对应的前端界面可以看到对接各个三方产品的消息的发送情况，可以手动再次重发，还可以联系三方平台，具体情况通报，有效解决生产中的故障问题。

在本申请一些实施例中，如图7所示，是本申请实施例提供的数据处理方法对应的系统架构示意图。下面分别对系统架构中的负载均衡层、治理配置层、监控保护层、服务网关层、服务应用层和数据保存层分别进行解释：

负载均衡层包括多个负载均衡模块，主要作用是静态资源代理和服务应运的负载均衡处理；

治理配置层包括配置管理模块、服务治理模块和流量控制模块，服务治理模块和流量控制模块都是对微服务的管理，不用对外暴露服务的ip,只要通过服务名称即可找到对用的应用；配置管理模块是对各个微服务的配置信息进行动态的保存以便微服务能够实时拉取到信息；

监控保护层包括链路跟踪模块和容错保护模块，链路跟踪模块对于服务的链路调用追踪具有很好的监控能力；容错保护模块对于高流量的访问就有保护作用；

服务网关层包括多个服务网关模块，服务网关模块对于外来服务请求具有很好的保护作用，具有过滤作用；

服务应用层该区域聚集了很多微服务，探针服务、计算服务以及延时消费服务等等，都在该区域部署；

数据保存层包括文件存储系统、数据库、缓存系统、消息中间件和信息配置仓库，文件存储系统用于保存用户大数据资源，数据库用于一般数据的存储，缓存系统用于缓存高频信息，消息中间件用于对消息队列信息进行存储。

首先，业务服务群组向监控&保护系统注册以及向治理&配置系统注册；其次，当外部用户通过客户端对目标系统进行访问时，通过负载均衡系统动态的路由到前端集群服务以及路由到后端对应的服务网关；服务网关通过治理&配置系统路由到对应的业务服务集群；业务集群进行业务处理(即本申请一些实施例中提出的对目标数据进行处理)，将数据流多次清洗处理后存储到数据层中，从外部访问到后续的深度业务处理流程中过程中，监控&保护系统对整体流程进行监控和保护。

基于上述实施例提供的数据处理方法，结合附图5介绍本申请实施例提供的数据处理装置的具体实施方式。

参见图8，是本申请一个实施例提供的数据处理装置的结构示意图，该数据处理装置800包括：

确定模块801，用于将多个第一探测包发送至目标系统，确定将每个第一探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号；

预测模块802，用于根据多个第一探测包的发送时长和处理顺序号，预测处理目标数据量的数据时目标系统的数据接收延迟时长，得到延迟时长预测值；

生成模块803，用于利用延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长；

重发模块804，用于在向目标系统发送目标数据失败的情况下，按照每次数据重发对应的重发间隔时长，重发目标数据。

本申请实施例提供的上述轴承故障诊断模型的训练装置，通过向目标系统发送多个探测包，根据多个探测包发送至目标系统的发送时长，以及目标系统对每个第一探测包进行处理的处理顺序号，得到目标系统的数据接收延迟情况随接收数据量的变化而变化的规律，以此来预测目标系统的延迟时长，从而能够根据延迟时长预测值和向目标系统发送数据的预设可重发次数，生成每次数据重发对应的重发间隔时长，按照重发间隔时长重发目标数据，这样能够尽可能在目标系统发生的延迟结束之后再根据是否发送成功的结果来判断是否进行下一次的数据重发，有效减少了重发次数，进而减少了数据重发队列中数据积压，以及存储资源被过度占用的情况发生，降低了内存崩溃的风险。

作为本申请的一种实现方式，上述预测模块502可以包括：

线性回归子模块，用于对多个第一探测包的发送时长和处理顺序号进行线性回归，得到线性回归模型；

第一获取子模块，用于获取目标系统处理数据的目标数据量；

输出子模块，用于将目标数据量输入至线性回归模型中，输出得到延迟时长预测值。

作为本申请的一种实现方式，为进一步生成每次数据重发对应的重发间隔时长的准确性，上述生成模块503可以包括：

第一确定子模块，用于基于预设的多个延迟阈值区间，确定延迟时长预测值的所属延迟阈值区间，以及所属延迟阈值区间对应的预设延迟因子；

生成子模块，用于利用预设延迟因子和预设可重发次数，生成每次数据重发对应的重发间隔时长。

作为本申请的一种实现方式，上述生成子模块具体用于：将预设延迟因子和重发次数k相乘，得到重发次数k对应的重发间隔时长，k为大于0且小于或等于N的整数；在k小于N的情况下，将k赋值为k+1，返回执行将预设延迟因子和重发次数k相乘，直至k等于N，得到每次数据重发对应的重发间隔时长。

作为本申请的一种实现方式，上述装置还可以包括：

返回模块，用于在预设时长之后返回执行将多个第一探测包发送至目标系统。

作为本申请的一种实现方式，上述重发模块504可以包括：

第二获取子模块，用于在向目标系统发送目标数据失败的情况下，获取每次数据重发对应的重发间隔时长；

第二确定子模块，用于根据已重发次数，确定目标数据在下一次数据重发对应的重发间隔时长；

更新子模块，用于根据目标数据在下一次数据重发对应的重发间隔时长更新重发时间节点，得到更新后的目标数据；

重发子模块，用于将更新后的目标数据按照重发时间节点存储至重发队列的相应位置，按照位置重新发送目标数据，直至目标数据发送成功，或者已重发次数等于预设可重发次数。

作为本申请的一种实现方式，上述确定模块501可以包括：

发送子模块，用于将多个第一探测包发送至目标系统，每个第一探测包中包括第一探测包发出时的第一时间戳；

接收子模块，用于接收目标系统返回的多个第二探测包，第二探测包包括目标系统接收第一探测包时的第二时间戳，以及目标系统对与第二探测包对应的第一探测包进行处理的处理顺序号；

第三确定子模块，用于确定同一第二探测包中的第一时间戳与第二时间戳之间的时间差，得到每个第一探测包的发送时长。

图9是本申请一个实施例提供的电子设备的结构示意图。

电子设备900可以包括处理器901以及存储有计算机程序指令的存储器902。

具体地，上述处理器901可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器902可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器902可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器902可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器902可在综合网关容灾设备的内部或外部。在特定实施例中，存储器902是非易失性固态存储器。存储器902可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器902包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可执行上述实施例中的任意一种数据处理方法所描述的操作。

处理器901通过读取并执行存储器902中存储的计算机程序指令，以实现上述实施例中的任意一种数据处理方法。

在一个示例中，电子设备900还可包括通信接口903和总线910。其中，如图9所示，处理器901、存储器902、通信接口903通过总线910连接并完成相互间的通信。

通信接口903，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线910包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线910可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的数据处理方法，本申请实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种数据处理方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。