2013-04-14 6 views
0

순차적으로 7 개의 프로세스를 실행해야합니다 (하나씩 차례로 실행). 데이터는 MySQL에 저장됩니다. 나는 다음과 같은 옵션을 생각하고있다. 내가 틀렸거나 더 좋은 해결책이 있다면 나에게 정정 해주세요.스프링 배치 - 프로세서 체인

한 요구 사항 :

  1. 는 DB에서 데이터를 읽기, 일곱 개 과정을 마지막으로 DB에 처리 된 데이터를 쓰기 (datavalidation, 계산 1, calculation2 ... 등.).

  2. 데이터를 청크로 처리해야합니다.

내 솔루션과 문제 : 이것은 최고 성능의 DB 리더이기 때문에

  1. 이 JdbcCursorItemReader를 사용하여 데이터를 읽기 - 단, SQL은 매우 복잡, 그래서 할 수 있습니다 : 데이터 읽기 JdbcTemplate을 사용하여 사용자 정의 ItemReader를 고려하십니까? 데이터를보다 유연하게 처리 할 수 ​​있습니다.

프로세스 :

  1. 는 일곱 단계와 청크를 정의 데이터 bean 사용 단계 사이의 데이터를 공유 할 수 있습니다. 하지만 이것은 좋은 아이디어가 아닙니다. 데이터가 청크로 처리되고 각 청크가 끝나면 step1 작성자가 데이터 bean에 새로운 데이터 세트를 작성하기 때문입니다. 이 databean이 다른 단계에서 공유되면 데이터 무결성이 문제가됩니다.

  2. 단계간에 데이터를 공유하려면 StepExecutionContext를 사용하십시오. 하지만 이는 일괄 작업 저장소와 관련되어 성능에 영향을 미칠 수 있습니다.

  3. 하나의 ItemReader와 하나의 프로세스 체인 (7 개의 프로세스)으로 하나의 단계 만 정의하고 처리 된 데이터를 DB에 기록하는 하나의 ItemWriter를 만듭니다. 하지만 각기 다른 프로세스를 관리하거나 모니터 할 수는 없으며 모두 한 단계로 진행됩니다. org.springframework.batch.item.support.CompositeItemProcessor

답변

4

은 두 번째 옵션에 가깝다 귀하의 요구 사항을 지원하는 것이다 스프링 배치 프레임 워크에서 상자 구성 요소의 부족이다. 이렇게하면 다음과 같은 일을 할 수 있습니다. - 데이터베이스 (itemreader)에서 읽을 수 있도록 디자인/솔루션을 분리하십시오. - 개별 프로세서의 우려 사항과 구성을 계속 유지하십시오. - 개별 프로세서가 이전 프로세스와 상관없이 null을 반환하여 청크를 '종료'하도록 허용하십시오.

CompositeItemProcessor은 대리인 루프를 반복하므로 액션 패턴과 '유사'합니다. 그것은 당신이 설명한 시나리오에서 매우 유용하고 아직도 당신이 (정책을 커밋 등을 제외하고 다시 시도)

+0

답장을 보내 주셔서 감사합니다. – Nandan

+0

행정 측면에서는 어느 것이 가장 적합할까요? 별도의 단계 또는 compositeItemProcessor와 한 단계? – Nandan

+0

별도의 단계는 장애 시나리오에서 다시 시작할 때 복잡성을 초래합니다. CompositeItemProcessor를 사용하는 단일 단계는 실패시 모든 프로세스가 롤백된다는 것을 의미합니다. –

1

제안 청크의 이점을 활용할 수 있습니다 :

1) JdbcCursorItemReader를 사용하여 데이터를 읽고 있습니다.

단계별로 다시 시작할 수있는 ItemStream 인터페이스가 이미 구현되어 있으므로 모든 기본 구성 요소를 사용하는 것이 좋습니다. 그러나 여러분이 언급 한 것처럼 언젠가는 요청이 복잡해 지거나 나처럼 여러분은 이미 재사용 할 수있는 서비스 나 DAO를 가지고 있습니다.

ItemReaderAdapter를 사용하는 것이 좋습니다. 이를 통해 데이터를 얻기 위해 호출 할 대리자 서비스를 구성 할 수 있습니다. 조직 다음 targetMethod이 ItemReaders의 읽기 계약 (더 이상 데이터는 null)

작업이 재시작 할 필요가없는 경우, 당신은 단순히 클래스를 사용할 수를 존중해야한다는

<bean id="MyReader" class="xxx.adapters.MyItemReaderAdapter"> 
     <property name="targetObject" ref="AnExistingDao" /> 
     <property name="targetMethod" value="next" />   
    </bean> 

참고. 당신이 다시 시작될 수 있도록 작업을해야하는 경우 springframework.batch.item.adapter.ItemReaderAdapter

, 당신은 다음과 같이 자신의 ItemReaderAdapter을 만들 수 있습니다

public class MyItemReaderAdapter<T> extends AbstractMethodInvokingDelegator<T> implements ItemReader<T>, ItemStream { 




private long currentCount = 0; 

private final String CONTEXT_COUNT_KEY = "count"; 

/** 
* @return return value of the target method. 
*/ 
public T read() throws Exception { 

    super.setArguments(new Long[]{currentCount++}); 
    return invokeDelegateMethod(); 
} 
@Override 
public void open(ExecutionContext executionContext) 
     throws ItemStreamException { 
    currentCount = executionContext.getLong(CONTEXT_COUNT_KEY,0); 

} 


@Override 
public void update(ExecutionContext executionContext) throws ItemStreamException { 
    executionContext.putLong(CONTEXT_COUNT_KEY, currentCount); 
    log.info("Update Stream current count : " + currentCount); 
} 


@Override 
public void close() throws ItemStreamException { 
    // TODO Auto-generated method stub 

} 

} 
,

out-of-the-box itemReaderAdapter는 다시 시작할 수 없기 때문에 ItemStream을 구현하는 자신 만의 아이템을 만들 수 있습니다.

2) 7 단계 대 1 단계

이 기사에서는 compositeProcessor를 사용하여 1 단계로 간다. 7 단계 옵션은 IMO에만 문제가 발생합니다.

1) 7 단계 databean : 그래서 writer는 7 단계까지 databean에서 커밋합니다. 그러면 7 단계 writer는 실제 데이터베이스에 커밋을 시도하고 오류가 발생합니다 !!! 모두 잃어 버리고 배치는 1 단계에서 다시 시작해야합니다!

2) 컨텍스트가있는 7 단계 : 스프링 배치 메타 데이터에 상태가 저장되어 있기 때문에 더 좋을 수 있습니다.하지만 springBatch의 메타 데이터에 큰 데이터를 저장하는 것은 좋지 않습니다 !!

3)은 IMO로가는 길입니다. ;-)