ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • [Kafka] request.timeout.ms 와 데이터 중복 생성 알아보기
      Kafka/Kafka Producer 2024. 6. 25. 06:28
      반응형

      - 목차

       

      들어가며.

      카프카 프로듀서는 request.timeout.ms 라는 설정을 가집니다.

      카프카 프로듀서는 request.timeout.ms 로 지정된 시간 내에 데이터를 생성하지 못하면 Retry 를 시도합니다.

      여기서 request.timeout.ms 의 기준은 브로커로부터 Ack 응답을 받기까지의 시간을 의미합니다.

      즉, 메시지의 생성 성공/실패 여부와 상관없이 request.timeout.ms 시간 내에 브로커로부터 Ack 응답을 받지 못하면 Retry 를 시도합니다.

      따라서 이러한 경우에 데이터의 중복 생성 문제가 발생하게 됩니다.

       

      출처 : https://www.geeksforgeeks.org/apache-kafka-producer-acknowledgement-and-min-insync-replicas/

       

       

      데이터 중복 생성 상황을 재현하기 위해서 카프카 클러스터를 생성합니다.

       

      docker network create kafka-net

docker run -d --name zookeeper --hostname zookeeper --net kafka-net \
  -e ZOOKEEPER_CLIENT_PORT=2181 \
  confluentinc/cp-zookeeper:7.6.4

docker run -d --name kafka1 --hostname kafka1 --net kafka-net \
  -e KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181 \
  -e KAFKA_CFG_BROKER_ID=1 \
  -e ALLOW_PLAINTEXT_LISTENER=yes \
  -e KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=2 \
  -e KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,OUTER://:19092 \
  -e KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka1:9092,OUTER://localhost:19092 \
  -e KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,OUTER:PLAINTEXT \
  -e KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT \
  -p 19092:19092 \
  bitnami/kafka:3.1.2

docker run -d --name kafka2 --hostname kafka2 --net kafka-net \
  -e KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181 \
  -e KAFKA_CFG_BROKER_ID=2 \
  -e ALLOW_PLAINTEXT_LISTENER=yes \
  -e KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=2 \
  -e KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,OUTER://:29092 \
  -e KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka2:9092,OUTER://localhost:29092 \
  -e KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,OUTER:PLAINTEXT \
  -e KAFKA_CFG_INTER_BROKER_LISTENER_NAME=PLAINTEXT \
  -p 29092:29092 \
  bitnami/kafka:3.1.2


docker run -d --name kafka-ui --net kafka-net \
  -e DYNAMIC_CONFIG_ENABLED='true' \
  -e KAFKA_CLUSTERS_0_NAME=cluster \
  -e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=kafka1:9092,kafka2:9092 \
  -p 8080:8080 \
  provectuslabs/kafka-ui:v0.7.2

       

      그리고 1개의 파티션과 2개의 Replication Factor 를 가지는 Topic 을 생성합니다.

      kafka-topics --bootstrap-server kafka1:9092 \
    --topic test --create \
    --replication-factor 2 --partitions 1 --config min.insync.replicas=2

       

      그리고 Kafka Producer 를 구현합니다.

      from confluent_kafka import Producer

producer_conf = {
    'bootstrap.servers': 'localhost:19092',
    'batch.size': 1,
    'request.timeout.ms': "100",
    'acks': 'all',
    'enable.idempotence': "false",
    'retry.backoff.ms': '1',
    'max.in.flight.requests.per.connection': 1
}

producer = Producer(producer_conf)

topic = "test"

def delivery_report(err, msg):
    if err is not None:
        print(f"Message delivery failed: {err}, msg : {msg}")

for i in range(10):
    producer.produce(topic, key=None, value=f"this is duplicated message {i}".encode(), callback=delivery_report)

producer.flush()
print("끋")

       

      Producer 의 실행 후, 아래와 같이 생성된 레코드들을 확인하게 되면 중복된 레코드들을 확인할 수 있습니다.

      kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test --from-beginning --group test1
      this is duplicated message 0
this is duplicated message 1
this is duplicated message 0
this is duplicated message 1
this is duplicated message 0
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 5
this is duplicated message 4
this is duplicated message 5
this is duplicated message 4
this is duplicated message 5
this is duplicated message 4
this is duplicated message 6
this is duplicated message 4
this is duplicated message 7
this is duplicated message 4
this is duplicated message 7
this is duplicated message 4
this is duplicated message 7
this is duplicated message 8
this is duplicated message 9
this is duplicated message 9
this is duplicated message 9
this is duplicated message 9

       

      TCP Packet 살펴보기.

      tcpdump 을 통해서 이 상황의 Kafka Broker 의 TCP Packet 을 살펴보면 아래와 같습니다.

      TCP Packet 의 Body 에 this.is.duplicated.message.9 라고 적힌 Packet 이 중복적으로 발송된 것을 확인할 수 있습니다.

       

      // .. 생략 

IP 172.19.0.1.55464 > kafka1.19092: Flags [P.], seq 3475:3615, ack 1907, win 512, options [nop,nop,TS val 2605162960 ecr 1103852644], length 140
	0x0000:  4500 00c0 1e94 4000 4006 c378 ac13 0001  E.....@.@..x....
	0x0010:  ac13 0004 d8a8 4a94 0fd2 c71a a789 d23a  ......J........:
	0x0020:  8018 0200 58de 0000 0101 080a 9b47 a1d0  ....X........G..
	0x0030:  41cb 7464 0000 0088 0000 0009 0000 001b  A.td............
	0x0040:  0007 7264 6b61 666b 6100 00ff ff00 0000  ..rdkafka.......
	0x0050:  0102 0574 6573 7402 0000 0000 6100 0000  ...test.....a...
	0x0060:  0000 0000 0000 0000 5400 0000 0002 20d0  ........T.......
	0x0070:  2fda 0000 0000 0000 0000 0195 2156 4476  /...........!VDv
	0x0080:  0000 0195 2156 4476 ffff ffff ffff ffff  ....!VDv........
	0x0090:  ffff ffff ffff 0000 0001 4400 0000 0138  ..........D....8
	0x00a0:  7468 6973 2069 7320 6475 706c 6963 6174  this.is.duplicat
	0x00b0:  6564 206d 6573 7361 6765 2039 0000 0000  ed.message.9....

IP kafka1.19092 > 172.19.0.1.55464: Flags [P.], seq 1907:1962, ack 3615, win 50470, options [nop,nop,TS val 1103852650 ecr 2605162960], length 55
	0x0000:  4500 006b 09b3 4000 4006 d8ae ac13 0004  E..k..@.@.......
	0x0010:  ac13 0001 4a94 d8a8 a789 d23a 0fd2 c7a6  ....J......:....
	0x0020:  8018 c526 5889 0000 0101 080a 41cb 746a  ...&X.......A.tj
	0x0030:  9b47 a1d0 0000 0033 0000 001b 0002 0574  .G.....3.......t
	0x0040:  6573 7402 0000 0000 0007 0000 0000 0000  est.............
	0x0050:  0070 ffff ffff ffff ffff 0000 0000 0000  .p..............
	0x0060:  0058 0100 0000 0000 0000 00              .X.........

IP 172.19.0.1.55464 > kafka1.19092: Flags [P.], seq 3615:3755, ack 1962, win 512, options [nop,nop,TS val 2605162968 ecr 1103852650], length 140
	0x0000:  4500 00c0 1e95 4000 4006 c377 ac13 0001  E.....@.@..w....
	0x0010:  ac13 0004 d8a8 4a94 0fd2 c7a6 a789 d271  ......J........q
	0x0020:  8018 0200 58de 0000 0101 080a 9b47 a1d8  ....X........G..
	0x0030:  41cb 746a 0000 0088 0000 0009 0000 001c  A.tj............
	0x0040:  0007 7264 6b61 666b 6100 00ff ff00 0000  ..rdkafka.......
	0x0050:  0102 0574 6573 7402 0000 0000 6100 0000  ...test.....a...
	0x0060:  0000 0000 0000 0000 5400 0000 0002 20d0  ........T.......
	0x0070:  2fda 0000 0000 0000 0000 0195 2156 4476  /...........!VDv
	0x0080:  0000 0195 2156 4476 ffff ffff ffff ffff  ....!VDv........
	0x0090:  ffff ffff ffff 0000 0001 4400 0000 0138  ..........D....8
	0x00a0:  7468 6973 2069 7320 6475 706c 6963 6174  this.is.duplicat
	0x00b0:  6564 206d 6573 7361 6765 2039 0000 0000  ed.message.9....

// .. 생략

       

      데이터가 중복 생성되는 원인.

      위에서 말씀드린 것처럼 request.timeout.ms 의 시간 안에 ProduceRequest 요청의 응답을 받아야 합니다.

      그렇지 않으면 카프카 프로듀서는 이전의 요청이 실패하였다고 간주합니다.

      요청의 성공/실패는 중요하지 않습니다.

      하지만 request.timeout.ms 뿐만 아니라 다른 요소들이 더 존재합니다.

       

      acks=all.

      카프카 프로듀서의 acks 가 all 또는 -1 인 상태는 min.insync.replicas 의 갯수만큼 데이터의 복제가 이루어져야지 데이터의 완전한 생성으로 간주됩니다.

      이 상황에서 메시지의 전송 과정을 아래와 같습니다.

      1. 프로듀서가 리더 브로커에게 데이터를 전송한다.
      2. 리더 브로커는 팔로워 브로커에게 데이터 복제본을 전송한다.
      3. 팔로워 브로커는 리더 브로커에게 Ack 응답을 전송한다.
      4. 리더 브로커는 프로듀서에게 Ack 응답을 전송한다.

      위와 같은 일련의 과정이 request.timeout.ms 내에 마무리되지 않으면 Producer 는 Retry 를 시도합니다.

       

      하지만 acks 가 0 이나 1 로 설정되어 있다면 중복 발생이 발생할 확률이 매우 적습니다.

      acks 가 0 상태에서는 브로커의 Ack 응답을 기다리지 않기 때문에 사실상 데이터의 중복 생성이 발생하지 않습니다.

      그리고 acks 가 1 인 상태에서는 리더 브로커가 동기적으로 Producer 의 요청을 처리하기 때문에 중복 생성이 발생할 순 있지만,

      거의 그럴 일은 없다고 생각하셔도 됩니다.

       

      아래와 같이 acks 의 값을 0 으로 변경한 후에 Producer 를 재시작합니다.

      producer_conf = {
    'bootstrap.servers': 'localhost:19092',
    'batch.size': 1,
    'request.timeout.ms': "1",
    'acks': '0',
    'enable.idempotence': "false",
    'retry.backoff.ms': '1',
    'max.in.flight.requests.per.connection': 1
}

       

      이 경우에는 브로커의 Ack 응답을 기다리지 않기 때문에 아래와 같이 중복현상이 발생하지 않습니다.

      다만, 데이터의 손실이 발생할 순 있겠죠 ?

      kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test --from-beginning --group test2
this is duplicated message 0
this is duplicated message 1
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 5
this is duplicated message 6
this is duplicated message 7
this is duplicated message 8
this is duplicated message 9

       

      retries.

      request.timeout.ms 시간 안에 Broker 의 Ack 응답을 받지 못한다면 몇 번의 재시도를 수행할까요 ?

      재시도의 최대 횟수와 관련된 설정이 바로 retries 입니다.

      일반적으로 retries 값은 무한대에 가까운 매우 큰 값입니다.

      따라서 엄청 많은 횟수를 재시도한다고 생각하시면 됩니다.

      Java 의 Kafka Clients 모듈을 사용한다면 Long.MAX_VALUE 값이 기본값으로 설정됩니다.

      하지만 retries 를 0 로 설정하게 된다면, 당연히 중복은 발생하지 않겠죠 ?

       

      producer_conf = {
    'bootstrap.servers': 'localhost:19092',
    'batch.size': 1,
    'request.timeout.ms': "1",
    'acks': 'all',
    'enable.idempotence': "false",
    'retry.backoff.ms': '1',
    'max.in.flight.requests.per.connection': 1,
    'retries': 0
}

       

      이 경우에도 중복 데이터없이 정상적으로 데이터가 생성됩니다.

      kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test --from-beginning --group test2
this is duplicated message 0
this is duplicated message 1
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 5
this is duplicated message 6
this is duplicated message 7
this is duplicated message 8
this is duplicated message 9

       

      다만 주목할 점은 아래와 같이 생성에 실패하였다는 에러 응답을 받게됩니다.

      이 상황은 브로커가 Ack 응답을 전달하지 못했을 뿐 브로커 내부에서 실제 데이터는 정상적으로 생성되었기 때문입니다.

      Message delivery failed: KafkaError{code=REQUEST_TIMED_OUT,val=7,str="Broker: Request timed out"}, msg : <cimpl.Message object at 0x7f89c1675840>

       

      아래의 이미지와 같이 카프카 브로커는 프로듀서로부터 전달받은 데이터를 정상적으로 생성하였고, 프로듀서에서 Ack 응답까지 성공합니다.

      하지만 제가 Producer 의 request.timeout.ms 를 너무 짧게 설정해서 그 시간 내에 Ack 응답을 받지 못했고, Producer 는 Timeout 응답을 raise 합니다.

       

      출처 : https://www.lydtechconsulting.com/blog-kafka-idempotent-producer.html

       

       

       

       

      max.in.flight.requests.per.connection

      max.in.flight.requests.per.connection 은 하나의 Network Socket 에서 발송할 수 있는 요청의 최대값을 의미합니다.

      즉, 한번에 얼마나 많은 요청을 보내는지에 대한 설정인데요.

      일반적으로 Producer 와 Broker 사이에는 1개의 Connection, 1개의 TCP Socket 이 생성됩니다.

      아래는 lsof -i 명령어를 통해서 현재의 Kafka Broker 의 File 과 Socket 의 상태를 확인하였습니다.

      주목한 Socket 은 "TCP kafka1:19092->172.19.0.1:62498 (ESTABLISHED)" 이 부분인데요.

      현재 Producer 와 Brorker 는 "kafka1:19092->172.19.0.1:62498" 인 관계의 TCP Socket 으로 연결됩니다.

       

      lsof -i

COMMAND PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java      1     1001  118u  IPv6 773404      0t0  TCP *:34931 (LISTEN)
java      1     1001  122u  IPv6 771556      0t0  TCP kafka1:38704->zookeeper.kafka-net:2181 (ESTABLISHED)
java      1     1001  130u  IPv6 767927      0t0  TCP *:9092 (LISTEN)
java      1     1001  143u  IPv6 767932      0t0  TCP *:19092 (LISTEN)
java      1     1001  165u  IPv6 806147      0t0  TCP kafka1:9092->kafka-ui.kafka-net:37038 (ESTABLISHED)
java      1     1001  166u  IPv6 790465      0t0  TCP kafka1:39862->kafka1:9092 (CLOSE_WAIT)
java      1     1001  167u  IPv6 797535      0t0  TCP kafka1:19092->172.19.0.1:62498 (ESTABLISHED)
java      1     1001  168u  IPv6 795053      0t0  TCP kafka1:45908->kafka2.kafka-net:9092 (CLOSE_WAIT)
java      1     1001  170u  IPv6 771559      0t0  TCP kafka1:9092->kafka-ui.kafka-net:45990 (ESTABLISHED)
java      1     1001  172u  IPv6 771585      0t0  TCP kafka1:9092->kafka2.kafka-net:36146 (ESTABLISHED)
java      1     1001  225u  IPv6 797771      0t0  TCP kafka1:45916->kafka2.kafka-net:9092 (ESTABLISHED)
java      1     1001  226u  IPv6 800202      0t0  TCP kafka1:9092->kafka2.kafka-net:56874 (ESTABLISHED)

       

      그리고 max.in.flight.requests.per.connection 이 만약 10 으로 설정된다면, 한번에 10개의 요청을 보내게 됩니다.

      여기서 각 요청마다 request.timeout.ms 와 Retries 가 개별적으로 적용됩니다.

      따라서 이 경우에는 데이터 중복이 더 많이 발생할 수 있습니다.

      그 이유는 max.in.flight.requests.per.connection == 1 에서 첫번째 ProductRequest 가 재시도를 하게 되면,

      잇다른 ProduceRequest 가 지연되기 때문입니다.

       

      producer_conf = {
    'bootstrap.servers': 'localhost:19092',
    'batch.size': 1,
    'request.timeout.ms': "1",
    'acks': 'all',
    'enable.idempotence': "false",
    'retry.backoff.ms': '1',
    'max.in.flight.requests.per.connection': 10,
}

       

      kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test --from-beginning --group test3
this is duplicated message 0
this is duplicated message 1
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 5
this is duplicated message 6
this is duplicated message 7
this is duplicated message 8
this is duplicated message 9
this is duplicated message 0
this is duplicated message 1
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 0
this is duplicated message 2
this is duplicated message 4
this is duplicated message 0
this is duplicated message 2
this is duplicated message 0
this is duplicated message 4
this is duplicated message 4
this is duplicated message 4
this is duplicated message 4
this is duplicated message 4

       

      enable.idempotence

      사실상 이 모든 것들인 enable.idempotence 가 False 이기 때문에 발생하는 상황입니다.

      idempotence 를 멱등성이라고 하는데요.

      멱등성이 활성화된 Producer 는 중복이 발생하지 않습니다.

      카프카 프로듀서의 멱등성에 대해서는 다른 글에서 설명을 하도록 하겠습니다.

      우선 아래와 같이 enable.idempotence 를 True 로 활성화하고 난 후에 결과를 확인해보면 데이터 중복은 발생하지 않습니다.

       

      producer_conf = {
    'bootstrap.servers': 'localhost:19092',
    'batch.size': 1,
    'request.timeout.ms': "1",
    'acks': 'all',
    'enable.idempotence': "true",
    'retry.backoff.ms': '1',
    'max.in.flight.requests.per.connection': 1,
}
      kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test --from-beginning --group test6
this is duplicated message 0
this is duplicated message 1
this is duplicated message 2
this is duplicated message 3
this is duplicated message 4
this is duplicated message 5
this is duplicated message 6
this is duplicated message 7
this is duplicated message 8
this is duplicated message 9

       

       

      이 시점의 TCP Packet 은 아래와 같습니다.

      아래와 같이 분명히 Kafka Broker 는 this.is.duplicated.message.1 이라는 메시지를 2번 수신하였습니다.

      하지만 Kafka Broker 내부적으로 Transaction ID 와 Correlation ID 를 기준으로 중복 제거 처리를 수행합니다.

       

      IP 172.19.0.1.55844 > kafka1.19092: Flags [P.], seq 433:573, ack 723, win 512, options [nop,nop,TS val 2607327333 ecr 1106017019], length 140
  0x0000:  4500 00c0 9dbf 4000 4006 444d ac13 0001  E.....@.@.DM....
  0x0010:  ac13 0004 da24 4a94 7cd9 6182 d08c ff7f  .....$J.|.a.....
  0x0020:  8018 0200 58de 0000 0101 080a 9b68 a865  ....X........h.e
  0x0030:  41ec 7afb 0000 0088 0000 0009 0000 0006  A.z.............
  0x0040:  0007 7264 6b61 666b 6100 00ff ff00 0000  ..rdkafka.......
  0x0050:  0102 0574 6573 7402 0000 0000 6100 0000  ...test.....a...
  0x0060:  0000 0000 0000 0000 5400 0000 0002 22a0  ........T.....".
  0x0070:  1cb9 0000 0000 0000 0000 0195 2177 4757  ............!wGW
  0x0080:  0000 0195 2177 4757 0000 0000 0000 0000  ....!wGW........
  0x0090:  0000 0000 0001 0000 0001 4400 0000 0138  ..........D....8
  0x00a0:  7468 6973 2069 7320 6475 706c 6963 6174  this.is.duplicat
  0x00b0:  6564 206d 6573 7361 6765 2031 0000 0000  ed.message.1....
IP kafka1.19092 > 172.19.0.1.55844: Flags [P.], seq 723:778, ack 573, win 50470, options [nop,nop,TS val 1106017025 ecr 2607327333], length 55
  0x0000:  4500 006b 33d1 4000 4006 ae90 ac13 0004  E..k3.@.@.......
  0x0010:  ac13 0001 4a94 da24 d08c ff7f 7cd9 620e  ....J..$....|.b.
  0x0020:  8018 c526 5889 0000 0101 080a 41ec 7b01  ...&X.......A.{.
  0x0030:  9b68 a865 0000 0033 0000 0006 0002 0574  .h.e...3.......t
  0x0040:  6573 7402 0000 0000 0007 0000 0000 0000  est.............
  0x0050:  00cc ffff ffff ffff ffff 0000 0000 0000  ................
  0x0060:  00b1 0100 0000 0000 0000 00              ...........
IP 172.19.0.1.55844 > kafka1.19092: Flags [.], ack 778, win 512, options [nop,nop,TS val 2607327379 ecr 1106017025], length 0
  0x0000:  4500 0034 9dc0 4000 4006 44d8 ac13 0001  E..4..@.@.D.....
  0x0010:  ac13 0004 da24 4a94 7cd9 620e d08c ffb6  .....$J.|.b.....
  0x0020:  8010 0200 5852 0000 0101 080a 9b68 a893  ....XR.......h..
  0x0030:  41ec 7b01                                A.{.
IP 172.19.0.1.55844 > kafka1.19092: Flags [P.], seq 573:713, ack 778, win 512, options [nop,nop,TS val 2607328324 ecr 1106017025], length 140
  0x0000:  4500 00c0 9dc1 4000 4006 444b ac13 0001  E.....@.@.DK....
  0x0010:  ac13 0004 da24 4a94 7cd9 620e d08c ffb6  .....$J.|.b.....
  0x0020:  8018 0200 58de 0000 0101 080a 9b68 ac44  ....X........h.D
  0x0030:  41ec 7b01 0000 0088 0000 0009 0000 0007  A.{.............
  0x0040:  0007 7264 6b61 666b 6100 00ff ff00 0000  ..rdkafka.......
  0x0050:  0102 0574 6573 7402 0000 0000 6100 0000  ...test.....a...
  0x0060:  0000 0000 0000 0000 5400 0000 0002 22a0  ........T.....".
  0x0070:  1cb9 0000 0000 0000 0000 0195 2177 4757  ............!wGW
  0x0080:  0000 0195 2177 4757 0000 0000 0000 0000  ....!wGW........
  0x0090:  0000 0000 0001 0000 0001 4400 0000 0138  ..........D....8
  0x00a0:  7468 6973 2069 7320 6475 706c 6963 6174  this.is.duplicat
  0x00b0:  6564 206d 6573 7361 6765 2031 0000 0000  ed.message.1....
IP kafka1.19092 > 172.19.0.1.55844: Flags [P.], seq 778:833, ack 713, win 50470, options [nop,nop,TS val 1106018020 ecr 2607328324], length 55
  0x0000:  4500 006b 33d2 4000 4006 ae8f ac13 0004  E..k3.@.@.......
  0x0010:  ac13 0001 4a94 da24 d08c ffb6 7cd9 629a  ....J..$....|.b.
  0x0020:  8018 c526 5889 0000 0101 080a 41ec 7ee4  ...&X.......A.~.
  0x0030:  9b68 ac44 0000 0033 0000 0007 0002 0574  .h.D...3.......t
  0x0040:  6573 7402 0000 0000 0000 0000 0000 0000  est.............
  0x0050:  00cc 0000 0195 2177 4757 0000 0000 0000  ......!wGW......
  0x0060:  00b1 0100 0000 0000 0000 00              ...........

       

      마치며.

      이번 글에서 카프카 환경에서 왜 데이터의 중복이 발생하는지에 대해서 여러가지 상황을 살펴보았습니다.

      사실 일반적으로 Network 환경에 위와 같은 시나리오처럼 이상하지 않습니다.

      그래서 Network 이슈로 인해서 중복이 발생할 일은 거의 없으며,

      enable.idempontence 과 max.in.flight.requests.per.connection 설정을 통해서 왠만한 중복은 발생하지 않긴 합니다.

       

       

      반응형

      'Kafka > Kafka Producer' 카테고리의 다른 글

      [Kafka] FindCoordinator 와 Transaction Coordinator 알아보기  (0) 2024.06.29
      [Kafka] Transaction 과 Commit / Abort Maker 알아보기  (0) 2024.06.29
      [Kafka] Producer 와 Idempotence 알아보기 ( InitProducerId, Epoch, Sequence Number )  (0) 2024.06.25
      [Kafka] Pull 방식의 복제와 Producer 속도 관계 알아보기 ( replica.fetch.wait.max.ms )  (0) 2024.06.25
      [Kafka] BufferPool 알아보기 (org.apache.kafka:kafka-clients)  (0) 2024.06.03

      관련글 관련글 더보기

    Designed by Tistory.

    티스토리툴바