一种分布式任务系统及应用该系统的数据处理方法

文档序号:6468782阅读:192来源:国知局

专利名称::一种分布式任务系统及应用该系统的数据处理方法
技术领域
:本发明涉及分布式任务
技术领域
,特别涉及一种分布式任务系统及应用该系统的数据处理方法。
背景技术
:在小型的服务器系统中,一般抓取数据和数据处理都由一台服务器来实现,但随着数据量的增大,一台服务器的效能已经不能满足系统的要求。于是业界通常将多台服务器布置为分布式任务系统来进行相关数据处理,并且,为了避免多台服务器处理时会存在重复性的问题,通常采用时间片段锁。务,被多个服务器并发处理的情况;为了避免被多个服务器并发处理,根据任务的处理间隔时长决定时间片段的长度,从而以时间片段的方式来保证只有多台服务器中一台执行操作。例如,设定的时间片段范围为l分钟(具体根据任务的处理间隔时长决定),在这1分钟内,通过数据库锁的方式来保证只能有1台服务器来执行定时任务;具体处理方式可以为以一张数据库表控制并发,这个表很小(数据列少、数据量只有一条记录),只需要记录上1分钟执行的机器名、机器IP或者MAC地址即可;在进入下l分钟后,所有的服务器都来尝试锁该笔记录,由于数据库锁的排他性,只会有l台服务器取得对该笔记录的排他锁,之后更新锁时间和机器IP或MAC地址;那么别的服务器一旦锁不住则自动退出尝试并暂停任务;等待下1分钟再次尝试取得排他锁,以此类推。基于上述原理,现有的分布式任务系统及数据处理方案如下将服务器群即多台服务器从逻辑上分为两层,第一层为数据抓取层,第二层为数据处理层;物理结构上所有的服务器都可以作为上述逻辑两层中的口一贝;当定时任务开始时,通过时间片段锁方式,确保一定时间段内如i分钟内,只能有一台服务器充当数据抓取的角色,由其与数据库联系进行数据抓3取,根据优化的配置将所抓取的数据进行分发,由数据处理层的服务器执行具体的数据处理。比如某个海量数据处理任务,硬件方面投入了20台服务器,组成对该任务的执行服务器群;以当前时间10:OO整为例,在10:00-10:01之间,只能有一台服务器锁住该任务(可通过数据库表加锁的方式实现),由该服务器一次性读取10000条数据;按照10000/20分成500个批次分发给数据处理层的多台服务器共同执行,以达到并发处理的目的。现有的分布式任务系统及其数据处理方式至少存在如下的缺点1、在同一时间点只能有一台服务器与数据库进行交互进行业务数据抓取,那么这台服务器就会成为系统的瓶颈所在;即使增加更多的硬件资源如继续投入服务器,也无法解决在同一时间点的最大并发处理量,不能够实现水平扩容;2、对于现有的分布式任务系统,在程序编写中势必会根据当前的业务数据量及所有的硬件资源综合考虑,推导出当前最优的业务数据分配策略;而一旦增加了一台或多台服务器,程序分配算法势必要从整体业务逻辑上重新设计,以达到理论上的最优,即在增加服务器时需要修改程序代码。
发明内容本申请实施例在于提供一种分布式任务系统及应用该系统的数据处理方法,在保证分布式任务系统不会重复处理相同数据的同时,还能够避免系统瓶颈最大限度的实现多服务器并发处理,实现水平扩容,并且,在增加服务器后无需修改程序代码。本申请实施例提供的一种分布式任务系统,包括子任务拆分层,用于采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件;数据装载层,用于接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据;数据处理层,用于对接收到的待处理数据进行业务处理。其中,所述查询过滤条件根据业务规则确定。其中,所述分布式任务系统中包括若干台服务器;所述若干台服务器中的一台或多台作为所述子任务拆分层、数据装载层和^t据处理层中的一层或多层。本申请实施例还提供了一种数据处理方法,包括将分布式任务系统中的服务器从逻辑上分为子任务拆分层、数据装载层和数据处理层三层;所述方法还包括所述子任务拆分层采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件;所述数据装载层接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据;所述数据处理层对接收到的待处理数据进行业务处理。其中,所述查询过滤条件根据业务规则确定。其中,所述业务规则包括数据创建时间,或者,数据的处理优先级,或者,数据创建时间和数据的处理优先级。其中,所述若干台服务器中的一台或多台作为所述子任务拆分层、数据装载层和凄t据处理层中的一层或多层。应用本申请实施例所提供的分布式任务系统及应用该系统的数据处理方法,在保证分布式任务系统不会重复处理相同数据的同时,还能够避免系统瓶颈最大限度的实现多服务器并发处理,达到了业务需求与系统性能的最优设计。再有,应用本申请实施例,由于子任务拆分层不与数据库进行交互,避免了瓶颈问题,可以对服务器硬件资源的无限水平扩容,无需修改代码;适用各种大、中型分布式系统。再有,本申请实施例提供的三层逻辑结构中,每层的处理方式由具体业务决定,如不同的任务、不同的数据量级,其查询过滤条件拆分方式、数据装载方式以及处理方式都会有不同,开发人员只需针对特定任务,编写每层的具体业务处理逻辑,经过筒单的配置即可将该任务无缝集成至本申请的分布式任务处理体系中;同时由于本申请不侵入每个任务的具体业务逻辑,具有很好的可扩展性。再有,本申请实施例不仅提高了处理数据的效能,而且具有;f艮强的通用性,所有的分布式任务系统都可以使用此方案进行处理。为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作筒单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以才艮据这些附图获得其他的附图。图1是根据本申请实施例的一种分布式任务系统结构示意图;图2是根据本申请实施例的数据处理方法流程图。具体实施例方式下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。参见图l,其是^f艮据本申请实施例的一种分布式任务系统结构示意图。本例中,假设分布式任务系统包括10台服务器,以下为描述方便对其进行编号,分别为SERVER-1-1、SERVER-1隱2、SERVER-1-3、SERVER-1陽4、SERVER-1匿5、SERVER-2-1、SERVER-2-2、SERVER-2-3、SERVER画2-4、SERVER-2-5。首先,将分布式任务系统中的若干台服务器从逻辑上分为三层子任务拆分层、数据装载层和数据处理层,以上编号后的服务器任何一台都可以为其中一层或多层,也即所述若干台服务器中的一台或多台可以作为所述子任务拆分层、数据装载层和数据处理层中的一层或多层。这样,本申请实施例所提供的分布式任务系统包括子任务拆分层101、数据装载层102和数据处理层103,其中,子任务拆分层101,为分布式任务的启动入口,用于采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件。该查询过滤条件根据业务规则确定,其中的业务规则包括但不限于数据创建时间,或者,数据的处理优先级,或者,凝:据创建时间和数据的处理优先级。可以理解,任何待处理的数据,都可以根据一定的业务规则对其进行拆分,也就是分割、细化数据队列的查询过滤条件。子任务拆分层101所拆分出的每个查询过滤条件,是由各个系统的具体业务决定的,本文并不对具体的业务规则做限定。根据数据的创建时间进行拆分是指每个查询过滤条件只包含一定时间内的数据,比如只包含10:00:00~10:01:00的数据集。根据数据的处理优先级进行拆分是指每个过滤条件中包含了指定处理优先级的数据集。这里的优先级在银行系统中可以反映为需要对诸如大客户的数据优先处理,系统在产生数据时就指定了数据的处理优先级。当然,子任务拆分层101还可以根据数据的创建时间和处理优先级的复合方式拆分出查询过滤条件。下面以最常见的根据数据的创建时间确定查询过滤条件为例进行说明。比如某大型系统今日处理了会计账1000万笔,需要日终与银行的流水进行勾兑;以系统当前时间为起点,至前10分钟内;每隔1分钟建立一个查询过滤条件;这里的时间间隔可以根据需要任意设定,如以IO秒钟、30秒钟为时间分割点等等;这样会产生若干个数据过滤查询条件。需要说明的是,子任务拆分层101不进行数据装载和处理工作,只是按照业务规则拆分查询过滤条件,并将拆分后的查询过滤条件分发至服务群内。至于如何具体拆分查询过滤条件是根据业务需要所决定的,本文对此并不做限定。正因为子任务拆分层101仅^t查询过滤条件的拆分操作,因而其不与凄t据库联系。需要说明的是,子任务拆分层101与现有的数据抓取层同样釆取基于时间片段锁的方式防止同一时间内对相同数据的重复处理;不同之处在于子任务拆分层不进行数据的装载,不与数据库交互;而是将数据装载的查询过滤条件分发至数据装载层,由数据装载层进行后续处理。数据装载层102,用于接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,4艮据数据分配策略下发所述待处理数据。7数据装载层102接收来自子任务拆分层101下发查询过滤条件,由于每个查询过滤条件是相互独立的,比如10:00:00-10:00:59的查询过滤条件和10:01:00-10:01:59的查询过滤条件是相互独立的,因而其所对应的数据是不重叠的,所以不存在多台服务器重复处理相同数据的风险,这样,处于数据装载层的各服务器可以自行进行数据装载,不存在处理瓶颈。数据装载层102所采用的分配策略是根据实际需要设定或计算得出的,本实施例对具体的分配策略不做限定。数据处理层103,用于对接收到的待处理数据进行业务处理。数据处理层103是分布式任务系统的真正业务处理部分,不同的业务有其相应的业务处理方式;由于前两层的防重复处理与并发处理机制的保证,此层可专心处理业务凄t据,本实施例对具体的业务处理方式不^L限定。可见,应用本申请实施例所提供的分布式任务系统,在保证分布式任务系统不会重复处理相同数据的同时,还能够避免系统瓶颈最大限度的实现多服务器并发处理,达到了业务需求与系统性能的最优设计。再有,应用本申请实施例所提供的分布式任务系统,由于子任务拆分层不与数据库进行交互,避免了瓶颈问题,可以对服务器硬件资源无限水平扩容,无需修改代码;适用各种大、中型分布式系统。再有,本申请实施例提供的三层逻辑结构中,每层的处理方式由具体业务决定,如不同的任务、不同的数据量级,其查询过滤条件拆分方式、彩:据装载方式以及处理方式都会有不同,开发人员只需针对特定任务,编写每层的具体业务处理逻辑,经过简单的配置即可将该任务无缝集成至本申请的分布式任务处理体系中;同时由于本申请不侵入每个任务的具体业务逻辑,具有很好的可扩展性。再有,本申请实施例不仅提高了处理数据的效能,而且具有很强的通用性,所有的分布式任务系统都可以使用此方案进行处理。参见图2,其是才艮据本申请实施例的数据处理方法流程图。本例中,已将分布式任务系统中的若干台服务器从逻辑上分为三层即,子任务拆分层、数据装载层和数据处理层,上述若干台服务器中的一台或多台可以作为所述子任务拆分层、数据装载层和数据处理层中的一层或多层,也就是说,对于一台物理存在的服务器,其在逻辑上既可能处于子任务拆分层,也可能处于数据装载层,还可能处于数据处理层,还可能处于上述三层的多层中。本实施例具体包括以下步骤步骤201,子任务拆分层采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件,该查询过滤条件可以是一个对象。子任务拆分层为分布式任务的启动入口,其中的查询过滤条件根据业务规则确定,该业务规则包括但不限于数据创建时间,或者,数据的处理优先级,或者,数据创建时间和数据的处理优先级。可以理解,任何待处理的数据,都可以根据一定的业务规则对其进行拆分,也就是分割、细化数据队列的查询过滤条件。子任务拆分层所拆分出的每个查询过滤条件,是由各个系统的具体业务决定的,本文并不对具体的业务规则做限定。需要说明的是,子任务拆分层不进行数据装载和处理工作,只是按照业务规则拆分查询过滤条件,并将拆分后的查询过滤条件分发至服务群内。至于如何具体拆分查询过滤条件是根据业务需要所决定的,本文对此并不做限定。正因为子任务拆分层仅做查询过滤条件的拆分操作,因而其不与数据库联系。需要说明的是,子任务拆分层与现有的数据抓取层同样采取基于时间片段锁的方式防止同一时间内对相同数据的重复处理;不同之处在于子任务拆分层不进行数据的装载,不与数据库交互;而是将数据装载的查询过滤条件分发至数据装载层,由数据装载层进行后续处理。步骤202,数据装载层接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据。可以理解,子任务拆分层和数据装载层之间的交互是通过一个个具体的查询过滤条件的,简而言之,当需要使用分布式任务时,开发人员会事先根据业务特征来设计数据查询过滤条件,子任务拆分层产生多个所设计的数据查询过滤条件项,当数据装载层接收到这样的条件项时,就能够形成本次需要查询的具体结构4匕查询i吾言(SQL,StructureQueryLanguage)。例如现有一个交易超时提醒用户的分布式任务,每日零点执行,取得上一日零点至当前时间内的所有超时数据,并进行业务处理;数据量大约有1000万笔;经过评估,得知数据的分布比较均匀,每分钟内产生的业务数据在1000笔左右,由此设定的数据查询过滤条件为每个子任务只装载l分钟内的业务数据;此时的数据查询过滤条件可以是一个java^象,其含有创建时间起点、创建时间终点两个属性;自定义两个属性的名称,如minGmtCreate、maxGmtCreate;定义数据装载层的查询SQL:select*fromtable—awheregmt—create>andgmt—create<=;子任务拆分层每次进行拆分时,产生若干个java^"象对数据装载层下发、、.......数据装载层拿到这样的查询过滤条件后,将每个对象内的minGmtCreate、maxGmtCreate属性填充至预定义的查询SQL中,得到最终的查询SQL:select*fromtable—awheregmt—create>'10:00:00,andgmt—create<='10:01:00,;select*fromtable—awheregmt—create〉'10:01:00,andgmt—create<='10:02:00、select*fromtable—awheregmt_create>,10:02:00,andgmt—create<='10:03:00,;由于每个查询过滤条件是相互独立的,比如10:00:00-10:00:59的查询过滤条件和10:01:00-10:01:59的查询过滤条件是相互独立的,因而其所对应的数据是不重叠的,所以不存在多台服务器重复处理相同数据的风险,这样,处于数据装载层的各服务器可以自行进行数据装载,不存在处理瓶颈。上述分配策略是根据实际需要设定或计算得出的,本实施例对具体的分配策略不做限定。步骤203,数据处理层对接收到的待处理数据进行业务处理。10数据处理层103是分布式任务系统的真正业务处理部分,不同的业务有其相应的业务处理方式;由于前两层的防重复处理与并发处理^L制的保证,此层可专心处理业务数据,本实施例对具体的业务处理方式不做限定。至此,完成了数据的处理。应用本申请实施例所提供的数据处理方法,在保证分布式任务系统不会重复处理相同数据的同时,还能够避免系统瓶颈最大限度的实现多服务器并发处理,达到了业务需求与系统性能的最优设计。再有,应用本申请实施例所提供的数据处理方法,由于子任务拆分层不与数据库进行交互,避免了瓶颈问题,可以对服务器硬件资源的无限水平扩容,无需修改代码;适用各种大、中型分布式系统。再有,本申请实施例提供的三层逻辑结构中,每层的处理方式由具体业务决定,如不同的任务、不同的数据量级,其查询过滤条件拆分方式、数据装载方式以及处理方式都会有不同,开发人员只需针对特定任务,编写每层的具体业务处理逻辑,经过简单的配置即可将该任务无缝集成至本申请的分布式任务处理体系中;同时由于本申请不侵入每个任务的具体业务逻辑,具有很好的可扩展性。再有,本申请实施例不〗义提高了处理tt据的效能,而且具有^f艮强的通用性,所有的分布式任务系统都可以使用此方案进行处理。本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于计算机可读取存储介质中,这里所称得的存储介质,如ROM/RAM、磁碟、光盘等。以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本申请的保护范围内。权利要求1、一种分布式任务系统,其特征在于,包括子任务拆分层,用于采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件;数据装载层,用于接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据;数据处理层,用于对接收到的待处理数据进行业务处理。2、根据权利要求1所述的分布式任务系统,其特征在于,所述查询过滤条件根据业务规则确定。3、根据权利要求1所述的分布式任务系统,其特征在于,所述分布式任务系统中包括若干台服务器;所述若干台服务器中的一台或多台作为所述子任务拆分层、数据装载层和数据处理层中的一层或多层。4、一种数据处理方法,其特征在于,包括将分布式任务系统中的若干台服务器从逻辑上分为子任务拆分层、数据装载层和数据处理层三层;所述方法还包括所述子任务拆分层采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件;所述数据装载层接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据;所述数据处理层对接收到的待处理数据进行业务处理。5、根据权利要求4所述方法,其特征在于,所述查询过滤条件根据业务步见则确定。6、根据权利要求5所述方法,其特征在于,所述业务规则包括数据创建时间,或者,数据的处理优先级,或者,数据创建时间和数据的处理优先级。7、根据权利要求4所述方法,其特征在于,所述若干台服务器中的一台或多台作为所述子任务拆分层、凝:据装载层和邀:据处理层中的一层或多层。全文摘要本申请公开了一种分布式任务系统及应用该系统的数据处理方法,所述系统包括子任务拆分层,用于采取时间片段锁的方式,将待处理的业务数据对应的查询过滤条件进行拆分,下发所述拆分后的查询过滤条件;数据装载层,用于接收所述查询过滤条件,从数据库中获取与所述查询过滤条件对应的待处理数据,根据数据分配策略下发所述待处理数据;数据处理层,用于对接收到的待处理数据进行业务处理。应用本申请,在保证分布式任务系统不会重复处理相同数据的同时,还能够避免系统瓶颈最大限度的实现多服务器并发处理,达到了业务需求与系统性能的最优设计,可以实现硬件资源水平无限扩展。文档编号G06F17/30GK101464884SQ20081018659公开日2009年6月24日申请日期2008年12月31日优先权日2008年12月31日发明者寄许申请人:阿里巴巴集团控股有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1