Spring Batch2的一些新的特性

1.  Spring Batch2的新的特性

Spring Batch2.0有六个主要的主题:

Ø  Java 5

Ø  非顺序的步骤

Ø  基于块的处理

Ø  元数据扩展

Ø  伸缩性

Ø  可配置

1.1. Java 5

Spring Batch的1.x版本基于Java 1.4,这样限制了框架使用1.5的一些新的特性,比如:泛型和参数化类型。整个框架都做了调整来适应新的特性。所心,1.4已经不再支持了。开发者使用的大多数接口已经泛型化。例如,ItemReader接口在1.x中,如下面所示:

 

就像你所看到的那样,read方法返回了一个Object。2.0中,如下所示:

 

可以看到,2.0已经支持泛型,参见read函数的返回值,你也可以看到,mark和reset已经被移除,这是因为处理流程上的改变,这会在后面提到,很多其它的函数也像这样进行了更改。

1.2. 基于块的处理

以前,默认的处理规则就是基于项的处理。

 

在基于项的处理中,ItemReader返回了一个对象,然后交给了ItemWriter,当数量达到了commit interval规定的值的时候,进行阶段性的提交。例如,如果commit interval设置成5,ItemReader和ItemWriter每个都被调用5次,下面就是一个代码的结构:

 

ItemReader和ItemWriter都被完全绑定起来:

 

由于处理的范围是一个item,支持回滚的场景就需要额外的方法,这就是mark,reset,flush和clear。如果成功读写了两条数据,而第三条在写的时候出现了错误,事务就需要回滚,在这种情况下,writer的clear方法就会被执行,表示它应当清空自己的buffer,然后ItemReader的reset方法就会被调用,表示它应当回到上一个mark方法被调用的点。

在2.0里面,策略被改成了基于块的结构:

 

使用上面相同的例子,如果commit interval是5的话,read就会被执行5次,但write只会被执行一次。这些数据项会被放进一个list里面,然后被同时写出,下面是一个能够简单说明问题的例子:

 

这个修改不仅让处理和伸缩更加简单,而且也让ItemReader和ItemWriter更加的清晰。

 

就像你所看到的,接口不再有mark,reset,flush和clear方法,这让开发者感觉readers和writers的创建更加的直接。对于ItemReader接口,只会向前走。如果需要回滚的话,框架会自动为开发者缓存数据项。ItemWriter是如此的简单,由于它一次拿到了个块的数据,不再是一次一个,在把控制权交还给step之前,可以输出任何资源。

1.2.1.  项处理器

以前,Steps仅仅只有两个依赖,ItemReader和ItemWriter。

上面的基础配置确实是十分的健壮,但是,有很多的情形,item需要在交给writer之前进行转换。在1.x中,这需要用组合模式进行实现。

 

这的确起作用,但是这需要在reader、writer和step之间增加新的一层。更重要的是,ItemWriter需要作为一个ItemStream在Step中进行单独地注册。因为这个原因,ItemTransfomer改名为ItemProcessor,而且移到了和ItemReader及ItemWriter的同一层。

 

1.3. 配置扩展

2.0以前,唯一的配置Spring Batch的方法就是像SpringBean一样的配置方式。但是在2.0,有了新的名字空间。例如,在1.1里面,像下面这样配置一个任务。

 

 

在2.0里面,等效的配置如下:

 

1.4. 元数据访问提升

JobRepository接口,实现在基本的使用Job元数据进行CRUD操作,而且,这在查询的时候也会很有帮助。因为这个原因,JobExplorer和JobOperator才被定义出来。

 

1.5. 非序列的步执行

在step的配置方面,2.0也有了很大的提升,而不在仅仅是一条线的往下走。

 

现在是可以选择的:

 

使用新的名字空间,可选择的step变得十分的容易。

 

1.6. 扩展性

Spring Batch1.x期望作为一个单独的vm,也许是多线程模型,但是很多的多进程并发的特性被编译进去。基于Spring Batch服务特性的目标,很多项目实现了一个可伸缩的解决方案,来保证进程只会在一个有顺序的情况下发生。在2.0里面,这些显得现的更加的透明,有两种可伸缩的方案,remote chunking和partitioning。

1.7. Remote Chunking

Remote Chunking是一种把一个step的工作进行分解的技术,而且不需要任何额外的对数据结构的了解。一个输入源可以被动态的拆分,一个进程进行读,任务的处理被分发到远端的工作线程。远端实现了一个监听模式,响应一个请求,处理数据,发送一个异步的回复,请求和回复的传送必须被分发者和一个单独的消费者保持起来。这种特性使得任何JMS的实现都变得可读。由于Spring Batch是在Spring Integration的顶层构建的Remote Chunking,因此对于消息中间件来说,它是不可知的。

1.8. Partitioning

对于输入的数据的结构有一些了解的话,Partitioning(分发)也是一个可以尝试的途经。像一系列的主键,或者一个要处理的文件的名字。这个模型的优点就是,每个处理程序,就像一个单独的Job,它们不需要实现任何特殊的新的模式,这让它们很容易配置和测试。原则上来讲,Partitioning比Remote Chunking有更好的伸缩性,因为这没有在一个地方进行文件读操作的瓶颈。

在Spring Batch2里面,Partitioning需要两个接口的支持:PartitionHandler和StepExecutionSplitter,PartitionHandler知道执行的结构,它必须发送请求到远端的steps,收集执行结果。PartitionHandler是一个SPI,Spring Batch提供了一个可在本地运行的实现,通过一个TaskExecutor。这十分有用,如果这是一个IO十分频繁的操作的话,由于在这些情况下远程执行只增加了复杂度,却没有性能上的提升。其它的实现可能是和运行时的结构进行绑定。

标签