在大型企業中，由於業務複雜、資料量大、資料格式不同、資料互動格式繁雜，並非所有的操作都能通過互動介面進行處理。而有一些操作需要定期讀取大批量的資料，然後進行一系列的後續處理。這樣的過程就是“批處理”。
批處理應用通常有以下特點：
- 資料量大，從數萬到數百萬甚至上億不等；
- 整個過程全部自動化，並預留一定介面進行自定義配置；
- 這樣的應用通常是週期性執行，比如按日、周、月執行；
- 對資料處理的準確性要求高，並且需要容錯機制、回滾機制、完善的日誌監控等。
什麼是Spring batch
Spring batch是一個輕量級的全面的批處理框架，它專為大型企業而設計，幫助開發健壯的批處理應用。Spring batch為處理大批量資料提供了很多必要的可重用功能，比如日誌追蹤、事務管理、job執行統計、重啟job和資源管理等。同時它也提供了優化和分片技術用於實現高效能的批處理任務。
它的核心功能包括：
- 事務管理
- 基於塊的處理過程
- 宣告式的輸入/輸出操作
- 啟動、終止、重啟任務
- 重試/跳過任務
- 基於Web的管理員介面
筆者所在的部門屬於國外某大型金融公司的CRM部門，在日常工作中我們經常需要開發一些批處理應用，對Spring Batch有著豐富的使用經驗。近段時間筆者特意總結了這些經驗。
使用Spring Batch 3.0以及Spring Boot
在使用Spring Batch時推薦使用最新的Spring Batch 3.0版本。相比Spring Batch2.2，它做了以下方面的提升：
- 支援JSR-352標準
- 支援Spring4以及Java8
- 增強了Spring Batch Integration的功能
- 支援JobScope
- 支援SQLite
支援Spring4和Java8是一個重大的提升。這樣就可以使用Spring4引入的Spring boot元件，從而開發效率方面有了一個質的飛躍。引入Spring-batch框架只需要在build.gradle中加入一行程式碼即可：
|
1 |
compile("org.springframework.boot:spring-boot-starter-batch") |
而增強Spring Batch Integration的功能後，我們就可以很方便的和Spring家族的其他元件整合，還可以以多種方式來呼叫job，也支援遠端分割槽操作以及遠端塊處理。
而支援JobScope後我們可以隨時為物件注入當前Job例項的上下文資訊。只要我們指定Bean的scope為job scope，那麼就可以隨時使用jobParameters和jobExecutionContext等資訊。
|
1 2 3 4 5 6 7 8 9 10 |
@Component @JobScope public class CustomClass { @Value("#{jobParameters[jobDate]}") private String jobDate; @Value("#{jobExecutionContext['input.name']}.") private String fileName; } |
使用Java Config而不是xml的配置方式
之前我們在配置job和step的時候都習慣用xml的配置方式，但是隨著時間的推移發現問題頗多。
- xml檔案數急劇膨脹，配置塊長且複雜，可讀性很差；
- xml檔案缺少語法檢查，有些低階錯誤只有在執行整合測試的時候才能發現；
- 在xml檔案中進行程式碼跳轉時IDE的支援力度不夠；
我們漸漸發現使用純Java類的配置方式更靈活，它是型別安全的，而且IDE的支援更好。在構建job或step時採用的流式語法相比xml更加簡潔易懂。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@Bean public Step step(){ return stepBuilders.get("step") .chunk(1) .reader(reader()) .processor(processor()) .writer(writer()) .listener(logProcessListener()) .faultTolerant() .skipLimit(10) .skip(UnknownGenderException.class) .listener(logSkipListener()) .build(); } |
在這個例子中可以很清楚的看到該step的配置，比如reader/processor/writer元件，以及配置了哪些listener等。
本地整合測試中使用記憶體資料庫
Spring batch在執行時需要資料庫支援，因為它需要在資料庫中建立一套schema來儲存job和step執行的統計資訊。而在本地整合測試中我們可以藉助Spring batch提供的記憶體Repository來儲存Spring batch的任務執行資訊，這樣既避免了在本地配置一個資料庫，又可以加快job的執行。先為Job的配置類新增擴充套件類：DefaultBatchConfigurer。
|
1 2 3 4 |
public class CustomJobConfiguration extends DefaultBatchConfigurer { ... } |
我們在build.gradle中加入對hsqldb的依賴：
|
1 |
runtime(‘org.hsqldb:hsqldb:2.3.2’) |
然後在測試類中新增對DataSource的配置。
|
1 2 3 4 5 6 7 |
@EnableAutoConfiguration @EnableBatchProcessing @DataJpaTest @Import({DataSourceAutoConfiguration.class, BatchAutoConfiguration.class}) public class TestConfiguration { } |
並且在applicaton.properties配置中新增初始化Database的配置：
|
1 |
spring.batch.initializer.enable=true |
合理的使用Chunk機制
Spring batch在配置Step時採用的是基於Chunk的機制。即每次讀取一條資料，再處理一條資料，累積到一定數量後再一次性交給writer進行寫入操作。這樣可以最大化的優化寫入效率，整個事務也是基於Chunk來進行。
當我們在需要將資料寫入到檔案、資料庫中之類的操作時可以適當設定Chunk的值以滿足寫入效率最大化。但有些場景下我們的寫入操作其實是呼叫一個web service或者將訊息傳送到某個訊息佇列中，那麼這些場景下我們就需要設定Chunk的值為1，這樣既可以及時的處理寫入，也不會由於整個Chunk中發生異常後，在重試時出現重複呼叫服務或者重複傳送訊息的情況。
使用Listener來監視job執行情況並及時做相應的處理
Spring batch提供了大量的Listener來對job的各個執行環節進行全面的監控。
在job層面Spring batch提供了JobExecutionListener介面，其支援在Job開始或結束時進行一些額外處理。在step層面Spring batch提供了StepExecutionListener，ChunkListener，ItemReadListener，ItemProcessListener，ItemWriteListener，SkipListener等介面，同時對Retry和Skip操作也提供了RetryListener及SkipListener。
通常我們會為每個job都實現一個JobExecutionListener，在afterJob操作中我們輸出job的執行資訊，包括執行時間、job引數、退出程式碼、執行的step以及每個step的詳細資訊。這樣無論是開發、測試還是運維人員都對整個job的執行情況瞭如指掌。
如果某個step會發生skip的操作，我們也會為其實現一個SkipListener，並在其中記錄skip的資料條目，用於下一步的處理。
實現Listener有兩種方式，一種是繼承自相應的介面，比如繼承JobExecutionListener介面，另一種是使用annoation（註解）的方式。經過實踐我們認為使用註解的方式更好一些，因為使用介面你需要實現介面的所有方法，而使用註解則只需要對相應的方法新增annoation即可。
下面的這個類採用了繼承介面的方式，我們看到其實我們只用到了第一個方法，第二個和第三個都沒有用到。但是我們必須提供一個空的實現。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
public class CustomSkipListener implements SkipListener { @Override public void onSkipInRead(Throwable t) { // business logic } @Override public void onSkipInWrite(String item, Throwable t) { // no need } @Override public void onSkipInProcess(String item, Throwable t) { // no need } } |
而使用annoation的方式可以簡寫為：
|
1 2 3 4 5 6 |
public class CustomSkipListener { @OnSkipInRead public void onSkipInRead(Throwable t) { // business logic } } |
使用Retry和Skip增強批處理工作的健壯性
在處理百萬級的資料過程過程中難免會出現異常。如果一旦出現異常而導致整個批處理工作終止的話那麼會導致後續的資料無法被處理。Spring Batch內建了Retry（重試）和Skip（跳過）機制幫助我們輕鬆處理各種異常。我們需要將異常分為三種型別。第一種是需要進行Retry的異常，它們的特點是該異常可能會隨著時間推移而消失，比如資料庫目前有鎖無法寫入、web服務當前不可用、web服務滿載等。所以對它們適合配置Retry機制。第二種是需要Skip的異常，比如解析檔案的某條資料出現異常等，因為對這些異常即使執行Retry每次的結果也都是相同，但又不想由於某條資料出錯而停止對後續資料的處理。第三種異常是需要讓整個Job立刻失敗的異常，比如如果出現了OutOfMemory的異常，那麼需要整個Job立刻終止執行。
一般來說需要Retry的異常也要配置Skip選項，從而保證後續的資料能夠被繼續處理。我們也可以配置SkipLimit選項保證當Skip的資料條目達到一定數量後及時終止整個Job。
有時候我們需要在每次Retry中間隔做一些操作，比如延長Retry時間，恢復操作現場等，Spring Batch提供了BackOffPolicy來達到目的。下面是一個配置了Retry機制、Skip機制以及BackOffPolicy的step示例。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@Bean public Step step(){ return stepBuilders.get("step") .chunk(1) .reader(reader()) .processor(processor()) .writer(writer()) .listener(logProcessListener()) .faultTolerant() .skipLimit(10) .skip(UnknownGenderException.class) .skip(ServiceUnavailableException.class) .retryLimit(5) .retry(ServiceUnavailableException.class) .backOffPolicy(backoffPolicy) .listener(logSkipListener()) .build(); } |
使用自定義的Decider來實現Job flow
在Job執行過程中不一定都是順序執行的，我們經常需要根據某個job的輸出資料或執行結果來決定下一步的走向。以前我們會把一些判斷放置在下游step中進行，這樣可能會導致有些step實際執行了，但其實並沒有做任何事情。比如一個step執行過程中會將失敗的資料條目記錄到一個報告中，而下一個step會判斷有沒有生成報告，如果生成了報告則將該報告傳送給指定聯絡人，如果沒有則不做任何事情。這種情況下可以通過Decider機制來實現Job的執行流程。在Spring batch 3.0中Decider已經從Step中獨立出來，和Step處於同一級別。
|
1 2 3 4 5 6 7 8 9 10 |
public class ReportDecider implements JobExecutionDecider { @Override public FlowExecutionStatus decide(JobExecution jobExecution, StepExecution stepExecution) { if (report.isExist()) { return new FlowExecutionStatus(“SEND"); } return new FlowExecutionStatus(“SKIP"); } } |
而在job配置中可以這樣來使用Decider。這樣整個Job的執行流程會更加清晰易懂。
|
1 2 3 4 5 6 7 8 |
public Job job() { return new JobBuilder("petstore") .start(orderProcess()) .next(reportDecider) .on("SEND").to(sendReportStep) .on("SKIP").end().build() .build(); } |
採用多種機制加速Job的執行
批處理工作處理的資料量大，而執行視窗一般又要求比較小。所以必須要通過多種方式來加速Job的執行。一般我們有四種方式來實現：
- 在單個step中多執行緒執行任務
- 並行執行不同的Step
- 並行執行同一個Step
- 遠端執行Chunk任務
單個step多執行緒執行任務可以藉助於taskExecutor來實現。這種情況適合於reader、writer是執行緒安全且是無狀態的場景。我們還可以設定執行緒數量。
|
1 2 3 4 5 6 |
public Step step() { return stepBuilders.get("step") .tasklet(tasklet) .throttleLimit(20) .build(); } |
上述示例中的tasklet需要實現TaskExecutor，Spring Batch提供了一個簡單的多執行緒TaskExecutor供我們使用：SimpleAsyncTaskExecutor。
並行執行不同的Step在Spring batch中很容易實現，以下是一個示例：
|
1 2 3 4 5 6 7 |
public Job job() { return stepBuilders.get("parallelSteps") .start(step1) .split(asyncTaskExecutor).add(flow1, flow2) .next(step3) .build(); } |
在這個示例中我們先執行step1，然後並行執行flow1和flow2，最後再執行step3。
Spring batch提供了PartitionStep來實現對同一個step在多個程式中實現並行處理。通過PartitonStep再配合PartitionHandler可以將一個step擴充套件到多個Slave上實現並行執行。
遠端執行Chunk任務則是將某個Step的processer操作分割到多個程式中，多個程式通過一些中介軟體進行通訊（比如採用訊息的方式）。這種方式適合於Processer是瓶頸而Reader和Writer不是瓶頸的場景。
結語
Spring Batch對批處理場景進行了合理的抽象，封裝了大量的實用功能，使用它來開發批處理應用可以達到事半功倍的效果。在使用的過程中我們仍需要堅持總結一些最佳實踐，從而能夠交付高質量的可維護的批處理應用，滿足企業級應用的苛刻要求。