**기능 설명** 배치 서버가 재시작 된 경우, 메모리에 저장된 스케줄링 정보가 사라진다는 문제점이 있습니다. 스케줄링 데이터 보호를 위해 메모리에만 책임을 지게 하지 않고 DB를 조회하여 빠진 스케줄링을 다시 등록해주는 로직을 구상했습니다. - 현재 로직 1. 경매글 생성 메시지 전달 받으면 `이벤트 시작 시간`, `auctionUuid`를 전달 받는다. 2. `이벤트 시작 시간`에서 12시간을 뺀 시간을 `executionTime`로 정의하고 해당 시간에 `Job`이 동작하도록 스케줄러 등록 - 현재 로직의 문제점 - 서버가 재시작 될 때, 스케줄링 내용들이 없어지게 된다. - 제안 로직(배치 서버가 재시작되어도 DB 데이터는 유지된다는 가정) 1. 경매글 생성 메시지 전달 받으면 `이벤트 시작 시간`, `auctionUuid`를 전달 받으면 배치 서버의 `경매 스케줄링 테이블`에 `jobState` 와 함께 저장한다. 2. 배치 서버가 시작할 때 `offset`을 이용해 소비하지 않은 메세지들을 들고온 후, 해당 데이터와 `jobState=false`인 데이터를 스케줄링 처리합니다. 위 방식을 경매글에 국한하지 않고 모든 스케줄링에 사용하는 것이 좋을 듯 합니다. - [x] kafka consumer 로직에 DB 저장 로직 추가 - [x] kafka offset 처리 - [x] 서버 시작 시, 소비하지 않은 메시지 처리 및 DB의 `jobState=false` 데이터 스케줄링 처리 **추가 설명**
기능 설명
배치 서버가 재시작 된 경우, 메모리에 저장된 스케줄링 정보가 사라진다는 문제점이 있습니다.
스케줄링 데이터 보호를 위해 메모리에만 책임을 지게 하지 않고 DB를 조회하여 빠진 스케줄링을 다시 등록해주는 로직을 구상했습니다.
현재 로직
이벤트 시작 시간,auctionUuid를 전달 받는다.이벤트 시작 시간에서 12시간을 뺀 시간을executionTime로 정의하고 해당 시간에Job이 동작하도록 스케줄러 등록현재 로직의 문제점
제안 로직(배치 서버가 재시작되어도 DB 데이터는 유지된다는 가정)
이벤트 시작 시간,auctionUuid를 전달 받으면 배치 서버의경매 스케줄링 테이블에jobState와 함께 저장한다.offset을 이용해 소비하지 않은 메세지들을 들고온 후, 해당 데이터와jobState=false인 데이터를 스케줄링 처리합니다.위 방식을 경매글에 국한하지 않고 모든 스케줄링에 사용하는 것이 좋을 듯 합니다.
jobState=false데이터 스케줄링 처리추가 설명