acks 값 설정에 따른 Producer의 전송 방식 차이 이해

Producer의 acks 설정에 따른 send 방식

• producer는 해당 Topic의 Partition의 Leader Broker에게만 메시지를 보낸다.
• Leader Broker는 받은 메시지를 Replicars에게 메시지를 복제하여 전달한다.

acks = 0 인 경우

acks = 0

• producer는 Leader Broker가 메시지 A를 정상적으로 받았는지에 대한 Ack 메시지를 받지 않고, 다음 메시지인 B를 바로 전송
• 메시지가 제대로 전송되었는지 브로커로 부터 확인을 받지 않기 때문에 메시지가 브로커에 기록되지 않더라도 재 전송하지 않음
• 메시지 손실의 우려가 가장 크지만, 가장 빠르게 전송할 수 있음(IOT 센서 데이터 등 데이터 손실에 민감하지 않은 데이터 전송에 활용)

acks = 1인 경우

acks = 1

• Producer는 Leader broker가 메시지 A를 정상적으로 받았는지에 대한 Ack 메시지를 받은 후 다음 메시지인 메시지 B를 바로 전송
  • 만약 오류 메시지를 브로커로 부터 받으면 메시지 A를 재전송
• 메시지 A가 모든 Replicator에 완벽하게 복사되었는지의 여부는 확인하지 않고 메시지 B를 전송
• 만약 Leader가 메시지를 복제 중에 다운될 경우 다음 Leader가 될 브로커에는 메시지가 없을 수 있기 때문에 메시지를 소실할 우려가 있다.

acks = all인 경우

acks = all

• Producer는 Leader broker가 메시지 A를 정상적으로 받은 뒤 min.insync.replicas 개수만큼의 Replicator에 복제를 수행한 뒤에 보내는 Ack 메시지를 받은 후 다음 메시지인 메시지 B를 바로 전송.
  • 만약 오류 메시지를 브로커로부터 받으면 메시지 A를 재전송
• 메시지 A가 모든 Replicator에 완벽하게 복사되었는지의 여부까지 확인 후에 메시지 B를 전송
• 메시지 손실이 되지 않도록 모든 장애 상황을 감안한 전송모드이지만 Ack를 오래 기다려야 하므로 상대적으로 전송속도가 느림

Producer의 Sync와 Callback Async에서의 Acks와 retry

• Callback 기반의 async에서도 동일하게 acks 설정에 기반하여 retry가 수행된다.
• callback 기반의 async에서는 retry에 따라 Producer의 원래 메시지 전송 순서와 Broker에 기록되는 메시지 전송 순서가 변경될 수 있다.
• Sync 방식에서 acks=0일 경우 전송 후 ack/error를 기다리지 않는다.(fire and forget)

실습하기

 public static void main(String[] args) {
        Properties props = new Properties();
        //Bootstrap.servers, key.serializer.class, value.serializer.class
        //props.setProperty("bootstrap.servers", "192.168.56.101:9092");
        props.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.56.101:9092");
        props.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.setProperty(ProducerConfig.ACKS_CONFIG, "0");
    }

• 설정하지 않는다면 기본적으로는 -1로 설정되어 있다(all)
• sync와 acks=0으로 설정하지 말자..!