一种支持多核平台下数据流处理的线程管理系统的制作方法
【专利摘要】本发明涉及一种支持多核平台下数据流处理的线程管理系统，其特征在于，包括线程池管理器、请求队列、事件队列及包含有多个线程的线程池。本发明的有益效果是：本发明解决了多核平台复杂查询中数据流处理的性能问题。本发明能够在不改变原有Esper内部代码与结构的前提下，只通过外加线程管理来管理查询线程，对Esper本身没有“污染”。与现有技术相比，本发明通过外加线程管理以适应多核平台复杂查询，具有事件查询吞吐量高，事件响应时间快等特点，进一步可以推广到其它类Esper引擎数据流查询工具。
【专利说明】
一种支持多核平台下数据流处理的线程管理系统
技术领域
[0001]本发明涉及一种适用于多核平台下Esper数据流处理引擎的线程管理系统。
【背景技术】
[0002]复杂事件处理(Complex Event Processing，CEP)是一种实时从大量事件数据流中挖掘复杂模式的技术。事件流处理(Event Stream Processing，ESP)是一种从大量事件数据流中过滤，分析有意义的事件，并能够实时取得信息的技术。CEP和ESP系统在流数据处理和实时响应方面非常出色。Esper是基于CEP(复杂事件处理)和ESP(事件流处理)应用程序的组件，可以监测事件流并在特定事件发生时触发某些动作执行。Esper引擎的出现是为了满足事件进行分析并做出反应等类似应用需求而产生的。此类应用要求实时或者接近实时地处理事件，这些应用具有高吞吐量、低响应时间和复杂计算等特点。
[0003]Esper官方性能数据显示，在双2GHz CPU的Intel系统测试环境下，处理速率超过500000个事件/秒;但是，这些测试只是针对一些相对简单的查询得到的统计结果，而在现实应用中，Esper处理的查询通常为较为复杂的查询而非简单查询。现实应用案例表明，Esper在多核平台下复杂查询中表现出来的性能并不能充分利用软、硬件资源。究其原因是Esper在多核平台下采用的线程管理设计中存在着不足而导致的。
【发明内容】
[0004]本发明要解决的技术问题是:让Esper充分利用多核平台的软硬件资源，提高查询效率以及提升事件处理能力。
[0005]为了解决上述技术问题，本发明的技术方案是提供了一种支持多核平台下数据流处理的线程管理系统，其特征在于，包括线程池管理器、请求队列、事件队列及包含有多个线程的线程池，其中:
[0006]事件队列，用于存入事件，每个事件均具有一个事件类型，不同事件队列对应不同的事件类型，事件抵达Esper引擎后，由线程池管理器接管Esper引擎原有的事件发送方法，将当前事件依据事件类型存入对应的事件队列中；
[0007]线程池中的线程的状态在休眠与唤醒之间切换:当线程池管理器初始化后，或当处于唤醒状态的线程无法申请到请求队列中的请求后，或当线程依据申请到的请求中包含的事件类型访问对应的事件队列，而对应的事件队列为空时，线程的状态变更为休眠；
[0008]当请求被创建并插入请求队列后，由线程池管理器唤醒线程池中所有处于休眠状态的线程；
[0009]请求队列，线程池中处于唤醒状态的所有线程互斥访问请求队列，申请请求队列中的请求，申请到请求的线程依据请求中包含的事件类型访问对应的事件队列，获得非空事件队列中的事件，获得事件的线程调用Esper引擎中的查询处理功能模块进行事件的查询处理，在Esper引擎完成对当前事件的处理后，由线程将当前事件对应的请求返还至请求队列，其中，请求被创建的条件为:线程池管理器接收到事件后，依据当前事件对应的事件类型查询对应的事件队列，仅在被查询的事件队列为空时，创建一个请求并插入请求队列中，该请求包含当前事件的事件类型；
[0010]请求被丢弃的条件为:当线程依据申请到的请求中包含的事件类型访问对应的事件队列，而对应的事件队列为空时，当前线程申请到的请求被丢弃。
[0011]优选地，所述事件抵达Esper引擎后，由所述线程池管理器对事件进行包装处理。
[0012]本发明的有益效果是:本发明解决了多核平台复杂查询中数据流处理的性能问题。本发明能够在不改变原有Esper内部代码与结构的前提下，只通过外加线程管理来管理查询线程，对Esper本身没有“污染”。与现有技术相比，本发明通过外加线程管理以适应多核平台复杂查询，具有事件查询吞吐量高，事件响应时间快等特点，进一步可以推广到其它类Esper引擎数据流查询工具。
【附图说明】
[0013]图1为本发明的线程管理系统的线程管理模块结构图；
[0014]图2为本发明中线程池管理器的工作流程图；
[0015]图3为本发明中工作线程的工作流程图。
【具体实施方式】
[0016]下面结合具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。
[0017]本发明设计的线程管理系统主要是在原查询系统上添加一个线程管理模块，线程管理模块的线程池管理器维护请求队列，合理调度工作线程WorkThread完成事件的查询并输出查询结果。线程管理模块整体框图见图1。
[0018]本发明的线程管理模块中核心为线程池管理器ThreadPool，它担负着协调工作线程运行和管理请求队列Reques Queue等工作。线程池管理器主要功能有:初始化线程管理模块中的数据结构；接管Esper引擎发送事件的方法;判断请求队列是否添加新的请求任务。本发明中的线程池管理器的工作流程见图2。
[0019]启动Esper数据流引擎工作后，在事件抵达Esper引擎之前需要读取Esper引擎内部参数，如EPL(Event Processing Language)的数目、注册的数据流类型数目等，依据Esper内部参数初始化线程池管理器，其中包括事件队列数目、量化并初始化工作线程等等。
[°02°] 事件抵达Esper引擎后，线程池管理器介入Esper引擎发送事件方法和Esper事件查询过程之间，线程池管理器接管Esper引擎原有事件发送的方法，将事件进行包装处理。线程池管理器依据包装后的Event查询与当前事件的事件类型相对应的事件队列，如果对应的事件队列非空，表明已有线程为当前事件类型服务，那么不触发请求创建，仅将事件存入对应的事件队列中。当事件对应的队列为空时，线程池管理器创建一个请求，该请求包含当前事件的事件类型并插入请求队列，由线程池管理器唤醒线程池中处于休眠状态的所有工作线程去竞争请求队列中的请求(线程池中的工作线程自线程池管理器初始化之后一直处于休眠状态)。同时，当前事件也被存入事件队列。
[0021]处于唤醒状态的所有工作线程互斥地访问请求队列，申请请求，仅有一个工作线程获得请求，其余未获得请求的被唤醒的工作线程继续保持休眠状态等待下一次的唤醒去竞争获得请求。在此竞争中获得请求的工作线程依据请求中包含的事件类型信息去访问对应的事件队列，以获得事件队列中待处理查询的事件。若此时工作线程访问的事件队列为空，则丢弃当前请求，并且将当前工作线程设置为休眠状态，等待下一次被唤醒。成功获得事件的工作线程进行事件调用Esper引擎中的查询处理功能模块进行事件的查询处理，话句话说即转交给Esper引擎进行事件的查询以及结果集的输出。在Esper引擎完成对此事件的处理后，工作线程返还与当前事件对应的请求至请求队列，然后此线程与其它处于唤醒状态的工作线程一样地互斥访问请求队列申请请求，如此循环过程。本发明工作重心是针对线程以及事件进行管理，因此不会更改Esper引擎本身的查询事件过程，以此来保证事件查询结果的正确性以及对E s P e r的无侵害性。
[0022]由此可见，本发明中的线程池管理器的调度策略为:对于同种事件类型的事件工作线程先来先服务查询，并且不会有两个工作线程服务一种类型事件类型查询。不同事件类型之间的工作线程互不影响并发执行查询。
[0023]本发明中涉及的数据结构为请求队列、事件队列、工作线程的信号量。
[0024]I)请求队列
[0025]请求队列是本发明提供的线程管理系统中的一个重要概念。在本发明中，请求不仅是一个任务信号的标识，而且还关联着标识事件流的类型信息，即事件类型。请求队列中每个请求对应一种事件类型，它表示相应类型的事件是否在请求处理，即如果请求队列出现一个请求，则标识某个事件流正需要一个工作线程进行查询处理，工作线程只需要获得此请求即可依据请求包含的事件类型准确地获得待处理的事件。
[0026]对队列中请求置位有下列两种情况:(I)工作线程的返还；(2)线程池管理器的添加。如此设计既在访问上保证了线程安全性，又利于工作线程获得事件去查询，更重要的是，此设计避免了Esper引擎原有设计上的缺陷，从而提高了事件的查询效率。
[0027]2)事件队列；
[0028]本发明在线程管理模块中设计了 Java语言的ConcurrentHashMap类型的一个实体，功能是将所有的事件队列存储在此实体中，采用此类型设计保证了并发的工作线程在访问上的互斥性。Map中的元素类型为事件类型(EventType )_>事件队列(BlockingQueue)的Key->ValUe键值队。如此在事件经由线程管理器存储时可以访问Map查询到对应事件类型的队列中，并将之存储。事件队列的类型为BlockingQueue，如此利用了 Java阻塞队列的优势。此Map实体的实例化是在线程池管理器启用时进行的初始化阶段依据Esper引擎参数进行的。
[0029]3)工作线程的信号量；
[0030]在线程管理模块中维持着一个字符串常量EXECUTE_TASK_LOCK，EXECUTE_TASK_LOCK是工作线程被唤醒和休眠依据。工作线程的信号量的设计主要是为了保证EXECUTE_TASK_L0CK的互斥访问。工作线程唤醒以及休眠使用了 Java语言中的Object的wait/notify特性。
[0031]线程池管理器在初始化阶段中量化并启用工作线程时，初始化每个工作线程，每个工作线程试图访问请求队列获取请求失败则休眠。线程池管理器判断抵达的事件需要添加一个请求到请求队列时，唤醒休眠线程。
[0032]本发明所述的线程管理模块，整个管理器的设置是介于Esper引擎事件接收和事件具体查询模块之间，无需修改Esper引擎具体查询过程代码，不破坏Esper引擎内数据结构，因而数据流管理方法在保证查询结果的正确性前提下具有非常好的架构灵活性。
【主权项】
1.一种支持多核平台下数据流处理的线程管理系统，其特征在于，包括线程池管理器、请求队列、事件队列及包含有多个线程的线程池，其中: 事件队列，用于存入事件，每个事件均具有一个事件类型，不同事件队列对应不同的事件类型，事件抵达Esper引擎后，由线程池管理器接管Esper引擎原有的事件发送方法，将当前事件依据事件类型存入对应的事件队列中； 线程池中的线程的状态在休眠与唤醒之间切换:当线程池管理器初始化后，或当处于唤醒状态的线程无法申请到请求队列中的请求后，或当线程依据申请到的请求中包含的事件类型访问对应的事件队列，而对应的事件队列为空时，线程的状态变更为休眠； 当请求被创建并插入请求队列后，由线程池管理器唤醒线程池中所有处于休眠状态的线程； 请求队列，线程池中处于唤醒状态的所有线程互斥访问请求队列，申请请求队列中的请求，申请到请求的线程依据请求中包含的事件类型访问对应的事件队列，获得非空事件队列中的事件，获得事件的线程调用Esper引擎中的查询处理功能模块进行事件的查询处理，在Esper引擎完成对当前事件的处理后，由线程将当前事件对应的请求返还至请求队列，其中，请求被创建的条件为:线程池管理器接收到事件后，依据当前事件对应的事件类型查询对应的事件队列，仅在被查询的事件队列为空时，创建一个请求并插入请求队列中，该请求包含当前事件的事件类型； 请求被丢弃的条件为:当线程依据申请到的请求中包含的事件类型访问对应的事件队列，而对应的事件队列为空时，当前线程申请到的请求被丢弃。2.如权利要求1所述的一种支持多核平台下数据流处理的线程管理系统，其特征在于，所述事件抵达Esper引擎后，由所述线程池管理器对事件进行包装处理。
【文档编号】G06F15/16GK106095535SQ201610404750
【公开日】2016年11月9日
【申请日】2016年6月8日
【发明人】王洪亚, 刘杰, 陆可镜, 常姗
【申请人】东华大学