本发明涉及数据处理领域，尤其涉及一种业务数据处理方法及装置。
背景技术：
Kafka是分布式发布-订阅消息系统。Kafka是一个分布式的、可划分的、冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。
在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能、低延迟的不停流转，因此会带来组网复杂以及编网复杂的问题。而Kafka可以降低系统组网复杂度，降低编程复杂度，各个子系统不再是相互协商接口，各个子系统可以类似插口插在插座上一样插在Kafka上，由Kafka承担高速数据总线的作用。
如图1所示，Kafka的整体架构非常简单，是一个显式分布式架构，如下为Kafka中的几个基本概念，Topic：特指Kafka处理的消息源(feeds of messages)的不同分类。Partition：Topic物理上的分组，一个Topic可以分为多个Partition，每个Partition是一个有序的队列。Partition中的每条消息都会被分配一个有序的id。Message：消息，是通信的基本单位，每个Producer可以向一个Topic发布一些消息。Producers：消息和数据生产者，向Kafka的一个Topic发布消息。Consumers：消息和数据消费者，订阅Topics并处理其发布的消息。Broker：缓存代理，Kafka集群中的一台或多台服务器统称为Broker。
Kafka中，生产者端Producer、代理端Broker和消费者端Consumer都可以有多个。Producer、Consumer是实现Kafka注册的接口，数据从Producer发送到Broker，Broker承担一个中间缓存和分发的作用。Broker用于分发注册到系统中的Consumer。Broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。
Kafka主要特点：同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息(占50MB的存储容量)，每秒处理55万消息(占110MB的存储容量)；可进行持久化操作。将消息持久化到硬盘，因此可用于批量消费；分布式系统，易于向外扩展。所有的Producer、Broker和Consumer均为分布式的。无需停机即可扩展机器；消息被处理的状态是在Consumer端维护，而不是由服务器端维护，当失败时能自动平衡；支持online和offline的场景。
在包含Kafka架构在内的一些系统架构中，现有的Consumers的消息订阅消费模式都是耦合在具体业务场景中进行消息处理的，没有一个通用的高并发处理框架来通过简单的配置文件即可实现业务能力的服务器节点数量自动扩展，因此会导致消息处理积压，服务器资源消耗过高，消息处理不够及时。
技术实现要素：
本发明要解决的技术问题是，提供一种业务数据处理方法及装置，克服现有技术中的分布式发布-订阅消息系统所产生的消息挤压的缺陷。
本发明采用的技术方案是，业务数据处理方法，包括：
针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，其中，每一个业务处理单元都对应一个或多个订阅消息队列，业务处理单元用于处理订阅消息队列中的消息；
至少根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
进一步的，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，包括：
按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；
根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，包括：
在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
进一步的，方法，还包括：在检测代理端中与业务处理单元对应的订阅消息队列中的消息数量之前，在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围；
调整业务处理单元的业务处理能力，包括：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，扩展业务处理单元使用的线程数量，直到业务处理单元使用的线程数量等于消息数量为止，其中，业务处理单元使用的线程数量的上限为业务处理单元使用线程的数量范围的最大值；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，收缩业务处理单元使用的线程数量，直到业务处理单元使用的线程数量等于消息数量为止，其中，业务处理单元使用的线程数量的下限为业务处理单元使用线程的数量范围的最小值。
进一步的，设业务处理单元使用一台服务器时在第二设定时长内处理消息数量上限为M，M为正整数；配置文件中设定有业务处理单元使用的服务器数量上限N，N为正整数；
调整业务处理单元的业务处理能力，还包括：
若在第一设定时长内检测到的消息数量增长量大于等于n个M，n为正整数，则以N为上限，为业务处理单元扩展使用n+1台服务器；
若在第一设定时长内检测到的消息数量减少量大于等于n个M，，则以N为上限，为业务处理单元缩减使用n台服务器。
进一步的，方法，还包括：检测业务处理单元使用的服务器的负载；
根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
进一步的，根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力，包括：
步骤A1：按照设定的检测周期检测消息数量以及业务处理单元使用的服务器的负载，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量或者在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载大于设定的高负载阈值，则执行步骤A2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量且在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载持续小于设定的低负载阈值，则执行步骤A3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤A1；
步骤A2：扩展业务处理单元的业务处理能力，跳转步骤A1；
步骤A3：收缩业务处理单元的业务处理能力，跳转步骤A1。
本发明还提供一种业务数据处理装置，包括：
检测模块，用于针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，其中，每一个业务处理单元都对应一个或多个订阅消息队列，业务处理单元用于处理订阅消息队列中的消息；
判断模块，用于至少根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调用调整模块；
调整模块，用于调整业务处理单元的业务处理能力。
进一步的，检测模块，用于：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；
判断模块，用于：在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
进一步的，装置，还包括：
配置模块，用于在检测模块检测代理端中与业务处理单元对应的订阅消息队列中的消息数量之前，在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围；
调整模块，用于：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，扩展业务处理单元使用的线程数量，直到业务处理单元使用的线程数量等于消息数量为止，其中，业务处理单元使用的线程数量的上限为业务处理单元使用线程的数量范围的最大值；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，收缩业务处理单元使用的线程数量，直到业务处理单元使用的线程数量等于消息数量为止，其中，业务处理单元使用的线程数量的下限为业务处理单元使用线程的数量范围的最小值。
进一步的，设业务处理单元使用一台服务器时在第二设定时长内处理消息数量上限为M，M为正整数；配置文件中设定有业务处理单元使用的服务器数量上限N，N为正整数；
调整模块，还用于：
若在第一设定时长内检测到的消息数量增长量大于等于n个M，n为正整数，则以N为上限，为业务处理单元扩展使用n+1台服务器；
若在第一设定时长内检测到的消息数量减少量大于等于n个M，，则以N为上限，为业务处理单元缩减使用n台服务器。
进一步的，检测模块，还用于：检测业务处理单元使用的服务器的负载；
判断模块，用于根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力。
进一步的，检测模块，用于按照设定的检测周期检测消息数量以及业务处理单元使用的服务器的负载；
判断模块，用于若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量或者在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载大于设定的高负载阈值，则判定需要扩展业务处理单元的业务处理能力，继续调用检测模块；
若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量且在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载持续小于设定的低负载阈值，则判定需要收缩业务处理单元的业务处理能力，继续调用检测模块；
若在第一设定时长内的检测结果不符合前述情况，则继续调用检测模块。
采用上述技术方案，本发明至少具有下列优点：
本发明业务数据处理方法及装置，通过对业务处理单元所使用的服务器的负载以及分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩、及横向服务器节点的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
附图说明
图1为Kafka的整体架构示意图；
图2为本发明第一实施例的业务数据处理方法流程图；
图3为本发明第二、三实施例的业务数据处理方法流程图；
图4为本发明第四实施例的业务数据处理方法流程图；
图5为本发明第五实施例的业务数据处理装置组成结构示意图；
图6为本发明第六、七、八实施例的业务数据处理装置组成结构示意图；
图7为本发明第九实施例的业务数据处理装置组成结构示意图；
图8为本发明第九实施例的服务器的管理流程图。
具体实施方式
为更进一步阐述本发明为达成预定目的所采取的技术手段及功效，以下结合附图及较佳实施例，对本发明进行详细说明如后。
本发明第一实施例，一种业务数据处理方法，如图2所示，包括以下具体步骤：
步骤S101，针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；业务处理单元使用的每个线程能够处理一条消息，处理完后该线程资源会释放。
可选的，在步骤S101中，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，包括：
按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；
步骤S102，至少根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
可选的，在步骤S102中，根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，包括：
在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
可选的，调整业务处理单元的业务处理能力包括：扩展或收缩业务处理单元所使用的线程和/或服务器的数量。且尽量先考虑扩展或收缩业务处理单元所使用的线程，当通过扩展或收缩业务处理单元所使用的线程仍然不能贴近业务处理单元所需的业务处理能力的情况下，再考虑扩展或收缩业务处理单元所使用的服务器数量。
本发明实施例的业务数据处理方法，通过对分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第二实施例，一种业务数据处理方法，如图3所示，包括以下具体步骤：
步骤S201，在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围；
步骤S202，针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；
可选的，在步骤S202中，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，包括：
按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
步骤S203，根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
可选的，在步骤S203中，根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，包括：
在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
本发明实施例之所以未在检测到消息数量大于或者小于业务处理单元当前所使用的线程数量时就立刻判定需要调整业务处理单元的业务处理能力，是因为代理端中与业务处理单元对应的订阅消息队列中的消息数量可能会出现不稳地的波动，如果紧跟波动进行业务能力的调整，调整的过于频繁，就会增加业务处理单元的资源消耗。
可选的，在步骤S203中，调整业务处理单元的业务处理能力，包括：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止。
例如：本实施例的检测和调整过程可以按照如下的循环操作：
步骤A1：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则执行步骤A2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则执行步骤A3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤A1；
步骤A2：以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，跳转步骤A1；
步骤A3：以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，跳转步骤A1。
本发明实施例与第一实施例大致相同，区别在于，本发明实施例提供了通过简单的配置文件的方式配置业务处理单元使用线程的数量范围，该配置文件还可配置对于业务处理单元的检测和业务能力调整策略，具体体现在步骤S202和步骤S203的具体操作中。另外，本发明实施例还提供给了更详细的检测调整过程。
本发明实施例的业务数据处理方法，通过对分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第三实施例，一种业务数据处理方法，如图3所示，包括以下具体步骤：
步骤S201，在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围；
步骤S202，针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量；
可选的，在步骤S202中，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，包括：
按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
步骤S203，根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
可选的，在步骤S203中，根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，包括：
在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
可选的，在步骤S203中，调整业务处理单元的业务处理能力，包括：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止。
例如：本实施例的检测和调整过程可以按照如下的循环操作：
步骤A1：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则执行步骤A2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则执行步骤A3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤A1；
步骤A2：以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，跳转步骤A1；
步骤A3：以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，跳转步骤A1。
可选的，设业务处理单元使用一台服务器时在第二设定时长内处理消息数量上限为M，M为正整数；配置文件中设定有业务处理单元使用的服务器数量上限N，N为正整数；
在步骤S203中，调整业务处理单元的业务处理能力，还包括：
若在第一设定时长内检测到的消息数量增长量大于等于n个M，n为正整数，则以N为上限，为业务处理单元扩展使用n+1台服务器；
若在第一设定时长内检测到的消息数量减少量大于等于n个M，，则以N为上限，为业务处理单元缩减使用n台服务器。
本发明实施例与第二实施例大致相同，区别在于，本发明实施例在调整业务处理单元的业务处理能力的过程中还提供对于业务处理单元所使用的服务器节点的扩展或收缩，当一台服务器所能提供的线程已经不足以支持一个业务处理单元的运行时，就需要扩展该业务处理单元使用的服务器个数了，反之，就需要缩减。例如：一个业务处理单元使用一台服务器时在3分钟内处理消息数量上限为10万条，假设当前该业务处理单元仅使用了一台服务器，而当前检测到代理端中与业务处理单元对应的订阅消息队列中的消息数量为26万条时，就需要增加两台服务器供该业务处理单元使用。
本发明实施例的业务数据处理方法，通过对业务处理单元所使用的服务器的负载以及分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩、及横向服务器节点的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第四实施例，一种业务数据处理方法，如图4所示，包括以下具体步骤：
步骤S301，在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围、以及业务处理单元使用的服务器数量上限N，N为正整数；
步骤S302，针对消费者端的任一业务处理单元，检测业务处理单元使用的服务器的负载、以及代理端中与业务处理单元对应的订阅消息队列中的消息数量；
可选的，在步骤S302中，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，包括：
按照设定的检测周期检测业务处理单元使用的服务器的负载、以及代理端中与业务处理单元对应的订阅消息队列中的消息数量。
步骤S303，根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力，若是，则调整业务处理单元的业务处理能力。
可选的，在步骤S303中，根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力，包括：
步骤B1：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量以及业务处理单元使用的服务器的负载，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量或者在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载大于设定的高负载阈值，则执行步骤B2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量且在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载持续小于设定的低负载阈值，则执行步骤B3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤B1；
步骤B2：扩展业务处理单元的业务处理能力，跳转步骤B1；
步骤B3：收缩业务处理单元的业务处理能力，跳转步骤B1。
本发明实施例与第三实施例大致相同，区别在于，本发明实施例要结合代理端中与业务处理单元对应的订阅消息队列中的消息数量以及业务处理单元使用的服务器的负载，共同来判断是否需要调整业务处理单元的业务处理能力，由于业务处理单元处理的业务的种类不同，其逻辑复杂程度也不一样，对服务器资源的消耗程度也不相同，服务器资源包括CPU占用率、内存资源等，实际业务运行中，很可能会出现与业务处理单元对应的订阅消息队列中的消息数量不多，但业务处理单元使用的某些服务器的负载已经超负荷的情况，此时应该依据服务器的负载情况进行服务器数量扩展；对于缩减服务器数量的时候，应该既考虑与业务处理单元对应的订阅消息队列中的消息数量的情况又考虑业务处理单元使用的服务器的负载情况，来共同决定是否需要缩减服务器的数量，这样才能准确的反映业务处理单元实际需要的业务处理能力。
本发明实施例的业务处理方法，通过对业务处理单元所使用的服务器的负载以及分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩、及横向服务器节点的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第五实施例，与第一实施例对应，本实施例介绍一种业务数据处理装置，如图5所示，包括以下组成部分：
1)检测模块501，用于针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。业务处理单元使用的每个线程能够处理一条消息，处理完后该线程资源会释放。
可选的，检测模块501，用于：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
2)判断模块502，用于至少根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调用调整模块503；
可选的，判断模块502，用于：在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
3)调整模块503，用于调整业务处理单元的业务处理能力。
可选的，调整模块503用于扩展或收缩业务处理单元所使用的线程和/或服务器的数量。
本发明实施例的业务数据处理装置，通过对分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第六实施例，与第二实施例对应，本实施例介绍一种业务数据处理装置，如图6所示，包括以下组成部分：
1)配置模块601，用于在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围。业务处理单元使用的每个线程能够处理一条消息，处理完后该线程资源会释放。
2)检测模块602，用于针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
可选的，检测模块602，用于：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
2)判断模块603，用于根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调用调整模块604；
可选的，判断模块603，用于：在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
本发明实施例之所以未在检测到消息数量大于或者小于业务处理单元当前所使用的线程数量时就立刻判定需要调整业务处理单元的业务处理能力，是因为代理端中与业务处理单元对应的订阅消息队列中的消息数量可能会出现不稳地的波动，如果紧跟波动进行业务能力的调整，调整的过于频繁，就会增加业务处理单元的资源消耗。
3)调整模块604，用于调整业务处理单元的业务处理能力。
可选的，调整模块604，用于：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止。
比如：调整模块604执行如下的循环操作：
步骤A1：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则执行步骤A2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则执行步骤A3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤A1；
步骤A2：以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，跳转步骤A1；
步骤A3：以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，跳转步骤A1。
本发明实施例与第五实施例大致相同，区别在于，本发明实施例提供了通过简单的配置文件的方式配置业务处理单元使用线程的数量范围，该配置文件还可配置对于业务处理单元的检测和业务能力调整策略，具体体现在检测模块、判断模块和调整模块的具体操作中。另外，本发明实施例还提供给了更详细的检测调整过程。
本发明实施例的业务数据处理装置，通过对分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第七实施例，与第三实施例对应，本实施例介绍一种业务数据处理装置，如图6所示，包括以下组成部分：
1)配置模块601，用于在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围。业务处理单元使用的每个线程能够处理一条消息，处理完后该线程资源会释放。
2)检测模块602，用于针对消费者端的任一业务处理单元，检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
可选的，检测模块602，用于：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量。
3)判断模块603，用于根据检测到的消息数量判断是否需要调整业务处理单元的业务处理能力，若是，则调用调整模块604；
可选的，判断模块603，用于：在第一设定时长内，若检测到的消息数量持续大于或者持续小于业务处理单元当前所使用的线程数量，则判定需要调整业务处理单元的业务处理能力；第一设定时长大于设定的检测周期。
本发明实施例之所以未在检测到消息数量大于或者小于业务处理单元当前所使用的线程数量时就立刻判定需要调整业务处理单元的业务处理能力，是因为代理端中与业务处理单元对应的订阅消息队列中的消息数量可能会出现不稳地的波动，如果紧跟波动进行业务能力的调整，调整的过于频繁，就会增加业务处理单元的资源消耗。
4)调整模块604，用于调整业务处理单元的业务处理能力。
可选的，调整模块604，用于：
若检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止；
若检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，直到消息数量等于业务处理单元使用的线程数量为止。
比如：调整模块604执行如下的循环操作：
步骤A1：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量，若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量，则执行步骤A2；若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量，则执行步骤A3；若在第一设定时长内的检测结果不符合前述情况，则重复执行步骤A1；
步骤A2：以数量范围的最大值为上限，扩展业务处理单元使用的线程数量，跳转步骤A1；
步骤A3：以数量范围的最小值为下限，收缩业务处理单元使用的线程数量，跳转步骤A1。
可选的，设业务处理单元使用一台服务器时在第二设定时长内处理消息数量上限为M，M为正整数；配置文件中设定有业务处理单元使用的服务器数量上限N，N为正整数；
调整模块604，还用于：
若在第一设定时长内检测到的消息数量增长量大于等于n个M，n为正整数，则以N为上限，为业务处理单元扩展使用n+1台服务器；
若在第一设定时长内检测到的消息数量减少量大于等于n个M，，则以N为上限，为业务处理单元缩减使用n台服务器。
本发明实施例与第六实施例大致相同，区别在于，本发明实施例在调整业务处理单元的业务处理能力的过程中还提供对于业务处理单元所使用的服务器节点的扩展或收缩，当一台服务器所能提供的线程已经不足以支持一个业务处理单元的运行时，就需要扩展该业务处理单元使用的服务器个数了，反之，就需要缩减。例如：一个业务处理单元使用一台服务器时在3分钟内处理消息数量上限为10万条，假设当前该业务处理单元仅使用了一台服务器，而当前检测到代理端中与业务处理单元对应的订阅消息队列中的消息数量为26万条时，就需要增加两台服务器供该业务处理单元使用。
本发明实施例的业务数据处理装置，通过对业务处理单元所使用的服务器的负载以及分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩、及横向服务器节点的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第八实施例，与第四实施例对应，本实施例介绍一种业务数据处理装置，如图6所示，包括以下组成部分：
1)配置模块601，用于在本地内存中加载配置文件；配置文件中设定有业务处理单元使用线程的数量范围、以及业务处理单元使用的服务器数量上限N，N为正整数。业务处理单元使用的每个线程能够处理一条消息，处理完后该线程资源会释放。
2)检测模块602，用于针对消费者端的任一业务处理单元，检测业务处理单元使用的服务器的负载、以及代理端中与业务处理单元对应的订阅消息队列中的消息数量；。
可选的，检测模块602，用于：按照设定的检测周期检测代理端中与业务处理单元对应的订阅消息队列中的消息数量、以及业务处理单元使用的服务器的负载。
3)判断模块603，用于根据检测到的消息数量以及业务处理单元使用的服务器的负载判断是否需要调整业务处理单元的业务处理能力，若是，则调用调整模块604；
可选的，判断模块603，用于若在第一设定时长内检测到的消息数量持续大于业务处理单元当前所使用的线程数量或者在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载大于设定的高负载阈值，则判定需要扩展业务处理单元的业务处理能力，继续调用检测模块602；
若在第一设定时长内检测到的消息数量持续小于业务处理单元当前所使用的线程数量且在第一设定时长内检测到的业务处理单元使用的至少一台服务器的负载持续小于设定的低负载阈值，则判定需要收缩业务处理单元的业务处理能力，继续调用检测模块602；
若在第一设定时长内的检测结果不符合前述情况，则继续调用检测模块602。
4)调整模块604，用于调整业务处理单元的业务处理能力。
可选的，调整业务处理单元的业务处理能力包括：扩展或收缩业务处理单元所使用的线程和/或服务器的数量。且尽量先考虑扩展或收缩业务处理单元所使用的线程，当通过扩展或收缩业务处理单元所使用的线程仍然不能贴近业务处理单元所需的业务处理能力的情况下，再考虑扩展或收缩业务处理单元所使用的服务器数量。
本发明实施例与第七实施例大致相同，区别在于，本发明实施例要结合代理端中与业务处理单元对应的订阅消息队列中的消息数量以及业务处理单元使用的服务器的负载，共同来判断是否需要调整业务处理单元的业务处理能力，由于业务处理单元处理的业务的种类不同，其逻辑复杂程度也不一样，对服务器资源的消耗程度也不相同，服务器资源包括CPU占用率、内存资源等，实际业务运行中，很可能会出现与业务处理单元对应的订阅消息队列中的消息数量不多，但业务处理单元使用的某些服务器的负载已经超负荷的情况，此时应该依据服务器的负载情况进行服务器数量扩展；对于缩减服务器数量的时候，应该既考虑与业务处理单元对应的订阅消息队列中的消息数量的情况又考虑业务处理单元使用的服务器的负载情况，来共同决定是否需要缩减服务器的数量，这样才能准确的反映业务处理单元实际需要的业务处理能力。
本发明实施例的业务数据处理装置，通过对业务处理单元所使用的服务器的负载以及分布式发布-订阅消息系统中的业务处理单元对应的订阅消息队列当前消息数量进行监测，对业务处理单元的业务处理能力进行纵向线程的扩展或收缩、及横向服务器节点的扩展或收缩。通过这样的方式可以使业务处理更加灵活，在业务空闲的时候自动缩减服务器节点，在业务繁忙的时候自动扩展服务器节点，从而实现业务处理能力的自动伸缩，避免了分布式发布-订阅消息系统所产生的消息挤压。
本发明第九实施例，本实施例是在上述实施例的基础上，结合附图7～8介绍一个本发明的应用实例。
如图7所示，本发明实施例提供一种避免消费者端业务处理性能瓶颈的装置，以解决大数据消息平台(kafka)订阅后消费者端消息业务处理性能瓶颈的问题。通过此装置自动根据业务处理单元当前订阅消息队列深度进行线程的纵向扩展和服务器节点的自动横向扩展。
业务处理单元启动后，本发明实施例的避免消费者端业务处理性能瓶颈的装置也就随即启动。该装置对应的软件产品可以包含业务处理单元，也可以不包含业务处理单元。本方案最大的优点在于，业务处理单元通过实现装置提供的方法即装置通过接口继承的方式，使得业务处理单元具备横向和纵向的扩展能力。另外，装置具有通用的高并发处理结构，通过简单的配置文件即可实现业务能力的服务器节点数量自动扩展，避免消息处理积压、服务器资源消耗过高以及消息处理不够及时等情况的出现。
服务器状态检测模块：用于检测服务器当前负载，可以通过shell方式获取服务器当前支持的业务处理单元的信息。对于业务处理单元来说，可以获得该业务处理单元所用的服务器的负载情况。
消息队列检测模块：用于检测当前订阅队列消息挤压深度，即当前订阅队列消息的数量。
线程池：实现单个服务器节点内线程动态扩展。
消息订阅模块：用于从代理端为业务处理单元订阅消息队列，业务处理单元无需重复编码，由该装置统一处理。
服务器列表模块：提供服务器列表，包含当前服务器集群最大服务器节点数，还用于动态扩展服务器节点。
缓存模块：用于将配置文件中的基础配置加载到本地内存，该基础配置中包含实现业务的方法以及公共数据，供其他模块共享使用，
服务器线程负载检测模块：用于检测业务处理单元下的线程数。
业务处理单元：通过实现装置提供的方法即装置通过接口继承的方式，对订阅到的消息进行正常的业务处理，使得业务处理单元具备横向和纵向的扩展能力。此处不需要关注高并发及横向扩展功能，开发人员只需要实现针对订阅的消息进行的业务处理流程即可。
如图8所示，横向---服务器的管理：
步骤1，业务处理单元1启动后，避免消费者端业务处理性能瓶颈的装置也随之启动。
步骤2，首先启动消息订阅模块，消息订阅模块从代理端拉取消息时需要用到缓存模块中事先配置的公共数据，并占用线程处理消息，此时线程池启动，并由服务器线程负载检测模块检测出业务处理单元1的线程使用情况。
步骤3，启动队列深度检测模块和服务器状态检测模块。
步骤4，通过该装置中的队列深度检测模块、服务器状态检测模块以及服务器列表模块决策是否需要扩展新的服务器节点来横向扩展。
步骤5，当上述决策模块检测到需要扩展新的服务器节点时，通过脚本的方式进行服务器2-处理单元1的自动启动。从而实现服务器节点的动态扩展。
同理，当决策模块检测到需要减少该处理单元1的服务器节点时，通过脚本的方式进行服务器2-业务处理单元1的关闭，从而实现服务器节点的资源的合理利用。
还可以将释放出来的服务器节点分配给其他业务处理单元，通过脚本删除对应的程序生成的锁文件，框架内部有锁文件检查守护进程负责检测是否停止当前节点进程。停止后会释放对应的堆内存及CPU资源，在此之后，即可将该资源分配给其他处理单元。
纵向-----线程的管理：
以当前配置文件中配置的线程池的最大和最小线程数为限，进行线程池的扩展与收缩。
本发明实施例通过该避免消费者端业务处理性能瓶颈的装置实现对kafka消息的订阅，业务层只需要根据配置文件的配置实现消息的自动拉取。
通过对消息队列深度的检测，服务器状态的检测，实现服务器节点的动态扩展，使业务层能够专注业务处理，无需关注高并发下动态扩展方面的复杂实现。
通过对多线程的业务处理单元的封装，屏蔽业务层对多线程实现。实现单服务器节点业务处理单元内高并发的实现。
通过具体实施方式的说明，应当可对本发明为达成预定目的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图示仅是提供参考与说明之用，并非用来对本发明加以限制。