유실테스트

메세지 유실 테스트

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