retry 시 동작과정 질문

kafka @RetryableTopic 에 대해 알아보다보니 궁금한점이 생겨 질문 드립니다.

@RetryableTopic 가 없어도 retry 는 기본적으로 진행하는거 같은데요. 제가 알아본 바로는 아래와 같은 차이점이 있는것 같았습니다.

@RetryableTopic 을 사용하지 않으면 'dlt' 로 메시지가 이동되지 않는다.
- @RetryableTopic 을 사용하면 'dlt' 토픽이 없는 경우 자동으로 만들어주고 dlt 토픽으로 메시지를 이동시켜준다.
@RetryableTopic 을 사용하지 않으면 재시도는 하지만 재시도동안에는 partition 을 blocking 한다 (= 블로킹).
- @RetryableTopic 을 사용하면 재시도 하기전에 retry 토픽으로 이동시키고 consumer 의 스레드를 blocking 하지 않고 별도 스레드에서 retry 를 진행한다. (= 논블로킹)

강좌에서는 retry 중에는 partition 이 blocking 된다고 하셨는데, 그 부분과 좀 다른거 같아서 문의 드립니다..!

만약 @RetryableTopic 이 논블로킹으로 별도 스레드에서 진행이 된다면 순서보장이 안되는거라서 순서보장이 필요하다면 이걸 사용하면 안되는게 아닌가 싶습니다.

안녕하세요, 인프런 AI 인턴입니다. writer0713님.

Kafka의 @RetryableTopic 어노테이션 사용에 관하여 훌륭한 질문을 주셨습니다. 이 어노테이션은 Kafka 스프링을 사용하여 메시지 재시도 로직을 구현할 때 많이 참고되는 기능 중 하나입니다. 이 기능을 사용하는 것과 그로 인해 발생하는 차이를 설명드리겠습니다.

`@RetryableTopic`와 일반 재시도 로직의 차이

DLT(Dead Letter Topic) 생성 및 관리:
- 기본적으로 Kafka는 실패한 메시지를 다른 토픽으로 보내는 기능이 없습니다. @RetryableTopic을 사용하면 실패한 메시지가 일정 횟수의 재시도 후에도 처리되지 않을 때 DLT로 이동하여 메시지 손실을 방지합니다. DLT가 없다면 자동으로 생성해주는 기능도 포함되어 있어 편리합니다.
블로킹 vs. 논블로킹 재시도:
- 기본 재시도에서는 컨슈머가 처리 실패 시, 해당 파티션의 메시지를 재시도 동안 처리할 수 없기에 그 파티션이 블로킹됩니다.
- @RetryableTopic은 재시도 로직을 별도의 토픽으로 이동시키고, 소비자에게 별도 스레드에서 재시도가 발생하도록 하여 파티션이 블로킹되지 않도록 합니다. 이는 논블로킹 방식으로, 일반적인 파티션의 메시지 처리에 영향을 줄이지 않습니다.
순서 보장 문제:
- @RetryableTopic을 사용하게 되면 논블로킹으로 처리하게 되어, 재시도 시 메시지의 순서를 보장하기 어렵습니다. 따라서, 메시지의 순서가 중요한 경우 사용에 주의해야 합니다.

이와 관련하여 더 깊이 있는 설명은 다음 링크를 참고하시면 추가적인 정보와 이해에 도움이 될 것입니다:
- Kafka @RetryableTopic을 활용한 재시도 전략

해당 기능은 사용자에게 유연성을 제공하나, 특정 상황에서는 적합하지 않을 수 있기에 사용 시 메시지의 특성 및 시스템 요구사항을 고려하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변

@RetryableTopic와 일반 재시도 로직의 차이

`@RetryableTopic`와 일반 재시도 로직의 차이