CN112882853A - 一种数据处理方法、装置及设备 - Google Patents

Abstract

本说明书实施例提供一种数据处理方法、装置及设备，可用于大数据领域。所述方法包括监听同一个消费组中是否存在至少两个线程处理目标作业；在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；基于所述第一线程信息，确定处理所述目标作业的线程；利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；基于所述业务数据对所述目标作业进行业务逻辑处理。利用本说明书实施例可以保证同一份作业不会被多个线程处理，从而避免产生对共享资源的争抢，提高系统服务的可用性。

Description

一种数据处理方法、装置及设备

技术领域

本申请涉及大数据领域，特别涉及一种数据处理方法、装置及设备。

背景技术

在大数据领域中，可用性是对系统服务而言比较重要的标准。

现有技术中，主要基于服务实例定时发送的心跳距离上次心跳发送时间间隔是否超过阈值来确定服务实例是否可以工作，若超过阈值，则判定该服务实例无法工作，由其他服务实例接管其工作，从而可以保证原有工作能被继续处理，保障服务的可用性。

然而，当出现网络异常等问题时，由于原本正常工作的服务实例心跳无法成功更新，待网络恢复后就会有其他服务实例判断其心跳超时并接管其工作，此时就会导致不同节点争抢共享资源，降低系统服务的可用性。

因此，业内亟需一种可以解决上述技术问题的技术方案。

发明内容

本说明书实施例提供了一种数据处理方法、装置及设备，可以保证同一份作业不会被多个线程处理，从而避免产生对共享资源的争抢，提高系统服务的可用性。

本说明书提供的一种数据处理方法、装置及设备是包括以下方式实现的。

一种数据处理方法，应用于分布式发布订阅消息系统，所述分布式发布订阅消息系统包括多个线程，所述多个线程属于同一个消费组，所述方法包括：监听同一个消费组中是否存在至少两个线程处理目标作业；在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；基于所述第一线程信息，确定处理所述目标作业的线程；利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；基于所述业务数据对所述目标作业进行业务逻辑处理。

一种数据处理装置，包括：监听模块，用于监听同一个消费组中是否存在至少两个线程处理目标作业；第一获取模块，用于在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；确定模块，用于基于所述第一线程信息，确定处理所述目标作业的线程；第二获取模块，用于利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；处理模块，用于基于所述业务数据对所述目标作业进行业务逻辑处理。

一种数据处理设备，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现本说明书实施例中任意一个方法实施例方法的步骤。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现本说明书实施例中任意一个方法实施例的步骤。

本说明书提供的一种数据处理方法、装置及设备。一些实施例中可以监听同一个消费组中是否存在至少两个线程处理目标作业，在存在至少两个线程处理目标作业的情况下获取第一线程信息，其中，第一线程信息为分布式文件系统中与目标作业对应的线程信息，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息。进一步可以基于第一线程信息确定处理目标作业的线程，利用处理目标作业的线程获取与目标作业对应的业务数据，基于业务数据对目标作业进行业务逻辑处理。采用本说明书提供的实施方案，不仅可以保证同一份作业不会被多个线程处理，避免产生对共享资源的争抢，提高系统服务的可用性，而且可以在网络异常等问题出现后，保证作业被接管的过程中，数据不丢失、不重复处理，从而提高系统服务的可靠性。

附图说明

此处所说明的附图用来提供对本说明书的进一步理解，构成本说明书的一部分，并不构成对本说明书的限定。在附图中：

图1是本说明书提供的一种数据处理方法的一个实施例的流程示意图；

图2是本说明书提供的一种数据处理方法的一个具体实施例的流程示意图；

图3是本说明书提供的一种数据处理装置的一个实施例的模块结构示意图；

图4是本说明书提供的一种数据处理服务器的一个实施例的硬件结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书中的一部分实施例，而不是全部的实施例。基于本说明书中的一个或多个实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书实施例保护的范围。

随着信息技术的高速发展，各类数据实现指数级增长。传统数据库很难存储、分析这些数据的内容，本说明书实施例中，使用Hadoop生态系统等大数据技术进行业务处理。Hadoop的分布式文件系统(HDFS)是一个被设计成适合运行在通用硬件上的分布式文件系统，具有高容错性、高吞吐量等特点。

Kafka是一种高吞吐量的分布式发布订阅消息系统，被广泛地应用于大数据领域中，主要可以被应用在数据缓冲、异步通信、汇集日志、系统解耦等方面。Kafka的Rebalance机制可以理解为是一种协议，可以用于规定一个消费者组下所有消费者如何达成一致来分配订阅topic的每个分区，当组成员个数发生变化时会触发Rebalance。例如：某Group(消费组)下有20个Consumer(消费者)实例，其订阅了一个具有100个partition(分区)的topic(消息)，正常情况下，Kafka会为每个Consumer平均的分配5个partition，这个分配的过程就是Rebalance。Rebalance发生时，Group下所有Consumer实例都会协调在一起共同参与，Kafka能够保证尽量达到最公平的分配。通过Kafka的Rebalance监听器可以在进行Rebalance的各个阶段触发回调函数。在Kafka中，当订阅topic的消费者数量多于topic的分区数量时，仅分区数量的消费者能够读到数据，其余消费者无法读取到数据。本说明书实施例中，每个线程对应一个消费者，每个线程可以对应一个作业，作业与topic一一对应，每个线程处理对应的作业时可以从订阅的topic中获取对应的业务数据。

下面以一个具体的应用场景为例对本说明书实施方案进行说明。具体的，图1是本说明书提供的一种数据处理方法的一个实施例的流程示意图。虽然本说明书提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。

本说明书提供的一种实施方案可以应用到包括多个线程的客户端、服务器等中。所述客户端可以包括终端设备，如智能手机、平板电脑等。所述服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式系统的服务器结构等。

需要说明的是，下述实施例描述并不对基于本说明书的其他可扩展到的应用场景中的技术方案构成限制。具体的一种实施例如图1所示，本说明书提供的一种数据处理方法的一种实施例可以应用于分布式发布订阅消息系统。其中，分布式发布订阅消息系统包括多个线程，多个线程属于同一个消费组。所述方法可以包括以下步骤。

S0：监听同一个消费组中是否存在至少两个线程处理目标作业。

一些实施例中，在监听同一个消费组中是否存在至少两个线程处理目标作业前，可以基于配置表判断是否存在目标作业，在存在目标作业的情况下，监听同一个消费组中是否存在至少两个线程处理所述目标作业。其中，目标作业可以是待处理作业。所述配置表中可以包括确定作业状态的信息，还可以包括待落数的Kafka topic信息等。一些实施场景中，可以在预设数据库中创建配置表。其中，预设数据库可以是Oracle、MySQL等，本说明书对此不作限定。

一些实施例中，所述确定作业状态的信息可以包括状态标识和心跳更新时间。其中，状态标识可以表示作业状态，例如，待处理或正在处理等，其可以由数字、字母、文字等一种或多种组合生成，本说明书对此不作限定。例如，状态标识可以为1、0，其中，1可以表示作业正在处理中，0可以表示作业待处理。心跳更新时间可以通过对应的线程进行更新，例如，当作业被线程1获取后，线程1可以每隔预设时间更新对应的心跳时间，以便后续识别作业状态。

一些实施例中，所述基于配置表判断是否存在目标作业，可以包括：判断所述配置表中是否存在状态标识为预设标识的作业；或者，判断所述配置表中是否存在心跳更新时间超过预设阈值的作业。其中，预设标识可以表示作业状态为待处理，其可以由数字、字母、文字等一种或多种组合生成，本说明书对此不作限定。预设阈值可以根据时间场景设定，例如，可以是10分钟、15分钟等，本说明书对此不作限定。

一些实施场景中，分布式发布订阅消息系统可以每隔预设时间基于配置表判断是否存在待处理作业，在存在待处理作业的情况下，可以监听同一个消费组中是否存在至少两个线程处理该待处理作业。这样，可以及时发现并避免相同作业被不同节点处理的情况。其中，上述预设时间可以是1分钟、2分钟等，本说明书对此不做限定。

一些实施场景中，出现至少两个线程处理目标作业的场景可以包括原线程正在正常工作中，当出现网络故障问题，原线程无法成功更新配置表中对应作业的心跳信息，待网络恢复后，可能在下一次原线程成功更新之前，被另一空闲线程判断为心跳超时并接手。此时，存在两个线程对同一作业进行处理，即存在两个线程从Kafka同一topic中取数。由于在Kafka中，当订阅topic的消费者数量多于topic的分区数量，仅分区数量的消费者能够读到数据，其余消费者无法读取到数据，这样出现两个线程处理同一作业时，会导致在topic中有数的情况下，一个线程拉取获得数据，按照获得数据的条件进行业务逻辑处理，而另一个线程拉取未获得数据，按照未获得数据的条件进行业务逻辑处理，使得不同节点争抢共享资源，导致系统混乱、数据损坏等问题。

本说明书实施例中，通过监听同一个消费组中是否存在至少两个线程处理目标作业，可以有效避免相同作业被不同节点处理导致的系统混乱、数据损坏等问题。

S2：在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息。

本说明书实施例中，在存在至少两个线程处理目标作业的情况下，可以获取第一线程信息，以便根据第一线程信息确定处理目标作业的线程。其中，第一线程信息为分布式文件系统中与目标作业对应的线程信息。每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息。

一些实施例中，可以预先在分布式文件系统(HDFS)中每个作业对应的工作目录下建立一个用于记录线程信息的文件(记为.lock文件)和一个用于记录数据位移信息的文件(记为.offset文件)。其中，线程信息可以作为作业的锁，锁定处理目标作业的线程。数据位移信息可以作为数据处理原子操作的信息。线程信息可以包含线程所在服务器IP(Internet Protocol)、线程所在程序运行的端口号、线程id(Identity document)等。数据位移信息可以包括消费者目前正要消费的offset(位置)。

一些实施场景中，每个线程在获取到作业时会相应的更新作业在HDFS中与作业对应的线程信息，以此作为该作业的文件锁来判断作业持有者。例如一些实施场景中，每个空闲线程获取到作业变成处理线程后，都会立刻更新.lock文件。具体的，例如，新线程t2从配置表上获取作业1后，会先清空.lock文件，同时写入t2的线程信息。这样如果此时线程t1也在执行作业1，就可以基于.lock文件中存储的线程信息判断该由哪个线程来执行作业1，从而可以保证同一份作业不会被多个线程处理，避免因此产生对共享资源的争抢，从而提高系统服务的可用性。

一些实施例中，所述分布式发布订阅消息系统可以包括Rebalance监听器。其中，所述Rebalance监听器可以用于在存在至少两个线程处理同一目标作业时触发第一回调函数，还可以用于获取与所述目标作业对应的业务数据时触发第二回调函数。

一些实施例中，所述第一回调函数用于检查分布式文件系统中与所述目标作业对应的线程信息是否与当前线程信息一致；所述第二回调函数用于从分布式文件系统中与所述目标作业对应的记录数据位移信息的文件中读取业务数据对应的处理位置。

一些实施场景中，第一回调函数可以为onPartitionRevoked。onPartitionRevoked方法可以检查HDFS中作业对应目录下.lock文件中的线程信息与当前线程自身信息是否一致，以此判断自己是否持有锁。

一些实施场景中，第一回调函数可以为OnPartitionAssigned。onPartitionAssigned方法可以从HDFS上作业目录下.offset文件中读取offset。onPartitionAssigned方法中所实现的内容可以理解为将数据offset的记录与对于数据的业务逻辑处理整体作为原子操作，当业务逻辑未完全成功，则将已进行的部分处理结果回退并重新处理。

一些实施场景中，每个线程内部可以预先创建一个Consumer(消费者)对象。一些实施场景中，在创建Consumer对象时，可以为Consumer对象添加ConsumerRebalanceListener监听器(即Rebalance监听器)，以监听与线程在同一个消费组中且订阅同一topic的消费者变化情况，并实现onPartitionsRevoked和onPartitionsAssigned回调方法。

一些实施例中，每个线程在获取到所述目标作业后，可以每隔预设时间更新所述配置表中目标作业的心跳信息。其中，预设时间可以根据实际场景设定，本说明书对此不作限定。

S4：基于所述第一线程信息，确定处理所述目标作业的线程。

本说明书实施例中，在获取第一线程信息后，可以基于第一线程信息，确定处理目标作业的线程。

由于每个线程在获取到作业时会相应的更新作业在HDFS中与作业对应的线程信息，以此作为该作业的文件锁来判断作业持有者。一些实施例中，在监听到同一个消费组中存在至少两个线程处理目标作业时，可以获取分布式文件系统中与目标作业对应的线程信息，然后判断至少两个线程中哪个线程对应的线程信息与从分布式文件系统中获取的线程信息一致，则将对应的线程作为后续处理该目标作业的线程。

一些实施场景中，至少两个线程中线程信息与从分布式文件系统中获取的线程信息不一致的线程会自动退出。

例如一些实施场景中，原线程t1正在正常工作中，假设正在执行作业A，此时，.lock文件中存储的是原线程t1的信息。当出现网络故障问题时，原线程t1无法成功更新配置表中作业A的心跳。待网络恢复后，可能在下一次原线程t1成功更新之前，被另一空闲线程2判断为心跳超时并接手。此时，存在t1、t2两个线程同时在处理作业A(例如，假设心跳一分钟更新一次，t1在15:01:00更新心跳因网络问题没成功、t1在15:02:00更新心跳因网络问题没成功......、t1在15:10:00更新心跳因网络问题没成功、而当15:10:10开始网络恢复正常，在t1下一次更新心跳为15:11:00，或许15:10:30会有t2来接手作业，此时就会存在t1、t2同时在处理作业A)。想要从t1、t2中确定处理作业A的线程，需要从分布式文件系统中获取与作业A对应的线程信息，由于作业A被空闲线程2接手时，空闲线程2会立即更新.lock文件，使得此时.lock文件中存储的是空闲线程2，这样，就可以将空闲线程2作为处理作业A的线程。

由于每个线程内部预先创建了一个Consumer对象，而在创建Consumer对象时，为Consumer对象添加ConsumerRebalanceListener监听器，所以一些实施场景中，每个线程可以基于添加的ConsumerRebalanceListener监听器触发回调函数onPartitionRevoked检查HDFS中作业对应目录下.lock文件中的线程信息与当前线程自身信息是否一致，以此判断自己是否持有锁，若不一致则判断为不持有，自动退出，若一致则判断为持有，继续执行。

本说明书实施例中，通过基于在分布式文件系统文件中记录线程信息，赋予其锁的作用，并通过Kafka自身的监听器功能有效及时地触发各个线程去检查自己持有的锁，可以保证同一份作业不会被多个线程处理，避免因此产生对共享资源的争抢，从而提高系统服务的可用性。

S6：利用处理所述目标作业的线程获取与所述目标作业对应的业务数据。

本说明书实施例中，在确定处理目标作业的线程后，可以利用处理目标作业的线程获取与目标作业对应的业务数据。

由于作业本身的具体操作会从Kafka的某个topic(可以理解为消息)中拉取数据并对数据进行业务逻辑上的处理。这样，如果原消费者从topic中offset＝offset1的位置拉取数据n1条，当原消费者所在线程对数据进行业务逻辑处理，且已处理n2(n2<n1)条数据时，该线程所在服务器宕机。此时，就会有新的消费者加入，通过Rebalance机制分配topic分区及消费起始的offset(位置)。当分配的起始位置offset为offset1时，原线程已经处理的offset1+n2之间的数据则会被重复消费并重复处理，导致数据重复。而当起始位置offset为offset1+n1时，offset+n2至offset+n1之间的数据会丢失，这样就会降低系统的可靠性。其中，拉取的数据可以用于进行业务上逻辑处理，具体可以包含的信息和业务本身相关，本说明书对此不做限定。

本说明书实施例中，通过Kafka的Rebalance监听器可以在从topic中拉取与目标作业对应的业务数据时，可以触发第二回调函数，确保数据位移的记录与对于数据的业务逻辑处理整体作为原子操作以保障系统可靠性。

一些实施例中，所述利用所述目标线程获取与所述目标作业对应的业务数据，可以包括：基于所述第二回调函数从分布式文件系统中与所述目标作业对应的记录数据位移信息的文件中读取业务数据对应的处理位置；将所述处理位置作为起始位置从对应的topic信息中拉取与所述目标作业对应的业务数据。

一些实施场景中，在确定处理目标作业的线程后，Rebalance监听器会触发回调函数OnPartitionAssigned从HDFS上作业目录下.offset文件中读取offset，进一步清除对offset之后数据的所有业务逻辑操作结果，将topic的seek至读取到的offset处拉取业务数据。其中，由于线程本身内部创建了一个Consumer的对象实例，可以通过调用对象实例的poll()方法来拉取业务数据。

本说明书实施例中，通过将数据位移的记录与对于数据的业务逻辑处理整体作为原子操作，并通过Kafka自身监听器触发原子操作的回退动作可以有效提高系统服务的可靠性。

S8：基于所述业务数据对所述目标作业进行业务逻辑处理。

本说明书实施例中，在利用处理目标作业的线程获取与目标作业对应的业务数据后，可以基于业务数据对目标作业进行业务逻辑处理，从而完成对目标作业的处理。其中，具体业务逻辑处理处理的方式可以根据不同作业实现的功能确定，本说明书对此不做限定。

本说明书实施例中，能够在有多个线程试图同时处理同一作业时，及时被触发检查作业对应文件锁中信息，判断自身是否为锁的持有对象，并及时放弃处理作业，从而可以保障服务稳定性和服务高可用。同时，在当服务器宕机等情况出现时，通过保证消费数据位移记录与对数据的业务逻辑处理整体的原子性可以有效保障服务的可靠性。

本说明书实施例中，不仅可以在保证高可用的时效性的同时，保证当因网络异常等问题出现后同一作业被不同服务实例处理时，能及时触发检查并合理的退出处理，以保障系统服务的可用性，而且也可以在一定程度上保证系统服务的可靠性。

当然，上述只是进行示例性说明，本说明书实施例不限于上述举例，所属领域技术人员在本申请技术精髓的启示下，还可能做出其它变更，但只要其实现的功能和效果与本申请相同或相似，均应涵盖于本申请保护范围内。

下面以Kafka数据持久化至HDFS为场景对上述方法进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。如图2所示，图2是本说明书提供的一种数据处理方法的一个具体实施例的流程示意图。在本具体实施例中，作业与topic一一对应，每个处理线程处理一个作业，Oracle中建有配置表，配置表中存放待落数的Kafka topic信息、处理状态、心跳等内容。在为每个线程创建Consumer对象时，为Consumer对象添加了ConsumerRebalanceListener监听器，以监听与线程自身在相同消费组且订阅同一topic的消费者变化情况，并实现onPartitionsRevoked和onPartitionsAssigned回调方法。可以包括以下步骤。

S101：空闲线程监听Oracle配置表。

其中，空闲的处理线程每分钟检查配置表。

S102：判断Oracle配置表中是否存在待处理作业。

其中，若存在待处理作业，则执行步骤S103，若不存在待处理作业，则返回执行步骤S101。

S103：空闲线程随机选择1个待处理作业，变为业务处理线程。

S104：业务处理线程每分钟更新Oracle配置表中该作业的心跳。

S105：更新HDFS上作业对应目录下的.lock文件。

其中，更新HDFS上作业对应目录下的.lock文件包括记录当前处理线程的IP、端口等信息至文件中，以此作为该作业的文件锁来判断作业持有者。

由于创建Consumer对象时，为Consumer对象添加了ConsumerRebalanceListener监听器，以监听与线程自身在相同消费组且订阅同一topic的消费者变化情况，并实现onPartitionsRevoked和onPartitionsAssigned回调方法。所以，当出现原消费者正常从topic中消费数据并对数据进行业务逻辑处理，因网络故障等情况，被其他线程抢占作业成功时，会触发回调函数onPartitionRevoked检查HDFS中作业对应目录下.lock文件中的线程信息与当前线程自身信息是否一致，以此判断自己是否持有锁。若不一致则判断为不持有，消费者所在线程自动退出。若一致则判断为持有，执行步骤S106。

S106：从topic中拉取数据。

由于当出现原消费者正常从topic中消费数据并对数据进行业务逻辑处理，因网络故障等情况，被其他线程抢占作业成功时，Kafka会重新分配topic，从而会出现数据丢失、数据重复处理等问题，本实施例中，从topic中拉取数据时可以触发回调函数OnPartitionAssigned从HDFS上作业目录下.offset文件中读取offset(位置)。

S107：将数据起始offset写入HDFS上作业目录下的.offset文件中。

S108：对数据进行业务逻辑处理。

此后不断循环执行步骤S106至步骤S108，直至完成对待处理作业的处理。

本说明书实施例，通过Rebalance监听器可以实现在Rebalance前通过触发消费者检查自身是否持有作业的锁来保障系统可靠性，在Rebalance后确保数据位移的记录与对于数据的业务逻辑处理整体作为原子操作以保障系统服务的可靠性。

本说明书实施例，可以既保证高可用的时效性，让服务器出现宕机等故障后原本的工作能被及时接管，且保证当因网络异常等问题出现后，工作被错误接管时，服务能够及时触发检查并处理。同时，在接管的过程中，可以保证不丢失数据、不重复处理数据，从而提高系统服务的可靠性。

当然，上述只是进行示例性说明，本说明书实施例不限于上述举例，所属领域技术人员在本申请技术精髓的启示下，还可能做出其它变更，但只要其实现的功能和效果与本申请相同或相似，均应涵盖于本申请保护范围内。

从以上的描述中，可以看出，本申请实施例可以监听同一个消费组中是否存在至少两个线程处理目标作业，在存在至少两个线程处理目标作业的情况下获取第一线程信息，其中，第一线程信息为分布式文件系统中与目标作业对应的线程信息，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息。进一步可以基于第一线程信息确定处理目标作业的线程，利用处理目标作业的线程获取与目标作业对应的业务数据，基于业务数据对目标作业进行业务逻辑处理。由于分布式文件系统中记录的线程信息可以锁定处理目标作业的线程，这样通过Kafka自身的监听器可以有效及时地触发各个线程去检查自己持有的锁，从而保证同一份作业不会被多个线程处理，避免产生对共享资源的争抢，提高系统服务的可用性；通过将数据位移的记录与对于数据的业务逻辑处理整体作为原子操作，并通过Kafka自身监听器触发原子操作的回退动作可以提高系统服务的可靠性。

本说明书中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参加即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

基于上述所述一种数据处理方法，本说明书一个或多个实施例还提供一种数据处理装置。所述的装置可以包括使用了本说明书实施例所述方法的系统(包括分布式系统)、软件(应用)、模块、组件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本说明书实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参见前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

具体地，图3是本说明书提供的一种数据处理装置的一个实施例的模块结构示意图，如图3所示，本说明书提供的一种数据处理装置可以包括：监听模块120，第一获取模块122，确定模块124，第二获取模块126，处理模块128。

监听模块120，可以用于监听同一个消费组中是否存在至少两个线程处理目标作业；

第一获取模块122，可以用于在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；

确定模块124，可以用于基于所述第一线程信息，确定处理所述目标作业的线程；

第二获取模块126，可以用于利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；

处理模块128，可以用于基于所述业务数据对所述目标作业进行业务逻辑处理。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书还提供一种数据处理设备的实施例，包括处理器及用于存储处理器可执行指令的存储器，所述指令被所述处理器执行时实现包括以下步骤：监听同一个消费组中是否存在至少两个线程处理目标作业；在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；基于所述第一线程信息，确定处理所述目标作业的线程；利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；基于所述业务数据对所述目标作业进行业务逻辑处理。

需要说明的，上述所述的设备根据方法或装置实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图4是本说明书提供的一种数据处理服务器的一个实施例的硬件结构框图，该服务器可以是上述实施例中的数据处理装置或数据处理设备。如图4所示，服务器10可以包括一个或多个(图中仅示出一个)处理器100(处理器100可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器200、以及用于通信功能的传输模块300。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器10还可包括比图4中所示更多或者更少的组件，例如还可以包括其他的处理硬件，如数据库或多级缓存、GPU，或者具有与图4所示不同的配置。

存储器200可用于存储应用软件的软件程序以及模块，如本说明书实施例中的数据处理方法对应的程序指令/模块，处理器100通过运行存储在存储器200内的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器200可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器200可进一步包括相对于处理器100远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块300用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输模块300包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块300可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书提供的上述实施例所述的方法或装置可以通过计算机程序实现业务逻辑并记录在存储介质上，所述的存储介质可以计算机读取并执行，实现本说明书实施例所描述方案的效果。所述存储介质可以包括用于存储信息的物理装置，通常是将信息数字化后再以利用电、磁或者光学等方式的媒体加以存储。所述存储介质可以包括：利用电能方式存储信息的装置如，各式存储器，如RAM、ROM等；利用磁能方式存储信息的装置如，硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘；利用光学方式存储信息的装置如，CD或DVD。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。

本说明书提供的上述数据处理方法或装置实施例可以在计算机中由处理器执行相应的程序指令来实现，如使用windows操作系统的c++语言在PC端实现、linux系统实现，或其他例如使用android、iOS系统程序设计语言在智能终端实现，以及基于量子计算机的处理逻辑实现等。

需要说明的是说明书上述所述的装置、设备、系统根据相关方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照对应方法实施例的描述，在此不作一一赘述。

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

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把部分模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。

本发明是参照根据本发明实施例的方法、装置、设备、系统的流程图和/或方框图来描述的。应理解可由计算机程序指令实现，可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。

以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，应用于分布式发布订阅消息系统，所述分布式发布订阅消息系统包括多个线程，所述多个线程属于同一个消费组，所述方法包括：

监听同一个消费组中是否存在至少两个线程处理目标作业；

在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；

基于所述第一线程信息，确定处理所述目标作业的线程；

利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；

基于所述业务数据对所述目标作业进行业务逻辑处理。

2.根据权利要求1所述的方法，其特征在于，所述监听同一个消费组中是否存在至少两个线程处理目标作业前，包括：

基于配置表判断是否存在目标作业；其中，所述配置表中包括确定作业状态的信息；

在存在目标作业的情况下，监听同一个消费组中是否存在至少两个线程处理所述目标作业。

3.根据权利要求2所述的方法，其特征在于，所述确定作业状态的信息包括状态标识和心跳更新时间；

所述基于配置表判断是否存在目标作业，包括：

判断所述配置表中是否存在状态标识为预设标识的作业；或者，

判断所述配置表中是否存在心跳更新时间超过预设阈值的作业。

4.根据权利要求3所述的方法，其特征在于，每个线程在获取到所述目标作业后，每隔预设时间更新所述配置表中目标作业的心跳信息。

5.根据权利要求1所述的方法，其特征在于，所述分布式发布订阅消息系统包括Rebalance监听器；所述Rebalance监听器用于在存在至少两个线程处理同一目标作业时触发第一回调函数；所述Rebalance监听器还用于获取与所述目标作业对应的业务数据时触发第二回调函数。

6.根据权利要求5所述的方法，其特征在于，所述第一回调函数用于检查分布式文件系统中与所述目标作业对应的线程信息是否与当前线程信息一致；所述第二回调函数用于从分布式文件系统中与所述目标作业对应的记录数据位移信息的文件中读取业务数据对应的处理位置。

7.根据权利要求6所述的方法，其特征在于，所述利用处理所述目标作业的线程获取与所述目标作业对应的业务数据，包括：

基于所述第二回调函数从分布式文件系统中与所述目标作业对应的记录数据位移信息的文件中读取业务数据对应的处理位置；

将所述处理位置作为起始位置从对应的topic信息中拉取与所述目标作业对应的业务数据。

8.一种数据处理装置，其特征在于，包括：

监听模块，用于监听同一个消费组中是否存在至少两个线程处理目标作业；

第一获取模块，用于在存在至少两个线程处理所述目标作业的情况下，获取第一线程信息；所述第一线程信息为分布式文件系统中与所述目标作业对应的线程信息；其中，每个线程在获取到目标作业时会相应的更新目标作业对应的线程信息；

确定模块，用于基于所述第一线程信息，确定处理所述目标作业的线程；

第二获取模块，用于利用处理所述目标作业的线程获取与所述目标作业对应的业务数据；

处理模块，用于基于所述业务数据对所述目标作业进行业务逻辑处理。

9.一种数据处理设备，其特征在于，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现权利要求1至7中任意一项所述方法的步骤。

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

Images