5.2. 데이터 조정

메시지 전달 승인은 메시지가 손실될 가능성을 최소화합니다. 감사는 기본적으로 acks=all 에 설정된 acks 속성을 사용하여 활성화됩니다.

메시지 전달 확인

# ...
acks=all 1
# ...

1
ACKS=all 은 메시지 요청이 성공적으로 수신되었음을 확인하기 전에 특정 수의 성공자에게 메시지를 복제하도록 강제 적용합니다.

acks=all 설정은 강력한 전달 보장을 제공하지만 생산자가 메시지를 보내고 승인을 수신하는 것 사이의 대기 시간을 늘릴 수 있습니다. 이러한 강력한 보장이 필요하지 않은 경우 acks=0 또는 acks=1 로 설정하면 리더 복제본에서 해당 로그에 레코드를 기록했음을 확인하는 보장이 없거나 확인만 제공합니다.

acks=all 을 사용하면 리더는 모든 동기화 복제본이 메시지 전달을 승인할 때까지 기다립니다. 항목의 min.insync.replicas 구성은 필요한 최소 개수의 in-sync 복제본 승인 수를 설정합니다. 승인의 횟수는 리더와 팔로워의 수를 포함합니다.

일반적으로 시작 지점은 다음 구성을 사용하는 것입니다.

  • 생산자 구성:

    • ACKS=all (기본값)
  • 주제 복제를 위한 브로커 구성:

    • default.replication.factor=3 (기본값 = 1)
    • min.insync.replicas=2 (default = 1)

주제를 만들 때 기본 복제 요소를 재정의할 수 있습니다. 주제 구성의 주제 수준에서 min.insync.replicas 를 재정의할 수도 있습니다.

AMQ Streams는 Kafka의 다중 노드 배포에 대해 예제 구성 파일에서 이 구성을 사용합니다.

다음 표에서는 리더 복제본을 복제하는 사용자의 가용성에 따라 이 구성이 작동하는 방법을 설명합니다.

표 5.1. 팔로워 사용 가능

사용 가능한 설명 및 동기화감사 인사생산자가 메시지를 보낼 수 있습니까?

2

리더는 2개의 후속 조치를 기다리고 있습니다.

제공됨

1

리더가 1 후속 조치를 기다리는 경우

제공됨

0

리더는 예외를 발생시킵니다.

없음

3의 주제 복제 요인은 하나의 리더 복제본과 두 명의 팔로워를 만듭니다. 이 구성에서는 단일 후속 조치를 사용할 수 없는 경우 생산자가 계속될 수 있습니다. in-sync 복제본에서 실패한 브로커를 제거하거나 새 리더를 생성하는 동안 일부 지연이 발생할 수 있습니다. 두 번째 후속 조치도 사용할 수 없는 경우 메시지 전달에 성공하지 못합니다. 성공적인 메시지 전달을 인정하는 대신 리더는 오류(여전복제본이 충분하지 않음)를 프로듀자에게 보냅니다. 프로듀서에서 동일한 예외를 발생시킵니다. 재시도 구성을 사용하면 프로듀서에서 실패한 메시지 요청을 다시 보낼 수 있습니다.

참고

시스템이 실패하면 버퍼에 원하지 않는 데이터가 손실될 위험이 있습니다.