CN109218385B - 处理数据的方法和装置 - Google Patents

Abstract

本申请提供了一种处理数据的方法和装置，该方法包括：主应用获取该主应用和至少一个备应用中的多个客户端模块的标识信息；该主应用根据该标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，该第一客户端模块为多个客户端模块中的任意一个，该第一预配置关系用于指示该第一客户端模块从卡夫卡kafka系统中获取第一数据块的分区位置，该第二预配置关系用于指示该第一客户端模块将处理的所述第一数据块存储至该kafka系统中的分区位置。本申请实施例的技术方案，能够保证处理数据块时分区有序。

Description

处理数据的方法和装置

技术领域

本申请涉及信息技术领域，并且更具体地，涉及一种处理数据的方法和装置。

背景技术

互联网业务和技术的发展迎来了信息革命新高潮，带来数据的爆炸式增长，促使人类进入大数据时代。大数据时代，分析海量数据、寻找价值数据变得至关重要，分布式流处理技术无疑是对无边界数据集进行连续不断的处理、聚合和分析的最好工具。分布式流处理技术需求日益增加，包括支付交易、社交网络、物联网(IOT)、系统监控等。分布式流处理技术在大数据分析领域显得举足轻重。

卡夫卡(Kafka)系统是一种高吞吐量的分布式发布订阅消息系统，已经成为目前最流行的分布式消息系统之一。所有主流的流处理应用都集成Kafka作用于为数据源输入到应用(Data Source)和用于输出应用产生的数据(Data Sink)。流处理应用从Kafka的源主题(Source Topic)中读取数据，处理数据，然后将结果写入Kafka的目标主题(SinkTopic)中。

现有通常采用同步串行处理和异步处理集成Kafka作为Data Source和Data Sink的流处理应用。在采用同步串行处理消息时，可以保证分区内消息有序，但是串行同步处理消息吞吐量低，消息延时高，难以满足高并发、低时延应用场景；在采用异步处理消息时，会出现消息分区内的乱序。

发明内容

本申请提供一种处理数据的方法和装置，能够保证处理数据块时分区有序。

第一方面，提供了一种数据处理的方法，该方法适用于包括主应用和至少一个备应用的分布式系统中，该主应用和至少一个备应用中的每一个应用包括至少一个客户端模块，该客户端模块用于获取卡夫卡kafka系统中的数据块和向该kafka系统存储应用处理后的数据块，该方法包括：

该主应用获取该主应用和至少一个备应用中的多个客户端模块的标识信息；

该主应用根据该标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，该第一客户端模块为该多个客户端模块中的任意一个，该第一预配置关系用于指示该第一客户端模块从该kafka系统中获取第一数据块的分区位置，该第二预配置关系用于指示该第一客户端模块将处理的该第一数据块存储至该kafka系统中的分区位置。

本申请实施例的技术方案，通过预配置应用中客户端模块与卡夫卡系统中分区位置的对应关系，从而能够保证处理数据块时分区有序。

结合第一方面，在第一方面的某些实现方式中，该第一客户端模块包括第一消费模块和第一生产模块，该第一消费模块用于从该kafka系统中获取第一数据块，该第一生产模块用于向该kafka系统中存储处理后该第一数据块，该主应用根据该标识信息确定第一客户端模块的第一预配置关系和第二预配置关系包括：

该主应用确定该第一消费模块的该第一预配置关系和该第一生产模块的第二预配置关系。

应理解，在本申请的实施例中，每个应用中包括至少一个客户端模块，每个客户端模块由一个消费模块和一个生产模块组成，

结合第一方面，在第一方面的某些实现方式中，该主应用根据该标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，包括：

该主应用根据该标识信息和预设关系确定该第一预配置关系和该第二预配置关系。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

该主应用获取该kafka系统中源主题和目标主题，该源主题用于指示该多个客户端获取数据块的分区位置信息，该目标主题用于指示该多个客户端模块存储处理的数据块的分区位置信息。

结合第一方面，在第一方面的某些实现方式中，该主应用根据该标识信息确定该多个客户端模块中的第一客户端模块的第一预配置关系和第二预配置关系，包括：

该主应用根据该标识信息、该预设关系、该源主题以及该目标主题确定该第一预配置关系和该第二预配置关系。

结合第一方面，在第一方面的某些实现方式中，该主应用获取该主应用和至少一个备应用中的多个客户端模块的标识信息，包括：

当该多个客户端模块在分布式注册服务zookeeper中完成注册时，该主应用从该zookeeper中获取该多个客户端模块的标识信息。

在本申请实施例的技术方案中，分布式系统中主应用和至少一个备应用中的多个客户端模块在zookeeper中进行注册，zookeeper中包括多个客户端模块中每个客户端模块的标识信息，能够使得主应用或者任意一个备应用从zookeeper中可以获取多个客户端模块的标识信息。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

该主应用向该zookeeper发送该第一预配置关系和该第二预配置关系，用于指示该多个客户端模块中的任意一个客户端模块与该kafka系统分区位置的对应关系。

在本申请实施例的技术方案中，主应用确定任意一个应用包括的客户端模块与分区的对应关系，确定后主应用将该对应关系发生至zookeeper中，分布式系统中的任意一个应用可以从zookeeper中获取每个客户端模块与kafka系统分区位置的对应关系。

结合第一方面，在第一方面的某些实现方式中，该分布式系统中的每一个应用还包括分区保序模块，该分区保序模块用于对处理的数据块进行排序，该方法还包括：

该主应用将处理的多个数据块按照不同的分区位置在该分区保序模块中进行排序。

在本申请实施例的技术方案中，分布式系统中的每一个应用还可以包括分区保序模块，分区保序模块能够在应用采用异步并行处理数据块时，保证数据块不会跨分区乱序，此外还可以保证数据块在分区有序。

结合第一方面，在第一方面的某些实现方式中，该分区保序模块中包括第一队列和第二队列，其中，该第一队列用于存储序号连续的数据块，该第二队列用于存储序号不连续的数据块，该主应用将处理的多个数据块按照不同的分区位置在该分区保序模块中进行排序，包括：

该主应用处理第二数据块；

若该第二数据块与该第一数据块位于同一分区，且该第二数据块的序号比该第一数据块的序列号大1，则该主应用将处理的该第二数据块存放在与该第一数据块同分区的第一队列中；

若该第二数据块与该第一数据块位于同一分区，且该第二数据块的序号与该第一数据块的序列号不连续，则该主应用将处理的该第二数据块存放在与该第一数据块同分区的第二队列中。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

在该第二数据块存放在该第一队列后，该主应用依次扫描该第二队列；

将与该第二数据块连续且比该第二数据块的序号大1的第三数据块移出该第二队列；

将该第三数据块存放在该第二队列中。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

当该第一队列中的数据块的数量达到预配置的数量；或

当该主应用的等待时间超过定时器的预设时长时，该主应用将该分区保序模块中该第一数据块所在分区的该第一队列中的数据块根据该第二预配置关系发送至该kafka系统。

第二方面，提供了一种处理数据块的装置，该装置适用于包括该装置和至少一个备装置的分布式系统中，该装置和至少一个备装置中的每一个装置包括至少一个客户端模块，该客户端模块用于获取卡夫卡kafka系统中的数据块和向该kafka系统存储应用处理后的数据块，该装置包括：

收发模块，用于获取该装置和至少一个备装置的多个客户端模块的标识信息；

处理模块，用于根据该标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，该第一客户端为该多个客户端模块中的任意一个客户端模块，该第一预配置关系用于指示该第一客户端模块从该kafka系统中获取第一数据块的分区位置，该第二预配置关系用于指示该第一客户端模块将处理的该第一数据块存储至该kafka系统中的分区位置。

本申请实施例的技术方案，通过预配置应用中客户端模块与卡夫卡系统中分区位置的对应关系，从而能够保证处理数据块时分区有序。

结合第二方面，在第二方面的某些实现方式中，该第一客户端模块包括第一消费模块和第一生产模块，该第一消费模块用于从该kafka系统中获取第一数据块，该第一生产模块用于向该kafka系统中存储处理后该第一数据块，该处理模块还用于：

确定该第一消费模块的该第一预配置关系和该第一生产模块的该第二预配置关系。

应理解，在本申请的实施例中，每个应用中包括至少一个客户端模块，每个客户端模块由一个消费模块和一个生产模块组成，

结合第二方面，在第二方面的某些实现方式中，该处理模块还用于：

根据该标识信息和预设关系确定该第一预配置关系和该第二预配置关系。

结合第二方面，在第二方面的某些实现方式中，该收发模块还用于：

获取该kafka系统中源主题和目标主题，该源主题用于指示该多个客户端获取数据块的分区位置信息，该目标主题用于指示该多个客户端模块存储处理的数据块的分区位置信息。

结合第二方面，在第二方面的某些实现方式中，该处理模块还用于：

根据该标识信息、该预设关系、该源主题以及该目标主题确定该第一预配置关系和该第二预配置关系。

结合第二方面，在第二方面的某些实现方式中，该收发模块还用于：

当该多个客户端模块在zookeeper中完成注册时，从该zookeeper中获取该述多个客户端模块的标识信息。

在本申请实施例的技术方案中，分布式系统中的多个客户端模块在zookeeper中进行注册，zookeeper中包括多个客户端模块中每个客户端模块的标识信息，能够使得分布式系统中的任意一个装置可以从zookeeper中可以获取多个客户端模块的标识信息。

结合第二方面，在第二方面的某些实现方式中，该收发模块：

向该zookeeper发送该第一预配置关系和该第二预配置关系，用于指示该多个客户端模块中的任意一个客户端模块与该kafka系统分区位置的对应关系。

在本申请实施例的技术方案中，首先确定任意一个应用包括的客户端模块与分区的对应关系，确定后将该对应关系发生至zookeeper中，分布式系统中的任意一个装置可以从zookeeper中获取每个客户端模块与kafka系统分区位置的对应关系。

结合第二方面，在第二方面的某些实现方式中，该装置还包括：

分区保序模块，用于将处理的多个数据块按照不同的分区位置进行排序。

在本申请实施例的技术方案中，分布式系统中的每一个装置还可以包括分区保序模块，分区保序模块能够在应用采用异步并行处理数据块时，保证数据块不会跨分区乱序，此外还可以保证数据块在分区有序。

结合第二方面，在第二方面的某些实现方式中，该分区保序模块中包括第一队列和第二队列，其中，该第一队列用于存储序号连续的数据块，该第二队列用于存储序号不连续的数据块，该处理模块还应用：

处理第二数据块；

若该第二数据块与该第一数据块位于同一分区，且该第二数据块的序号比该第一数据块的序列号大1，则该处理模块将处理的该第二数据块存放在与该第一数据块同分区的第一队列中；

若该第二数据块与该第一数据块位于同一分区，且该第二数据块的序号与该第一数据块的序列号不连续，则该处理模块将处理的该第二数据块存放在与该第一数据块同分区的第二队列中。

结合第二方面，在第二方面的某些实现方式中，该处理模块还用于：

在该第二数据块存放在该第一队列后，依次扫描该第二队列；

将与该第二数据块连续且比该第二数据块的序号大1的第三数据块移出该第二队列；

将该第三数据块存放在该第二队列中。

结合第二方面，在第二方面的某些实现方式中，该处理模块还用于：

当该第一队列中的数据块的数量达到预配置的数量；或

当该装置的等待时间超过定时器的预设时长时，该装置将该分区保序模块中该第一数据块所在分区的该第一队列中的数据块根据该第二预配置关系发送至该kafka系统。

附图说明

图1是应用本申请实施例的技术方案的场景的示意图。

图2是根据现有技术中再平衡前分区的分配情况的示意图。

图3是根据现有技术中再平衡前数据块的处理过程的示意图。

图4是根据现有技术中再平衡后分区的分配情况的示意图。

图5是根据现有技术中再平衡后数据块的处理过程的示意图

图6是采用异步处理消息时出现分区内乱序的示意图。

图7是根据本申请实施例的处理数据的方法的示意性流程图。

图8是根据本申请实施例的处理数据的方法的示意性交互图。

图9是根据本申请一个实施例的处理数据的方法的示意图。

图10是根据本申请另一个实施例的处理数据的方法的示意图。

图11是根据本申请另一个实施例的处理数据的方法的示意图。

图12是根据本申请另一个实施例的处理数据的方法的示意图。

图13是根据本申请实施例的处理数据的装置的示意性框图。

图14是根据本申请一个实施例的处理数据的装置的示意性框图。

具体实施方式

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

应理解，在本申请的各实施例中，“第一”、“第二”等仅是为了指代不同的对象，并不表示对指代的对象有其它限定。

图1是可应用本申请实施例的技术方案的应用场景的示意图。

如图1所示，应用场景100可以包括分布式系统110、卡夫卡系统120和分布式应用程序协调服务(zookeeper)130等。

分布式系统110包括多个应用，多个应用中包括一个主应用和至少一个备应用。分布式系统110中的每一个应用可以获取卡夫卡系统120中的数据块，并对获取的数据块进行处理后存储至卡夫卡系统120中。

应理解，在本申请的实施例中，应用可以是应用程序(application，APP)。

卡夫卡系统120，可以用于分布式系统110获取数据块以及存储数据块。

分布式应用程序协调服务(zookeeper)130，用于存储分布式系统中每个应用的注册信息，该注册信息包括每个应用的标识信息。

应理解，分布式应用系统110可以与卡夫卡系统120和分布式注册服务(zookeeper)130在同一个集群中，分布式应用系统110也可以与卡夫卡系统120和分布式注册服务(zookeeper)130不在同一个集群中，分布式应用系统110、卡夫卡系统120和分布式注册服务系统130可以是3个独立的系统，本申请实施例对此并不限定。

为便于理解，下面将描述本申请实施例中所涉及的相关术语及其原理。

卡夫卡(kafka)是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

Kafka系统中的相关术语：

缓存代理(Broker)：Kafka集群包含一个或多个服务器，这种服务器被称为broker。

类别(Topic)：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

分区(Partition)：Partition是物理上的概念，每个Topic包含一个或多个Partition。

生产者(Producer)：负责发布消息到Kafka broker。

消费者(Consumer)：向Kafka broker读取消息的客户端。

应理解，在本申请的实施例中，消费者和生产者可以是应用中的模块。

消费者组(Consumer Group)：可以并行消费Topic中partition的消息。

偏移量(offset)：每一个分区都是一个顺序的、不可变的消息队列，并且可以持续的添加。分区中的消息都被分了一个序列号,称之为偏移量，在每个分区中此偏移量都是唯一的。

应理解，在Kafka系统中每一个分区只能由一个消费者来进行消费，但是一个消费者是可以消费多个分区，是一对多的关系。

需要说明的是，在本申请的实施例中消息可以理解为数据块，“消息”和“数据块”可以通用。

图2示出了现有技术中再平衡(rebalance)前分区的分配情况的示意图。在图2中，分区1、分区2、分区3和分区4属于卡夫卡系统中的同一个源主题的不同分区。如图2所示，协调器已经分配好分区和消费者之间的对应的关系，例如，消费者1消费分区1中的消息、消费者2分区2中的消息、消费者3消费分区3中的消息、以及消费者4消费分区4中的消息，每个消费者向协调器发送心跳信号，心跳信号即每隔一段时间向互联的另一方发送一个很小的数据包，通过对方回复情况判断互联的双方之间的通讯链路是否已经断开的方法，通知协调器自己当前的状态。协调器根据心跳信号确保分配的消费者和分区之间的对应关系保持连通的状态。

例如，图3示出了现有技术中再平衡(rebalance)前数据块的处理过程的示意图。在图3中，协调器已经分配分区和消费者之间的对应的关系，及即在broker1 topic1中消费者1消费分区1中的消息，处理后的消息由生产者1发送至broker1 topic2的分区1将处理后的消息进行存储，消费者2消费分区2中的消息，处理后由生产者2发送至broker1 topic2的分区2将处理后的消息进行存储，消费者3消费分区3中的消息，处理后由生产者3发送至broker1 topic2的分区3将处理后的消息进行存储，消费者4消费分区4中的消息，处理后由生产者4发送至broker1 topic2的分区4将处理后的消息进行存储。在rebalance前消息在每个分区中的处理均为有序的。

应理解，在本申请的实施例中，消息可以理解为数据块。

需要说明的是，应用采用串行处理数据块的方式，例如图3所示，应用1将A5数据块经过三个阶段的处理后，再处理A6数据块，同样A6数据块也会经过三个阶段的处理。其中，三个处理阶段可以包括以下阶段，第一阶段，预处理；第二阶段，数据填充；第三阶段，与数据库的交互过程。也就是说，应用采用串行处理数据块的方式时，应用分别将一个数据块处理完后再处理另一个数据块，每个数据块处理时采用相同的处理流程。

当消费者组中的消费者数量发生变化时，协调器会调整消费者和分区之间的对应关系。例如，在消费者组中有新加入的消费者时，或者，在消费者组中有消费者主动退出，或者，消费者组订阅的类别出现分区数量变化。此时，协调器会重新分配分区与消费者之间的对应关系。在协调器重新分配分区与消费者之间的对应关系后，处理消息的过程会出现跨分区乱序的问题。

现有集成Kafka作为用于将源数据输入到应用(Data Source)和用于输出应用产生的数据(Data Sink)的流处理应用，采用同步串行处理消息时，可以保证分区内消息有序。但串行同步处理消息吞吐量低，消息延时高，难以满足高并发、低时延应用场景。此外，由于Kafka管理partition分配，存在Consumer Group Rebalance的问题，从而导致消息跨分区乱序。

其中，消费者组再平衡(Consumer Group Rebalance)是消费者组订阅的种类分区(Topic Partition)发生变化时(增加、减少)或消费者组中的消费者变动时(加入、退出、故障等)，导致Partition在Consumer之间的对应关系重新分配的现象。

图4示出了现有技术中再平衡(rebalance)后分区的分配情况的示意图。在图4中，分区1、分区2、分区3和分区4属于卡夫卡系统中同一个源主题的不同分区。如图4所示，当消费者4出现故障时，即无法再向协调器发送心跳线，导致协调器发起消费者组的再平衡，即协调器需要将消费者和分区之间的对应关系进行重新的分配，rebalance后分区4被分配给消费者1，消费者1从分区1和分区4中poll消息进行消费。由于消费者组rebalance重新分配分区与消费者之间的对应关系，导致rebalance前后同一分区中的消息被不同的消费者消费，例如，rebalance前分区4中的消息由消费者4进行消费，当rebalance后分区4中的消息由消费者1进行消费，导致分区4中的消息部分备消费者4消费后又让消费者1进行消费，使得原本有序的消息出现跨分区乱序的问题。

例如，图5示出了现有技术中再平衡(rebalance)后数据块的处理过程的示意图。上述图3为rebalance前消息的处理过程，当消费者中处理消费者数量的变化或者消费者组订阅的类别出现分区数量变化时，协调器重新分配消费者与分区对应的关系。如图5所示，例如，对于消费者1而言，重新分配前消费分区1中的消息，重新分配后消费者1消费分区1和分区4中的消息。此时，分区4中的消息D3原来由消费者4poll到系统中未处理完成，rebalance后又由消费者1poll到系统中，导致出现消息重复消费的问题。

现有集成Kafka作为用于将源数据输入到应用(Data Source)和用于输出应用产生的数据(Data Sink)的流处理应用，采用异步处理处理消息时，同样可能存在分区内内乱序的问题。

在流处理应用采用异步处理消息时，消息在不同阶段由不同的业务线程处理。消息在当前阶段处理完成后会传递给下一阶段的业务线程继续处理。同一分区中的消息在同一阶段由同一线程池中的不同线程处理，由于CPU对线程调度的不确定性，顺序取到的消息不一定按顺序处理完成，消息按照处理完成的顺序写入Sink Topic对应的Partition时，就会出现消息在分区中乱序的问题。

例如，图6示出了采用异步处理数据块时出现分区内乱序的示意图。如图6所示，整个应用被分为3个阶段，由不同的三个线程池并行处理，第一阶段线程池中线程从SourceTopic的Partition中按顺序poll数据块完成第一阶段处理，然后将数据块传递给第二阶段的线程池中的线程处理，由于CPU对线程调度的不确定性，后进入第二阶段的数据块可能先处理完成，提前进去第3阶段处理，如分区4中数据块D2排在数据块D4前面，但在目标主题中，即主题2的分区4中数据块D4却先于数据块D2处理完成。因此，在同一个分区的数据块顺序被打乱，从而数据块在同分区中出现乱序的问题。

应理解，每个线程池中包括多个线程，对于应用采用异步处理数据块时，在第一处理阶段，线程池中的不同线程在第一处理阶段同时处理不同的数据块；然后将数据块传递至第二处理阶段的线程池，第二处理阶段线程池中的不同线程同时将不同的数据块进行第二阶段的处理；再将数据块传递至第三处理阶段的线程池，第三处理阶段线程池中的不同线程同时将不同的数据块进行第三阶段的处理。

应理解，采用串行处理数据块时，应用将第一个数据块分别进行三个阶段的处理后，再将第二个数据块进行三个阶段的处理；采用异步处理数据块时，线程池中的不同线程分别将多个数据块同时进行第一个阶段的处理后，再同时进行第二个阶段的处理。处理阶段可以包括多个步骤，本申请实施例对此不作限定。

基于上述数据块在分区中出现乱序的问题，下面将结合本申请实施例详细描述在集成Kafka作为Data Source和Data Sink的应用处理数据块时分区保序的技术方案。

图7为根据本申请实施例的处理数据的方法的示意性流程图。图7所示的处理数据的方法可以适用于图1所示的系统架构下，本申请对此不作限定。

710，主应用获取所述主应用和至少一个备应用中的多个客户端模块的标识信息。

应理解，在本申请的实施例中，主应用与至少一个备应用构成分布式系统，该分布式系统与kafka系统和zookeeper可以在一个集群中，也可以在不同的集群中。其中，分布式系统中的每一个应用中包括至少一个客户端模块，一个客户端模块由一个消费者模块和一个生产者模块组成，客户端模块用于获取卡夫卡kafka系统中的数据块和向所述kafka系统存储应用处理后的数据块。也就是说，客户端模块中的消费者模块用于获取卡夫卡kafka系统中的数据块，客户端模块中的生产者模块用于向kafka系统存储应用处理后的数据块，本申请实施例对此不作限定。

需要说明的是，在本申请的实施例中，在分布式系统启动时，分布式系统中主应用和至少一个备应用包括的客户端模块可以在zookeeper中进行注册。当所述多个客户端模块在zookeeper中完成注册时，主应用从所述zookeeper中获取所述多个客户端模块的标识信息。

720，主应用根据多个客户端模块的标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，第一客户端模块为所述多个客户端模块中的任意一个，所述第一预配置关系用于指示所述第一客户端模块从所述kafka系统中获取第一数据块的分区位置，所述第二预配置关系用于指示所述第一客户端模块将处理的所述第一数据块存储至所述kafka系统中的分区位置。

应理解，在本申请的实施例中分布式系统中主应用可以确定系统中每一个应用中的客户端模块从kafka系统中获取数据块的分区位置，以及将数据块处理后存储至kafka系统中的分区位置。客户端模块与分区的预配置关系确定后，在运行过程中不发生改变。即使用分区绑定后，分配关系不会发生改变。绑定关系在应用初始化时发生，一经绑定，运行时不会发生改变。

可选地，在本申请的实施例中，第一客户端模块可以包括第一消费模块和第一生产模块，其中，第一消费模块用于从所述kafka系统中获取第一数据块，第一生产模块用于向所述kafka系统中存储处理后所述第一数据块，主应用根据多个客户端模块的标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，即主应用根据标识信息确定第一消费模块的第一预配置关系和第一生产模块的第二预配置关系。

例如，在本申请的实施例中，主应用可以根据多个客户端模块的标识信息和预设关系确定所述第一预配置关系和所述第二预配置关系。其中，预配置关系可以为一个算法或者分配规则，本申请对此不作限定。

可选地，在本申请的实施例中，主应用获取kafka系统中源主题和目标主题，所述源主题用于指示所述多个客户端获取数据块的分区位置信息，所述目标主题用于指示所述多个客户端模块存储处理的数据块的分区位置信息。即源主题可以是kafka系统中SourceTopic中的分区位置信息，目标主题可以是kafka系统中Sink Topic中的分区位置信息。

在本申请的实施例中，主应用可以根据多个客户端模块的标识信息、预设关系、源主题以及目标主题确定第一预配置关系和第二预配置关系。在主应用确定第一预配置关系和第二预配置关系后，主应用可以向zookeeper发送所述第一预配置关系和所述第二预配置关系，用于指示所述多个客户端模块中的任意一个客户端模块与所述kafka系统分区位置的对应关系。

应理解，在zookeeper中包括分布式系统中多个客户端模块的注册信息，以及主应用确定的多个客户端模块与分区的绑定关系，例如，第一预配置关系和第二预配置关系。分布式系统中的备应用可以从zookeeper中获取多个客户端模块与分区的绑定关系，从而根据绑定关系在相应的源主题中的分区位置获取数据块，以及当应用将获取的数据块处理后存储在对应目标主题的分区中。

例如，图8为根据本申请实施例的处理数据的方法的示意性交互图。在图8中包括注册和分区绑定两个阶段，分区绑定可以理解为主应用确定的客户端模块与分区的对应关系。应理解图8中示出了流程中的主要步骤，图8中还可以包括本申请实施例中未示出的其它步骤，本申请实施例对此并不限定。

S810，分布式系统中的主应用和至少一个备应用中的包括的所有客户端模块向zookeeper发送注册信息。

应理解，一个客户端模块中包括一个消费者模块和一个生产者模块，消费者模块用于从所述kafka系统中获取数据块，生产模块用于向所述kafka系统中存储处理后的数据块，注册信息中可以包括每个客户端模块的标识信息。

例如，图9为根据本申请一个实施例的处理数据的方法的示意图。在图9中示出了，分布式应用系统中的应用在zookeeper中注册的示意图。

如图9所示，应用1中可以包括客户端模块1和客户端模块2，应用1可以向zookeeper路径下/[Topic]/[app1]/客户端模块标识；应用2中可以包括客户端1和客户端模块2，应用2可以向zookeeper路径下/[Topic]/[app2]/客户端模块标识。

应理解，在zookeeper中分布式系统中的每个应用可以获取多个应用的注册信息，即分布式系统中的任意一个应用在zookeeper中不仅可以获取自己的注册信息，还可以获取其它应用的注册信息。

等待所有的客户端模块注册完成，即注册阶段结束。

S820，主应用从zookeeper获取多个客户端模块的注册信息，该注册信息中可以包括多个客户端模块的标识信息。

在本申请的实施例中，分布式系统中的每一个备应用在zookeeper完成注册时，都会通知主应用，主应用可以从zookeeper中获取多个客户端模块的标识信息。

S830，主应用获取kafka系统中源主题和目标主题的分区信息。

需要说明的是，在本申请的实施例中，源主题可以用于指示多个客户端获取数据块的分区位置信息，目标主题可以用于指示多个客户端模块存储处理的数据块的分区位置信息。即源主题可以是kafka系统中Source Topic中的分区位置信息，目标主题可以是kafka系统中Sink Topic中的分区位置信息。

可选地，在主应用获取kafka系统中的源主题和目标主题的分区信息之前，主应用可以向kafka系统发生请求信息，用于请求获取源主题和目标主题的分区信息。

S840，主应用确定多个客户端模块与源主题、目标主题的对应关系。

例如，主应用获取多个客户端模块的标识信息，主应用根据标识信息进行排序编号，然后可以按照预设规则确定多个客户端模块与源主题、目标主题的对应关系。

例如，可以按照预设规则分区标号％客户端模块编号＝客户端模块标识，其中，％表示求余的运算。主应用也可以根据预设的算法确定多个客户端模块与源主题、目标主题的对应关系。在本申请的实施例中，预设规则可以为预定义的策略，本申请实施例对此不作限定。

例如，图10为根据本申请另一个实施例的处理数据的方法的示意图。在图10中示出了，主应用根据标识信息、预设关系、源主题以及目标主题确定多个客户端模块与源主题、目标主题的对应关系。

如图10所示，应用1中包括客户端模块1和客户端模块2，应用2中包括客户端模块1和客户端模块2。主应用对应用1和应用2中的客户端模块进行排序编号，即将应用1中客户端模块1编号为0，客户端模块2编号为2；将应用2中的客户端模块1编号为1，客户端模块2编号为3。此外，主应用获取源主题中包括分区0、分区1、分区2和分区3的分区位置信息，主应用还获取目标主题中包括分区0、分区1、分区2和分区3的分区位置信息。其中，源主题用于指示多个客户端获取数据块的分区位置信息，目标主题用于指示多个客户端模块存储处理的数据块的分区位置信息。主应用可以按照预设规则分区标号％客户端模块编号＝客户端模块标识确定多个客户端模块与源主题、目标主题的对应关系。

例如，可以按照预设规则分区标号％客户端模块编号＝客户端模块标识确定客户端模块1对应的分区为分区0，即客户端模块1从源主题的分区0中获取数据块信息，在应用1将数据块处理后将该数据块存储至目标主题的分区0中。

例如，分布式应用系统中包括如图10所示的4个应用，源主题中的分区0％客户端模块个数(例如，4个客户端模块)＝0，则将客户端编号0处理的数据块存储至目标主题中的分区0中；源主题中的分区1％客户端模块编号(例如，4个客户端模块)＝1，则将客户端编号1处理的数据块存储至目标主题中的分区1中。应理解，还可以根据其它预定义的策略确定多个客户端模块与源主题、目标主题的对应关系，本申请的实施例对此不作限定。

S850、主应用将确定的分布式应用系统中多个客户端模块与源主题、目标主题的对应关系，将确定的分区对应关系发生至分布式注册服务系统。

S860、分布式应用系统中的至少一个备应用可以在zookeeper中获取客户端与分区位置的对应关系。可选地，在本申请的实施例中，分布式系统中的每一个应用还可以包括分区保序模块，所述分区保序模块用于对处理的数据块进行排序，所述方法还包括：

所述主应用将处理的多个数据块按照不同的分区位置在所述分区保序模块中进行排序。

应理解，应用异步处理数据块时，由于CPU对工作线程的调度具有不确定性，因此可能会导致数据块分区内出现乱序。分区保序模块可以将处理后的数据块进行排序，从而再存储至kafka系统中，确保数据块在每个分区中不会出现乱序。

例如，图11为根据本申请另一个实施例的处理数据的方法的示意图。如图11所示，应用中包括分区保序模块。

数据块由kafka系统中Source Topic的分区poll出来后，经过3个阶段的线程池并行异步处理后，进入分区保序模块，按照分区标识进入对应队列中排序，未完成的数据块需要预留位置。例如，图11所示，分区保序模块中的B6数据块与B4数据块之间预留了B5数据块的位置，A5数据块附近预留了A4数据块的位置，分区保序模块在达到配置的数量或者等待的时间超时将队头中连续的数据块批量写入kafka系统中Sink Topic的分区中，未连续的数据块在分区保序模块中继续等待，直到连续。

例如，如图11中所示，在分区保序模块中第一分区中的A5数据块和A6数据块在分区保序模块中等待数据块数量达到配置数量，例如3个连续序号的数据块时向生产者发送3个应用处理后的数据块，生产者将该3个应用处理后的数据块发送至kafka系统中的目标主题进行存储。

需要说明的是，分区保序模块可以使应用批量的向kafka系统发送处理后的数据块。批量发送可以满足下列任意一个条件：例如，设置时间超时或者消息块的个数达到设置个数，或者预设的某个条件。其中，批量发送的数据块的数量可以进行配置，避免批量发送的数据块的个数较多。批量发送数据块可以是事务操作，成功持久化批量数据块的最大偏移量，失败则退回，等待下次批量发送。

可选地，在本申请的实施例中，分区保序模块中可以包括第一队列和第二队列，其中，第一队列用于存储序号连续的数据块，第二队列用于存储序号不连续的数据块，主应用将处理的多个数据块按照不同的分区位置在所述分区保序模块中进行排序，包括：

所述主应用处理第二数据块；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号比所述第一数据块的序列号大1，则所述主应用将处理的所述第二数据块存放在与所述第一数据块同分区的第一队列中；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号与所述第一数据块的序列号不连续，则所述主应用将处理的所述第二数据块存放在与所述第一数据块同分区的第二队列中。

在所述第二数据块存放在所述第一队列后，所述主应用依次扫描所述第二队列；

将与所述第二数据块连续且比所述第二数据块的序号大1的第三数据块移出所述第二队列；

将所述第三数据块存放在所述第二队列中。

可选地，在本申请的实施例中，当第一队列中的数据块的数量达到预配置的数量；或者当主应用的等待时间超过定时器的预设时长时，主应用将所述分区保序模块中所述第一数据块所在分区的所述第一队列中的数据块根据所述第二预配置关系发送至所述kafka系统。

在本申请的实施例中，分区保序模块中每个分区队列可以由两个队列组成，一个为可以为普通队列，用来存放已经连续的数据块；一个可以为优先级队列(数据偏移量offset小的优先级高)，用来存放非连续的数据块。

应理解，在本申请的实施例中，数据块的序号可以是数据块的偏移量，在同一个分区中，每个数据块的偏移量可以为不同的数值。

一个数据块进入分区保序模块中时，根据数据块的分区标识选择分区队列，与分区连续offset进行比较。如果数据块的offset不连续，则加入优先级队列；如果数据块的offset连续，则直接加入分区连续队列。加入连续队列后，依次检查优先级队列里的数据块是否连续，如果连续则移出优先级队列加入连续队列。当连续队列中的数据块的数量达到配置数量或者等待定时器超时，将连续队里中的数据块按照配置值大小批量发送到SinkTopic的Partition中，成功则删除已发送数据块，持久化offset；失败则等待下次发送。

例如，图12为根据本申请另一个实施例的处理数据的方法的示意图。如图12所示，分区保序模块中可以包括两个队列。

如图12所示，当前状态数据块A1、A2、A3已经存放在连续队列中，连续的最大offset为3，A5、A6在非连续队列中。当A8数据块进入分区保序模块中，与最大连续offset进行比较，不连续，将数据块A8存放在非连续队列中。当A4数据块进入分区保序模块中，与最大连续offset比较连续，加入连续队列，依次扫描优先级队列，发现A4数据块与A5、A6数据块连续，将A5、A6数据块移除出非连续队列加入连续队列，此时可以将最大连续offset值更改为6。连续队列的消息数达到配置值6，批量发送数据块，发送成功后删除连续队列中的A1-A6数据块。

当A7数据块进入分区保序模块中，与最大连续offset比较，连续加入连续队列，依次扫描优先级队列，发现A8数据块连续，将A8数据块移出非连续队列加入连续队列，更新最大连续offset值为8。

应理解，上述具体的举例详细描述本申请实施例只是为了帮助本领域技术人员更好地理解本申请实施例，而非限制本申请实施例的范围。

在本申请的实施例中，通过绑定客户端模块与分区位置的对应关系，解决了rebalance导致数据块跨分区无序问题，保证数据块分区有序；通过分区保序模块确保了在异步并行处理数据块时，同分区数据块的有序排列。从而保证系统高吞吐量、低时延。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

上文详细描述了根据本申请实施例的处理数据的方法，下面将描述根据本申请实施例的处理数据的装置。应理解，本申请实施例的处理数据的装置可以执行前述本申请实施例的各种方法，即以下各种产品的具体工作过程，可以参考前述方法实施例中的对应过程。

图13示出了根据本申请实施例的处理数据的装置500的示意性框图。图13中的处理数据的装置500可对应实现上述处理数据的方法，该装置500可以包括：

收发模块510，用于获取所述装置和至少一个备装置中的多个客户端模块的标识信息；

处理模块520，用于根据所述标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，所述第一客户端为所述多个客户端模块中的任意一个客户端模块，所述第一预配置关系用于指示所述第一客户端模块从所述kafka系统中获取第一数据块的分区位置，所述第二预配置关系用于指示所述第一客户端模块将处理的所述第一数据块存储至所述kafka系统中的分区位置。

本申请实施例的技术方案中，通过绑定客户端模块与分区位置的对应关系，解决了rebalance导致消息跨分区无序问题，保证数据块分区有序。

可选地，所述第一客户端模块包括第一消费模块和第一生产模块，所述第一消费模块用于从所述kafka系统中获取第一数据块，所述第一生产模块用于向所述kafka系统中存储处理后所述第一数据块，所述处理模块520还用于：

确定所述第一消费模块的所述第一预配置关系和所述第一生产模块的第二预配置关系。

可选地，所述处理模块520还用于：

根据所述标识信息和预设关系确定所述第一预配置关系和所述第二预配置关系。

可选地，所述收发模块510还用于：

获取所述kafka系统中源主题和目标主题，所述源主题用于指示所述多个客户端获取数据块的分区位置信息，所述目标主题用于指示所述多个客户端模块存储处理的数据块的分区位置信息。

可选地，所述处理模块520还用于：

根据所述标识信息、所述预设关系、所述源主题以及所述目标主题确定所述第一预配置关系和所述第二预配置关系。

应理解，在本申请的实施例中，预设规则可以为预定义的策略。

可选地，所述收发模块510还用于：

当所述多个客户端模块在zookeeper中完成注册时，从所述zookeeper中获取所述多个客户端模块的标识信息。

可选地，所述收发模块：

向所述zookeeper发送所述第一预配置关系和所述第二预配置关系，用于指示所述多个客户端模块中的任意一个客户端模块与所述kafka系统分区位置的对应关系。

可选地，在本申请的一个实施例中，所述装置和至少一个备装置中的每一个装置还包括：

分区保序模块530，用于将处理的多个数据块按照不同的分区位置进行排序。

在本申请的实施例中，分布式系统中的每一个装置还可以包括分区保序模块，分区保序模块能够在应用采用异步并行处理数据块时，保证数据块不会跨分区乱序，此外还可以保证数据块在分区有序。

例如，图14示出了根据本申请实施例的处理数据的装置500的示意性框图。如图14所示，所述装置包括收发模块510、处理模块520和分区保序模块530。

在本申请的实施例中，分区保序模块530中可以包括第一队列和第二队列，其中，所述第一队列用于存储序号连续的数据块，所述第二队列用于存储序号不连续的数据块，所述处理模块520还应用：

处理第二数据块；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号比所述第一数据块的序列号大1，则所述处理模块将处理的所述第二数据块存放在与所述第一数据块同分区的第一队列中；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号与所述第一数据块的序列号不连续，则所述处理模块将处理的所述第二数据块存放在与所述第一数据块同分区的第二队列中。

可选地，所述处理模块520还用于：

在所述第二数据块存放在所述第一队列后，依次扫描所述第二队列；

将与所述第二数据块连续且比所述第二数据块的序号大1的第三数据块移出所述第二队列；

将所述第三数据块存放在所述第二队列中。

可选地，所述处理模块520还用于：

当所述第一队列中的数据块的数量达到预配置的数量；或

当所述主应用的等待时间超过定时器的预设时长时，所述主应用将所述分区保序模块中所述第一数据块所在分区的所述第一队列中的数据块根据所述第二预配置关系发送至所述kafka系统。

在本申请的实施例中，通过绑定客户端模块与分区位置的对应关系，解决了rebalance导致数据块跨分区无序问题，保证数据块分区有序；通过分区保序模块确保了在异步并行处理数据块时，同分区数据块的有序排列。从而保证系统高吞吐量、低时延。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (22)

1.一种处理数据的方法，其特征在于，所述方法适用于包括主应用和至少一个备应用的分布式系统中，所述主应用和至少一个备应用中的每一个应用包括至少一个客户端模块，所述客户端模块用于获取卡夫卡kafka系统中的数据块和向所述kafka系统存储应用处理后的数据块，所述方法包括：

所述主应用获取所述主应用和至少一个备应用中的多个客户端模块的标识信息；

所述主应用根据所述标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，所述第一客户端模块为所述多个客户端模块中的任意一个，所述第一预配置关系用于指示所述第一客户端模块从所述kafka系统中获取第一数据块的分区位置，所述第二预配置关系用于指示所述第一客户端模块将处理的所述第一数据块存储至所述kafka系统中的分区位置。

2.根据权利要求1所述的方法，其特征在于，所述第一客户端模块包括第一消费模块和第一生产模块，所述第一消费模块用于从所述kafka系统中获取第一数据块，所述第一生产模块用于向所述kafka系统中存储处理后的所述第一数据块，所述主应用根据所述标识信息确定第一客户端模块的第一预配置关系和第二预配置关系包括：

所述主应用确定所述第一消费模块的所述第一预配置关系和所述第一生产模块的第二预配置关系。

3.根据权利要求1或2所述的方法，其特征在于，所述主应用根据所述标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，包括：

所述主应用根据所述标识信息和预设关系确定所述第一预配置关系和所述第二预配置关系。

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

所述主应用获取所述kafka系统中源主题和目标主题，所述源主题用于指示所述多个客户端获取数据块的分区位置信息，所述目标主题用于指示所述多个客户端模块存储处理的数据块的分区位置信息。

5.根据权利要求4所述的方法，其特征在于，所述主应用根据所述标识信息确定所述多个客户端模块中的第一客户端模块的第一预配置关系和第二预配置关系，包括：

所述主应用根据所述标识信息、所述预设关系、所述源主题以及所述目标主题确定所述第一预配置关系和所述第二预配置关系。

6.根据权利要求1或2所述的方法，其特征在于，所述主应用获取所述主应用和至少一个备应用中的多个客户端模块的标识信息，包括：

当所述多个客户端模块在分布式注册服务zookeeper中完成注册时，所述主应用从所述zookeeper中获取所述多个客户端模块的标识信息。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

所述主应用向所述zookeeper发送所述第一预配置关系和所述第二预配置关系，用于指示所述多个客户端模块中的任意一个客户端模块与所述kafka系统分区位置的对应关系。

8.根据权利要求1或2所述的方法，其特征在于，所述分布式系统中的每一个应用还包括分区保序模块，所述分区保序模块用于对处理的数据块进行排序，所述方法还包括：

所述主应用将处理的多个数据块按照不同的分区位置在所述分区保序模块中进行排序。

9.根据权利要求8所述的方法，其特征在于，所述分区保序模块中包括第一队列和第二队列，其中，所述第一队列用于存储序号连续的数据块，所述第二队列用于存储序号不连续的数据块，所述主应用将处理的多个数据块按照不同的分区位置在所述分区保序模块中进行排序，包括：

所述主应用处理第二数据块；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号比所述第一数据块的序列号大1，则所述主应用将处理的所述第二数据块存放在与所述第一数据块同分区的第一队列中；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号与所述第一数据块的序列号不连续，则所述主应用将处理的所述第二数据块存放在与所述第一数据块同分区的第二队列中。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在所述第二数据块存放在所述第一队列后，所述主应用依次扫描所述第二队列；

将与所述第二数据块连续且比所述第二数据块的序号大1的第三数据块移出所述第二队列；

将所述第三数据块存放在所述第二队列中。

11.根据权利要求10所述的方法，其特征在于，所述方法还包括：

当所述第一队列中的数据块的数量达到预配置的数量；或

当所述主应用的等待时间超过定时器的预设时长时，将所述分区保序模块中所述第一数据块所在分区的所述第一队列中的数据块根据所述第二预配置关系发送至所述kafka系统。

12.一种处理数据的装置，其特征在于，所述装置适用于包括所述装置和至少一个备装置的分布式系统中，所述装置和至少一个备装置中的每一个装置包括至少一个客户端模块，所述客户端模块用于获取卡夫卡kafka系统中的数据块和向所述kafka系统存储应用处理后的数据块，所述装置包括：

收发模块，用于获取所述装置和至少一个备装置的多个客户端模块的标识信息；

处理模块，用于根据所述标识信息确定第一客户端模块的第一预配置关系和第二预配置关系，其中，所述第一客户端为所述多个客户端模块中的任意一个客户端模块，所述第一预配置关系用于指示所述第一客户端模块从所述kafka系统中获取第一数据块的分区位置，所述第二预配置关系用于指示所述第一客户端模块将处理的所述第一数据块存储至所述kafka系统中的分区位置。

13.根据权利要求12所述的装置，其特征在于，所述第一客户端模块包括第一消费模块和第一生产模块，所述第一消费模块用于从所述kafka系统中获取第一数据块，所述第一生产模块用于向所述kafka系统中存储处理后所述第一数据块，所述处理模块还用于：

确定所述第一消费模块的所述第一预配置关系和所述第一生产模块的所述第二预配置关系。

14.根据权利要求12或13所述的装置，其特征在于，所述处理模块还用于：

根据所述标识信息和预设关系确定所述第一预配置关系和所述第二预配置关系。

15.根据权利要求14所述的装置，其特征在于，所述收发模块还用于：

获取所述kafka系统中源主题和目标主题，所述源主题用于指示所述多个客户端获取数据块的分区位置信息，所述目标主题用于指示所述多个客户端模块存储处理的数据块的分区位置信息。

16.根据权利要求15所述的装置，其特征在于，所述处理模块还用于：

根据所述标识信息、所述预设关系、所述源主题以及所述目标主题确定所述第一预配置关系和所述第二预配置关系。

17.根据权利要求12或13所述的装置，其特征在于，所述收发模块还用于：

当所述多个客户端模块在zookeeper中完成注册时，从所述zookeeper中获取所述多个客户端模块的标识信息。

18.根据权利要求17所述的装置，其特征在于，所述收发模块还用于：

向所述zookeeper发送所述第一预配置关系和所述第二预配置关系，指示所述多个客户端模块中的任意一个客户端模块与所述kafka系统分区位置的对应关系。

19.根据权利要求12或13所述的装置，其特征在于，所述装置还包括：

分区保序模块，用于将处理的多个数据块按照不同的分区位置进行排序。

20.根据权利要求19所述的装置，其特征在于，所述分区保序模块中包括第一队列和第二队列，其中，所述第一队列用于存储序号连续的数据块，所述第二队列用于存储序号不连续的数据块，所述处理模块还应用：

处理第二数据块；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号比所述第一数据块的序列号大1，则所述处理模块将处理的所述第二数据块存放在与所述第一数据块同分区的第一队列中；

若所述第二数据块与所述第一数据块位于同一分区，且所述第二数据块的序号与所述第一数据块的序列号不连续，则所述处理模块将处理的所述第二数据块存放在与所述第一数据块同分区的第二队列中。

21.根据权利要求20所述的装置，其特征在于，所述处理模块还用于：

在所述第二数据块存放在所述第一队列后，依次扫描所述第二队列；

将与所述第二数据块连续且比所述第二数据块的序号大1的第三数据块移出所述第二队列；

将所述第三数据块存放在所述第二队列中。

22.根据权利要求21所述的装置，其特征在于，所述处理模块还用于：

当所述第一队列中的数据块的数量达到预配置的数量；或

当所述装置的等待时间超过定时器的预设时长时，所述装置将所述分区保序模块中所述第一数据块所在分区的所述第一队列中的数据块根据所述第二预配置关系发送至所述kafka系统。

Images