数据的处理方法及装置、电子设备和计算机可读存储介质与流程

本申请涉及计算机技术领域，特别是涉及数据的处理方法及装置、电子设备和计算机可读存储介质。

背景技术：

随着互联网的普及，部分行业对服务端高并发、快速响应的要求越来越高；如部分系统可能出现短时间内极高的流量。对于常规系统，这种短时间内极高的流量是灾难性的，可能直接击垮服务器，

对此，现有技术中引入了消息队列(messagequeue，mq)，消息队列是一种应用程序之间的通信方法，通常用于不同应用程序中的两个服务之间传递数据，通过在两个或多个服务之间建立消息持久化存储的方式，具有流量削峰、解耦、异步的功能。例如，对于有数据传递需求的a、b两个服务(服务a需要传递数据给服务b)，由于a和b具有mq的服务，因此会在a和b所在系统加入mq服务器；其中，a作为消息提供者，负责生产消息；mq服务器用来存储消息，并处理一些消息发送或接收逻辑；b作为消息消费者，负责消费消息。

可见，mq的引入缓解了服务器的高并发、耦合性强问题。但是对于消息消费者接收到消息后处理过程中，如果多个处理环节中的某一个环节失败，例如写入操作失败，由于前面步骤已经执行，无法回滚，只能保存当前状态的数据，即只能从执行失败的步骤后的步骤向下执行，从而降低了消息在消费者端处理的稳定性。

技术实现要素：

本申请实施例的目的在于提供一种数据的处理方法及装置、电子设备和计算机可读存储介质，以保证消息执行的稳定性。具体技术方案如下：

在本申请实施的第一方面，提供了一种数据的处理方法，包括：在第一消息所对应的第一处理操作执行失败的情况下，第一服务器将所述第一消息所对应的第一数据写入重试队列，其中，所述第一消息由生产消息的第二服务器发送至消费消息的所述第一服务器；所述第一处理操作为所述第一服务器对所述第一消息进行处理过程中所包括的多个处理操作中的任一操作；所述第一服务器启动第一线程，并通过第一线程对所述重试队列中的所述第一数据重新执行所述第一处理操作，其中，基于第二线程执行所述多个处理操作，所述第一线程不同于所述第二线程。

在本申请实施的第二方面，还提供了一种数据的处理装置，应用于第一服务器，包括：第一写入模块，用于在第一消息所对应的第一处理操作执行失败的情况下，将所述第一消息所对应的第一数据写入重试队列，其中，所述第一消息由生产消息的第二服务器发送至消费消息的所述第一服务器；所述第一处理操作为所述第一服务器对所述第一消息进行处理过程中所包括的多个处理操作中的任一操作；第一处理模块，用于启动第一线程，并通过第一线程对所述重试队列中的所述第一数据重新执行所述第一处理操作，其中，基于第二线程执行所述多个处理操作，所述第一线程不同于所述第二线程。

在本申请实施的又一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一所述的数据的处理方法。

在本申请实施的又一方面，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的数据的处理方法。

本申请实施例提供的数据的处理方法，在第一消息所对应的第一处理操作执行失败的情况下，将第一消息所对应的第一数据写入重试队列，然后另起第一线程对该第一数据重新执行写入操作；由于该第一消息由生产消息的第二服务器发送至消费消息的第一服务器，且第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作，即接收消息的第一服务器可以在消息执行过程，多个处理操作中的任一操作执行失败的情况下，第一服务器可以另起线程对该执行失败的数据重新执行处理操作，即可以通过另起线程对执行失败的操作重新执行，以确保从执行失败的操作开始继续向下执行，从而避免了在出现某一个处理操作失败后，需要从执行失败的步骤后向下执行，导致无法完整的执行消息所对应的整个过程的问题。可见，即使出现了执行失败的处理操作，也可以通过另起线程对重试队列中该执行失败的数据重新执行处理操作，即能够使得该消息执行过程完整顺利的向下执行，保证了该消息执行过程的稳定性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本申请实施例中数据的处理方法的流程图之一；

图2为本申请实施例中数据重试处理的示意图之一；

图3为本申请实施例中数据的处理方法的流程图之二。

图4为本申请实施例中数据的处理方法的流程图之三；

图5为本申请实施例中数据的处理方法的流程图之四；

图6为本申请实施例中数据重试处理的示意图之二；

图7为本申请实施例中数据的处理方法的流程图之五；

图8为本申请实施例中数据的处理方法的流程图之六；

图9为本申请实施例中数据重试处理的示意图之三；

图10为本申请实施例中异常数据统计并上报示意图；

图11为本申请实施例中数据的处理装置的结构示意图；

图12为本申请实施例中电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

本申请实施例提供了一种数据的处理方法，如图1所示，该方法的步骤包括：

步骤102，在第一消息所对应的第一处理操作执行失败的情况下，第一服务器将第一消息所对应的第一数据写入重试队列，其中，第一消息由生产消息的第二服务器发送至消费消息的第一服务器；第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作；

步骤104，第一服务器启动第一线程，并通过第一线程对重试队列中的第一数据重新执行第一处理操作，其中，基于第二线程执行多个处理操作，第一线程不同于第二线程。

通过上述步骤102和步骤104，在第一消息所对应的第一处理操作执行失败的情况下，将第一消息所对应的第一数据写入重试队列，然后另起第一线程对该第一数据重新执行写入操作；由于该第一消息由生产消息的第二服务器发送至消费消息的第一服务器，且第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作，即接收消息的第一服务器可以在消息执行过程，多个处理操作中的任一操作执行失败的情况下，第一服务器可以另起线程对该执行失败的数据重新执行处理操作，即可以通过另起线程对执行失败的操作重新执行，以确保从执行失败的操作开始继续向下执行，从而避免了在出现某一个处理操作失败后，需要从执行失败的步骤后向下执行，导致无法完整的执行消息所对应的整个过程的问题。可见，即使出现了执行失败的处理操作，也可以通过另起线程对重试队列中该执行失败的数据重新执行处理操作，即能够使得该消息执行过程完整顺利的向下执行，保证了该消息执行过程的稳定性。

下面结合具体应用场景，对上述步骤102至步骤104进行解释说明。

如图2所示，当第二服务器中的生产者服务a上线后，向mq服务器发送消息，进而mq服务器会通过推送或由第一服务器中的消费者服务b主动拉取的方式获取消息，该消息进入第一服务器后会经过多个处理操作，例如：状态更新、入库、写日志(对应于本申请实施例中的对第一消息进行处理的多个处理操作)。当其中某一处理操作执行失败后，例如入库操作(对应于第一处理操作)，由于前面步骤(状态更新)已经执行，无法回滚，只能保存已执行的状态更新的操作的数据，也就是说，只能从当前执行失败后的处理操作(写日志)向下执行，无法完整执行该多个处理操作，导致消息在消费者端处理的稳定性较低。对于这种情况可以将待入库所对应的数据写入第一服务器的重试队列中，重试队列用于存储入库操作失败的数据，并在第一服务器中另起线程(对应于本申请实施例中的第一线程，正常执行该多个处理操作的线程为第二线程)，以对执行失败的入库操作对应的数据再次执行入库操作，因此，第一服务器可以基于重试队列中取出的数据继续重新执行入库操作，并接着执行入库后的步骤。

在本申请实施例的可选实施方式中，对于步骤102中涉及到的第一服务器将第一消息所对应的第一数据写入重试队列，进一步可以包括：第一服务器将第一数据和与第一数据对应的时间戳写入重试队列，其中，时间戳为第一处理操作的执行时间。

可见，在本申请实施例中除了需要将执行失败的第一处理操作所对应的第一数据写入重试队列之外，还需要将第一数据对应的第一处理操作的执行时间(时间戳)写入重试队列。以第一消息进入第一服务器后会经过多个处理操作，例如：状态更新、入库、写日志为例。其中，该三个处理操作的时间戳分别为第一时间、第二时间、第三时间，且第一时间早于第二时间、第二时间早于第三时间。当某一处理操作执行失败后，如入库操作执行失败后，第一服务器需要将入库操作对应的数据，以及第二时间写入重试队列。

在本申请实施例的另一个可选实施方式中，如图3所示，本申请实施例的方法除了包括上述图1中的方法步骤之外，还可以包括：

步骤302，在第一服务器通过第一线程对第一数据重新执行第一处理操作之前，且在第一数据还对应于第二消息的情况下，第一服务器确定第二消息所对应的第二处理操作的执行状态；其中，第二处理操作的执行结果将覆盖第一处理操作的执行结果；第二处理操作的执行时间晚于第一处理操作的执行时间，

步骤304，在第二处理操作执行失败的情况下，第一服务器将第二消息对应的第一数据写入重试队列；

步骤306，在第二处理操作成功，且还未通过第一线程对第一数据重新执行第一处理操作的情况下，第一服务器禁止启动第一线程。

通过上述步骤302至步骤306可知，在同一数据可能存在对应多条消息(第一数据与第一消息和第二消息均对应)的情况，例如，该第一数据为1，且第一消息和第二消息均可以对第一数据进行更新。如果第一消息的处理操作是将1更新为2，第二消息的处理操作是在第一数据为1的情况下将数据更新为3，或者是在第一数据为2的情况下更新为3，且第一消息的执行时间早于第二消息。也就是说，第二消息对应的处理操作的执行结果将会覆盖第一消息对应的处理操作的执行结果，即第一消息和第二消息正常执行的情况下，最终都会将1更新为3。但在第一消息的执行失败的情况下，其对应的数据写入了重试队列，这种情况下，需要进一步判断第二消息是否已经执行完成，如果第二消息已经执行完成，则因执行失败写入重试队列的第一消息对应的数据，则无需重新执行了。也就是说，正常服务的处理过程是“1”更新为“2”，然后“2”更新为“3”，如果当前第一消息中对于更新的操作执行失败，在将其对应的数据写入重试队列中后，需要进一步判断第二消息有没有执行成功，即数字“1”是否已经更新为“3”，如果已经更新为“3”则无需启动新线程对重试队列中的数据执行写入操作，如果还未更新为“3”则需要对重试队列中的第一消息对应的数据重新执行写入操作。

在本申请实施例的另一个可选实施方式中，如图4所示，本申请实施例的方法除了包括图1中的方法步骤以外，还可以包括：

步骤402，在满足以下至少之一的条件下，对重试队列中的消息所对应的数据进行持久化处理：重试队列中的消息所对应的服务停止之前、重试队列中消息的数量大于预设阈值。

需要说明的是，消息的处理过程停止之前是指消息对应的多个处理操作均已完成之前，因为，在该多个处理操作处理完成后其对应的数据容易丢失。而且，在本申请实施例的可选实施方式中为了减少数据存储的负担，本申请实施例中重试队列中的数据优选为内存数据，即多个处理操作完成时相应的数据也会丢失。此外，如果重试队列中存储的数据过多也会导致内存溢出，即数据丢失。如果数据丢失，则无法对重试队列中内的数据重新执行写入操作。因此，在本申请实施例中，在消息的处理过程停止之前，或重试队列中数据的数据量大于或等于预设阈值的情况下，需要将重试队列中的数据搬移至内存介质中，即数据的持久化。在本申请实施例的具体应用场景中可以只需要其中一种方式，也可以将两种方式结合起来使用，具体方式可以结合具体实际情况进行相应的设置。

需要说明的是，本申请实施例中内存介质可选为服务器的磁盘，在其他应用场景也可以是专有的存储单元，如关系型数据库管理系统中的mysql；若有性能要求还可以存储到分布式缓存里，如远程字典服务器(remotedictionaryserver，redis)。

当触发持久化操作时，说明消息处理问题比较严重，此时可以通知上报异常，具体的通知级别可以根据实际需求相应设置。如图5所示，本申请实施例的方法步骤除包括图4中的方法步骤之外，在对重试队列中的消息所对应的数据进行持久化处理之后，本申请实施例的方法还可以包括：

步骤502，第一服务器向第三服务器上报第一通知消息，其中，第一通知消息用于指示写入操作异常，第三服务器为告警平台中的服务器。

可见，如果当前重试队列中的数据越来越多，则表明当前通过重试队列进行处理的负荷越来越重，需要发出通知消息，以提醒相关人员。如图6所示，在通过目标线程对重试队列中的数据进行处理的情况下，在进行持久化的同时进行异常上报(上报第一通知消息)。

在本申请实施例的再一个可选实施方式中，如图7所示，本申请实施例的方法步骤除了包括图1中的方法步骤以外，还可以包括：

步骤702，在通过第一线程对第一数据重新执行第一处理操作成功的情况下，第一服务器从重试队列中删除第一数据。

通过上述步骤702可知，对于重试队列中已经执行写入操作成功的数据，无需再重新执行写入操作，则可以从重试队列中删除，以便腾出空间存储其他数据，避免重试队列中数据的冗余。

在本申请实施例的另一个可选实施方式中，如图8所示，在第一消息所对应的第一写入操作执行失败的情况下，在本申请实施例步骤102中涉及到的第一服务器将第一消息所对应的第一数据写入重试队列之前，本申请实施例的方法步骤还可以包括：

步骤802，第一服务器重新执行第一处理操作；

步骤804，第一服务器在重新执行第一处理操作失败的情况下，将第一数据写入日志，并保存日志到磁盘；

步骤806，第一服务器对磁盘内的日志的异常属性进行统计，并根据统计结果向第三服务器上报第二通知消息，其中，第二通知消息用于通知写入操作异常。

由上述步骤802可知，在第一处理操作执行失败的情况下，可以先直接对第一处理操作重新执行写入操作，如果可以直接重新执行处理操作成功，则无需将该第一处理操作对应的第一数据写入重试队列。需要说明的是，在本申请实施例中可以多次重新执行处理操作，该重新执行处理操作的次数可以预设值，例如3次、5次等。对于该步骤802在具体应用场景中，在图6的基础上可以是如图9所示，当第二服务器中的生产者服务a上线后，向mq服务器发送消息，进而mq服务器会通过推送或由第一服务器中的消费者服务b主动拉取的方式获取消息，该消息进入第一服务器后会经过多个处理操作，例如：状态更新、入库、写日志(对应于本申请实施例中的对第一消息进行处理的多个处理操作)。当其中某一处理操作执行失败后，例如入库操作(对应于第一处理操作)，在入库操作失败后对入库操作进行重试，重试的上限三次，如果三次以内重试成功，则无需将入库对应的数据写入重试队列，如果重试三次后依然未执行成功，则将入库对应的数据写入重试队列。

此外，在具体应用场景中，对于上述步骤804和步骤806中涉及到的方式可以是如图10所示，服务启动时同时启动相应的模块(例如，搜集投递模块)。当入库失败后，首先将数据写入日志，并将日志保存到磁盘，在日志中可以定义不同的类型(如入库失败、队列数据满等)用于后期数据统计。当异常日志写入磁盘后，搜集投递模块会将保存日志进行解析，并将解析结果投递到统计中心；统计中心对日志数据进行聚合如统计异常属性，例如，异常类型、异常数目，存储统计结果等。统计完成后，调用告警中心发送告警短信或邮件(通知消息)，同时统计结果还能发送给展示模块，分维度的显示异常情况。

如图11所示，本申请实施例还提供了一种数据的处理装置，该装置包括：

第一写入模块112，用于在第一消息所对应的第一处理操作执行失败的情况下，将第一消息所对应的第一数据写入重试队列，其中，第一消息由生产消息的第二服务器发送至消费消息的第一服务器；第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作；

第一处理模块114，用于启动第一线程，并通过第一线程对重试队列中的第一数据重新执行第一处理操作，其中，基于第二线程执行多个处理操作，第一线程不同于第二线程。

通过上述本申请实施例中的装置，在第一消息所对应的第一处理操作执行失败的情况下，将第一消息所对应的第一数据写入重试队列，然后另起第一线程对该第一数据重新执行写入操作；由于该第一消息由生产消息的第二服务器发送至消费消息的第一服务器，且第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作，即接收消息的第一服务器可以在消息执行过程，多个处理操作中的任一操作执行失败的情况下，第一服务器可以另起线程对该执行失败的数据重新执行处理操作，即可以通过另起线程对执行失败的操作重新执行，以确保从执行失败的操作开始继续向下执行，从而避免了在出现某一个处理操作失败后，需要从执行失败的步骤后向下执行，导致无法完整的执行消息所对应的整个过程的问题。可见，即使出现了执行失败的处理操作，也可以通过另起线程对重试队列中该执行失败的数据重新执行处理操作，即能够使得该消息执行过程完整顺利的向下执行，保证了该消息执行过程的稳定性。

可选地，本申请实施例中的第一写入模块112进一步可以包括：写入单元，用于将第一数据和与第一数据对应的时间戳写入重试队列，其中，时间戳为第一处理操作的执行时间。

可选地，本申请实施例中的装置还可以包括：确定模块，用于在通过第一线程对第一数据重新执行第一处理操作之前，且在第一数据还对应于第二消息的情况下，确定第二消息所对应的第二处理操作的执行状态；其中，第二处理操作的执行结果将覆盖第一处理操作的执行结果；第二处理操作的执行时间晚于第一处理操作的执行时间；第二写入模块，用于在第二处理操作执行失败的情况下，将第二消息对应的第一数据写入重试队列；禁止模块，用于在第二处理操作成功，且还未通过第一线程对第一数据重新执行第一处理操作的情况下，禁止启动第一线程。

可选地，本申请实施例中的装置还可以包括：持久化模块，用于在满足以下至少之一的条件下，对重试队列中的数据进行持久化处理：重试队列中数据所对应的消息的处理过程停止之前、重试队列中数据的数据量大于或等于预设阈值；其中，持久化处理是指将数据转存到内存介质中。

可选地，本申请实施例中的装置还可以包括：上报模块，用于在对重试队列中的数据进行持久化处理之后，向第三服务器上报第一通知消息，其中，第一通知消息用于指示写入操作异常，第三服务器为告警平台中的服务器。

可选地，本申请实施例中的装置还可以包括：删除模块，用于在通过第一线程对第一数据重新执行第一处理操作成功的情况下，从重试队列中删除第一数据。

可选地，本申请实施例中的装置还可以包括：执行模块，用于在第一服务器将第一消息所对应的第一数据写入重试队列之前，重新执行第一处理操作；第二处理模块，用于在重新执行第一处理操作失败的情况下，将第一数据写入日志，并保存日志到磁盘；第三处理模块，用于对磁盘内的日志的异常属性进行统计，并根据统计结果向第三服务器上报第二通知消息，其中，第二通知消息用于通知写入操作异常。

本申请实施例还提供了一种电子设备，如图12所示，包括处理器1201、通信接口1202、存储器1203和通信总线1204，其中，处理器1201，通信接口1202，存储器1203通过通信总线1204完成相互间的通信，

存储器1203，用于存放计算机程序；

处理器1201，用于执行存储器1203上所存放的程序时，实现如下步骤：

步骤11，在第一消息所对应的第一处理操作执行失败的情况下，第一服务器将第一消息所对应的第一数据写入重试队列，其中，第一消息由生产消息的第二服务器发送至消费消息的第一服务器；第一处理操作为第一服务器对第一消息进行处理过程中所包括的多个处理操作中的任一操作；

步骤12，第一服务器启动第一线程，并通过第一线程对重试队列中的第一数据重新执行第一处理操作，其中，基于第二线程执行多个处理操作，第一线程不同于第二线程。

上述终端提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述终端与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的数据的处理方法。

在本申请提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的数据的处理方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

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

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。