메세지 유실 테스트
1. unclean.leader.election.enable
1.1false일 경우
ISR이 아닌 팔로워 파티션을 리더 파티션으로 선출하지 않는다.
리더로 선출할 팔로워 파티션이 없을 경우 장애가 발생한 브로커가 다시 실행될 때까지 해당 토픽은 사용할 수 없다는 문제점이 있다.
데이터의 유실을 줄일 수 있다는 장점이 있다.
1.2 true일 경우
ISR이 아닌 팔로워 파티션, 즉 동기화가 되지 않은 팔로워 파티션도 리더로 선출될 수 있다.
리더 파티션이 존재하는 브로커에서 장애가 발생하고 동기화되지 않은 팔로워 파티션이 리더로 선출되면 리더 파티션으로부터 동기화가 되지 않은 일부 데이터는 유실될 수 있으나 토픽을 사용하는 서비스의 중단은 발생하지 않는다.
2. enable.auto.commit(103p) // consumer 설정
poll()메서드 호출 이후에 리밸런싱 또는 컨슈머 강제종료 발생 시 컨슈머가 처리하는 데이터가 중복 또는 유실될 수 있는 가능성이 있는 취약한 구조를 가지고 있다.
해결방안
enable.auto.commit=false로 설정하고 commitSync()또는 commitAsync()메서드를 사용한다.
이를 해결하기 위해 commitAsync()메서드를 사용하여 커밋 요청을 전송하고 응답이 오기 전까지 데이터 처리를 수행할 수 있다. 하지만 커밋 요청이 실패했을 경우 데이터의 순서를 보장하지 않으며 데이터의 중복 처리가 발생할 수 있다.
3. DLT(Dead Letter Topic)
- topic이 잘못 지정된 경우
- 메세지를 deserialize 할 수 없는 경우
- 데이터가 예상과 다른 경우 (예를 들어 값이 항상 양수인 필드에 음수가 들어간 경우)
- 나중에 시도할 때 성공할 수 있는 예외
- 액세스하려는 서비스(DB, API)가 다운되거나 문제가 발생하여 발생하는 예외
- RetryTemplate을 이용하여 재시도
- 최대 시도 횟수, 재시도하려는 예외 및 재시도하지않을 항목을 지정해야 한다.
- KafkaListenerErrorHandler
4. acks
생산자가 요청 완료를 고려하기 전에 리더가 수신해야 하는 확인의 수입니다. 이것은 전송된 레코드의 내구성을 제어합니다. 다음 설정이 허용됩니다.
acks=0으로 설정하면 생산자는 서버의 승인을 전혀 기다리지 않습니다. 레코드는 즉시 소켓 버퍼에 추가되고 전송된 것으로 간주됩니다. 이 경우 서버가 레코드를 수신했다고 보장할 수 없으며 retries구성이 적용되지 않습니다(클라이언트가 일반적으로 실패를 알지 못하기 때문에). 각 레코드에 대해 제공된 오프셋은 항상 로 설정됩니다 -1.
acks=1이는 리더가 로컬 로그에 레코드를 기록하지만 모든 팔로워의 완전한 승인을 기다리지 않고 응답함을 의미합니다. 이 경우 리더가 레코드를 승인한 직후 실패하지만 팔로워가 이를 복제하기 전에 레코드가 손실됩니다.
acks=all즉, 리더는 동기화된 전체 복제본 세트가 레코드를 승인할 때까지 기다립니다. 이렇게 하면 동기화된 복제본이 하나 이상 활성 상태로 유지되는 한 레코드가 손실되지 않습니다. 이것은 가장 강력한 보증입니다. 이는 acks=-1 설정과 동일합니다.
reply response
스프링 카프카에서는 KafkaTemplate외에도 ReplyingKafkaTemplate과 RoutingKafkaTemplate도 제공한다.
ReplyingKafkaTemplate
컨슈머가 특정 데이터를 전달받았는지 여부를 확인할수 있다.
RoutingKafkaTemplate
전송하는 토픽별로 옵션을 다르게 설정할 수 있다.
https://docs.confluent.io/platform/current/installation/configuration/producer-configs.html
