refactor: 보정 대기 시간과 스케줄러 주기를 동기화하여 정합성 보정 신뢰성 강화

[Ji-minhyeok]

🚀 작업 개요

보정 스케줄러의 대기(안전 마진)를 실행 주기(30s)와 동기화하였으며,
안전 마진 시간의 증가는 리스너의 메시지 수신(Fetch)과 실제 처리(onMessage) 사이의 시차를 설계 주기 안(안전 마진)으로 충분히 들어올 수 있도록 하여 정합성의 완성도를 높였습니다.

🛠️ 작업 사항

리스너 처리 주기를 고려한 마진 동기화

• 리스너의 pollTimeout과 Executor 큐 대기 시간이 모두 주기 내에 들어올 수 있도록 안전 마진을 스케줄러 실행 주기와 동일한 30초로 상향했습니다.
• 이를 통해 "리스너가 새로운 메시지를 가져오지 않고 내부 큐의 모든 메시지 처리가 완료되어 DB 반영까지 끝난 확실한 완료 상태"를 스케줄링 주기 단위로 검증합니다.

보호 구간 확립

• 단순한 시간 추측이 아닌, "최소 한 번의 전체 스케줄링 주기(30s) 동안 리스너 활동이 0"인 경우에만 보정 진입을 허용함으로써 리스너와 스케줄러 간의 레이스 컨디션을 근본적으로 차단했습니다.

✅ PR 유형

• 코드 리팩토링

✅ Check List

• 코드가 정상적으로 컴파일되나요?
• 테스트 코드를 통과했나요?
• merge할 브랜치의 위치를 확인했나요?
• Label을 지정했나요?

🔗 관련 이슈

• [Refcator] Lesson Consumer Row Lock 경합 개선 및 최종 일관성 적용 #221

💬 기타 참고 사항

리스너 - onMessage() 간의 시차에 대한 내용 정리입니다.

1. 리스너 수신 후 대기 단계: StreamMessageListenerContainer가 Redis에서 메시지를 수신(Fetch)하여 Executor 내부 큐(200개 용량)에 적재한 시점입니다.
2. 상태 불일치 구간: 이 단계에서 메시지는 이미 MQ를 떠났으나, 워커 스레드가 배정되어 onMessage를 실행하기 전까지는 Busy Counter가 0으로 유지됩니다.
3. 오판 원인: 스케줄러가 이 '수신 후 처리 대기 (= 내부 큐에 존재)' 상태를 '처리 완료(= MQ에 메세지가 없음)'로 오판하여 보정을 실행함으로써 보정 직후 유입된 대기 메시지들이 초과 집계되는 결과를 초래했습니다.