Feat/#91. Batch 모듈 추가, Job(질문발행알림) 추가 #99
Conversation
| fun executeJob() { | ||
| (jobLauncher as TaskExecutorJobLauncher).setTaskExecutor(batchTaskExecutor) | ||
|
|
||
| // TODO: 추후 Event Type에 따라 Job, JobParameter 나누기 | ||
| val jobParameters = JobParametersBuilder() | ||
| .addString("date", LocalDateTime.now().toString()) | ||
| .toJobParameters() | ||
| val job = applicationContext.getBean(QuestionPublishedNotification.JOB_NAME, Job::class.java) | ||
| jobLauncher.run(job, jobParameters) |
There was a problem hiding this comment.
배치 처리할 때, 네트워크 오류가 있을 수도 있으니 여기에서도 retry 로직 추가하는게 어떨까요?
(찾아보니 RetryTemplate 혹은 Retryable 애노테이션이 있어요.)
There was a problem hiding this comment.
Batch의 각 작업(Job)의 Step 내에서 retry를 지원해주기는 합니다.
그런데 제가 정의한 작업의 경우 멀티스레딩으로 처리하는데 이 경우 실패(오류) 시 재시도할 지점을 명확히 할 수 없다는 단점이 있습니다.(ex. 1~5 스레드 중 3번 처리는 무사히 끝났는데 1번 처리가 잘못되었을때, 만약 1번 처리부터 재시도하면 3번은 중복 처리는 되는 문제)
때문에 멀티스레딩의 경우 특별한 상황이 아니면 명시적으로 재시도를 막는게 좋습니다. 잘못하면 처리된 것들도 재시도를 할 수 있기 때문입니다. QuestionPublishedNotification 로직을 보시면 job() 메서드의 preventRestart 나 reader() 메서드 saveState() 메서드가 그러한 역할을 합니다.
실패지점을 기억하고 해당 지점부터 재시작할 수 있는 직렬처리가 아닌 멀티스레드로 처리한 이유는 내결함성이 있어야하는, 반드시 처리 되어야만하는 작업(단순 정보성 푸시 알림이기 때문)은 아니기 때문에 작업을 빠르게 처리할 수 있는 멀티스레드 방식을 선택했습니다.
추가적으로 Batch Job의 각 Step에서 재시도를 지원하는 메서드는 retryLimit입니다.
Issue
Summary
Description