[ default 옵션]
| 옵션명 | default | 설명 | |
| 1 | bootstrap.servers | localhost:9092 | 초기 kafka cluster에게 연결하기 위한 host/port 쌍의 list. bootstrap.servers 를 등록해야 외부 서버에서 연결이 가능하며, 2개 이상 권장 ( consumer AP 끊기게 될 경우, 다른 consumer 로 연결하기 위해) default : "" |
| 2 | compression.type | none | 생성된 모든 데이터에 대한 압축 코덱 지정 : none, gzip, snnappy, lz4, zstd |
[ Producer AP 옵션 ]
| 옵션명 | default | 설명 | 비고 | |
| 1 | key.serializer | 인터페이스를 구현하는 키에 대한 직렬 변환기 클래스 | ||
| 2 | value.serializer | 인터페이스를 구현하는 값에 대한 직렬 변환기 클래스 | ||
| 3 | bootstrap.server | kafka cluster에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록 클라이언트는 bootstraping을 위해 여기에 지정된 서버에 관계없이 모든 서버를 사용함. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미침. 기본형식은 host1:port1. 이러한 서버는 전체 클러스터 구성원(동적으로 변경될 수 있음) 을 검색하기 위한 초기 연결에만 사용되므로 이 목록에는 전체 서버 집합이 포함될 필요가 없으나, 서버가 다운된 경우에는 두개 이상 필요 |
||
| 4 | buffer.memory | 33554432 | producer가 서버로 전송되기를 기다리는 record를 버퍼링 하는데 사용할 수 있는 메모리의 총 바이트. Record가 서버에 전달될 수 있는 것보다 더 빠르게 전송되면 생상자는 차단한 max.block.ms후 예외를 발생 시킴 이 설정은 producer가 사용할 총 메모리와 대략적으로 일치해야하지만, producer가 사용하는 모든 메모리가 버퍼링에 사용되는 것은 아니기때문에 엄격한 제한은 아님. 일부 추가 메모리는 압축(압축이 활성화된 경우) 과 진행 중인 요청 유지에 사용됨 |
|
| 5 | compression.type | producerr가 생성한 모든 데이터의 압축 유형. 유효한 값 : none, gzip, snappy, lz4, zstd 압축은 전체 데이터 배치에 대한 것이므로 일괄 처리의 효율성은 압축 비율에도 영향을 미침 (일괄 처리가 많은수록 압축 성능이 향상됨) |
||
| 6 | retries | 2147483647 | 0보다 큰 값을 설정하면 client는 잠재적인 일시적인 오류로 인해 전송이 실패한 레코드를 다시 보내게 됨. 이 재시도는 client가 오류 수신 레코드를 다시 보내는 것과 다르지 않음. 성공적으로 승인되기 전에 구성한 제한 시간이 먼저 delivery.timeout.ms에 의해 만료되면 재시도 횟수가 소진되기 전에 생성 요청이 실패함. 일단 이 옵션은 변경하지 말고 대신 재시도 동작을 control하는 delivery.timeout.ms를 사용해야함 |
delivery.timeout.ms란, 반환 호출 후 성공 또는 실패를 보고하는 시간의 상한. 이는 전송 전에 레코드가 지연되는 총시간, broker의 승인을 기다리는 시간 및 재시도 가능한 전송 실패에 허용되는 시간을 제한함. 복구할 수 없는 오류가 발생했거나, 재시도 횟수가 소진되었거나, 더 이른 전달 말료 기한에 도달한 배치에 레코드가 추가된 경우, producer는 이 구성 이전에 레코드를 보내지 못했다고 보고할 수 있음. Request.timeout.out은 linger의 합계보다 크거나 같아야함. |
| 7 | batch.size | 16384 | producer는 여러 레코드가 동일한 partitions으로 전송될 때마다 레코드를 더 적은 수의 요청으로 일괄 처리하려고 시도함. 이는 클라이언트와 서버 모두의 성능에 도움이 됨. 이 구성은 기본 배치크기(바이트)를 제어함 이 크기보다 큰 일괄 레코드는 시도되지 않음. Broker가 전송된 요청에는 전송할 수 있는 데이터가 각 파티션마다 하나씩 여러 배치가 포함됨 배치 크기가 작으면 일괄 처리가 덜 일반적이고 처리량이 줄어들 수 있음 (배치 크기가 0이면 일괄 처리가 완전히 비활성화됨) 매우 큰 배치 크기는 추가 레코드를 예상하여 항상 지정된 배치 크기의 버퍼를 할당하므로 메모리를 좀 더 낭비적으로 사용할 수 있음 * 이 설정은 전송할 배치 크기의 상한을 제공함. 이 파티션에 대해 누적된 바이트 수가 이보다 적으면 linger.ms 설정의 기본값은 0임. 즉, 누적된 배치 크기가 이 설정에 해당하더라도 즉시 레코드를 전송한다는 의미. |
|
| 8 | linger.ms | 0 | 클라이언트가 부하를 줘 요청 수를 줄이고 싶을 때, 이 옵션을 사용하여 인위적인 지연 수행 TCP Nagle 알고리즘과 유사함 batch.size파티션에 대한 레코드 가치를 얻으면 이 설정에 관계없이 즉시 전송. 그러나 이 파티션에 대해 누적된 바이트 수가 이보다 적으면 지체됨. 더 많은 레코드가 표시될 때까지 기다리는 시간임. 0은 지연없음. 만약 linger.ms=5 로 설정하면, 전송된 요청 수가 줄여지지만 로드가 없을 땐 전송된 레코드에 최대 5ms의 대기시간이 추가됨 |
|
| 그 외 producer.properties 주석 옵션 | ||||
| 9 | partitioner.class | record가 생성될 때 레코드를 보낼 파티션을 결정함. <사용 가능한 옵션> • 설정하지 않을 경우 : 기본 분할 논리 사용됨 • org.apache.kafka.clients.producer.RoundRobinPartitioner로 설정할 경우 : 파티션이 소진되고 프로세스가 다시 시작될 때까지 '키'제공 여부에 관계없이 일련의 dustrh 레코드의 각 레코드가 다른 파티션으로 전송되는 partitioning 전략. (참고 : 새 배치가 생성될 때 고르지 않은 배포를 일으키는 문제가 있음) org.apache.kafka.clients.producer.Partitioner인터페이스를 구현하면 custom partitioner에 연결할 수 있음 |
||
| 10 | request.timeout.ms | 30000(30초) | 클라이언트가 요청 응답을 기다리는 최대 시간을 제어함. 제어 시간이 경과하기 전에 응답이 수신되지 않으면, 클라이언트는 필요한 경우 요청을 다시 보내거나 재시도가 모두 소진되면 요청이 실패함. replica.lag.time.max.ms(불필요한 producer 재시도때문에 메시지가 복제되는 가능성을 줄여줌)보다 더 커야함 |
|
| 11 | max.block.ms | 60000(1분) | KafkaProducer구성은 , send(), , 및 메소드 partitionsFor()가 차단되는 기간을 제어함 이 시간 초과 의 경우 메타데이터 가져오기 및 버퍼 할당을 기다리는 총 시간이 제한됨 (사용자 제공 직렬 변환기 또는 파티셔너의 차단은 이 시간 초과에 대해 계산되지 않음) 이 제한 시간은 메타데이터를 사용할 수 없는 경우 이를 기다리는 데 소요되는 시간을 제한함 트랜잭션 관련 메서드는 항상 차단되지만, 트랜잭션 코디네이터를 찾을 수 없거나 시간 초과 내에 응답하지 않으면 시간 초과될 수 있음 |
|
| 12 | max.request.size | 요청의 최대 크기(바이트) 이 설정은 대규모 요청을 보내는 것을 피하기 위해 producer가 단일 요청으로 보내는 레코드 배치 수를 제한함 이는 또한 압축되지 않은 최대 레코드 배치 크겡 대한 사실상의 제한임 서버에는 레코드 배치 크기(압축이 활성화된 경우 압축 후)에 대한 자체 제한이 있으며 이와 다를 수 있음 |
||
[ 그 외 공식문서 참고 ]
| 옵션명 | default | 설명 | 비고 |
| importance : high | |||
| key.serializer | 인터페이스를 구현하는 키에 대한 직렬 변환기 클래스 | ||
| value.serializer | 인터페이스를 구현하는 값에 대한 직렬 변환기 클래스 | ||
| bootstrap.server | kafka cluster에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록 클라이언트는 bootstraping을 위해 여기에 지정된 서버에 관계없이 모든 서버를 사용함. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미침. 기본형식은 host1:port1. 이러한 서버는 전체 클러스터 구성원(동적으로 변경될 수 있음) 을 검색하기 위한 초기 연결에만 사용되므로 이 목록에는 전체 서버 집합이 포함될 필요가 없으나, 서버가 다운된 경우에는 두개 이상 필요 |
||
| buffer.memory | 33554432 | producer가 서버로 전송되기를 기다리는 record를 버퍼링 하는데 사용할 수 있는 메모리의 총 바이트. Record가 서버에 전달될 수 있는 것보다 더 빠르게 전송되면 생상자는 차단한 max.block.ms후 예외를 발생 시킴 이 설정은 producer가 사용할 총 메모리와 대략적으로 일치해야하지만, producer가 사용하는 모든 메모리가 버퍼링에 사용되는 것은 아니기때문에 엄격한 제한은 아님. 일부 추가 메모리는 압축(압축이 활성화된 경우) 과 진행 중인 요청 유지에 사용됨 |
|
| compression.type | producerr가 생성한 모든 데이터의 압축 유형. 유효한 값 : none, gzip, snappy, lz4, zstd 압축은 전체 데이터 배치에 대한 것이므로 일괄 처리의 효율성은 압축 비율에도 영향을 미침 (일괄 처리가 많은수록 압축 성능이 향상됨) |
||
| retries | 2147483647 | 0보다 큰 값을 설정하면 client는 잠재적인 일시적인 오류로 인해 전송이 실패한 레코드를 다시 보내게 됨. 이 재시도는 client가 오류 수신 레코드를 다시 보내는 것과 다르지 않음. 성공적으로 승인되기 전에 구성한 제한 시간이 먼저 delivery.timeout.ms에 의해 만료되면 재시도 횟수가 소진되기 전에 생성 요청이 실패함. 일단 이 옵션은 변경하지 말고 대신 재시도 동작을 control하는 delivery.timeout.ms를 사용해야함 |
delivery.timeout.ms란, 반환 호출 후 성공 또는 실패를 보고하는 시간의 상한. 이는 전송 전에 레코드가 지연되는 총시간, broker의 승인을 기다리는 시간 및 재시도 가능한 전송 실패에 허용되는 시간을 제한함. 복구할 수 없는 오류가 발생했거나, 재시도 횟수가 소진되었거나, 더 이른 전달 말료 기한에 도달한 배치에 레코드가 추가된 경우, producer는 이 구성 이전에 레코드를 보내지 못했다고 보고할 수 있음. Request.timeout.out은 linger의 합계보다 크거나 같아야함. |
| importance : medium | |||
| batch.size | 16384 | producer는 여러 레코드가 동일한 partitions으로 전송될 때마다 레코드를 더 적은 수의 요청으로 일괄 처리하려고 시도함. 이는 클라이언트와 서버 모두의 성능에 도움이 됨. 이 구성은 기본 배치크기(바이트)를 제어함 이 크기보다 큰 일괄 레코드는 시도되지 않음. Broker가 전송된 요청에는 전송할 수 있는 데이터가 각 파티션마다 하나씩 여러 배치가 포함됨 배치 크기가 작으면 일괄 처리가 덜 일반적이고 처리량이 줄어들 수 있음 (배치 크기가 0이면 일괄 처리가 완전히 비활성화됨) 매우 큰 배치 크기는 추가 레코드를 예상하여 항상 지정된 배치 크기의 버퍼를 할당하므로 메모리를 좀 더 낭비적으로 사용할 수 있음 * 이 설정은 전송할 배치 크기의 상한을 제공함. 이 파티션에 대해 누적된 바이트 수가 이보다 적으면 linger.ms 설정의 기본값은 0임. 즉, 누적된 배치 크기가 이 설정에 해당하더라도 즉시 레코드를 전송한다는 의미. |
|
| linger.ms | 0 | 클라이언트가 부하를 줘 요청 수를 줄이고 싶을 때, 이 옵션을 사용하여 인위적인 지연 수행 TCP Nagle 알고리즘과 유사함 batch.size파티션에 대한 레코드 가치를 얻으면 이 설정에 관계없이 즉시 전송. 그러나 이 파티션에 대해 누적된 바이트 수가 이보다 적으면 지체됨. 더 많은 레코드가 표시될 때까지 기다리는 시간임. 0은 지연없음. 만약 linger.ms=5 로 설정하면, 전송된 요청 수가 줄여지지만 로드가 없을 땐 전송된 레코드에 최대 5ms의 대기시간이 추가됨 |
|
| partitioner.class | record가 생성될 때 레코드를 보낼 파티션을 결정함. <사용 가능한 옵션> • 설정하지 않을 경우 : 기본 분할 논리 사용됨 • org.apache.kafka.clients.producer.RoundRobinPartitioner로 설정할 경우 : 파티션이 소진되고 프로세스가 다시 시작될 때까지 '키'제공 여부에 관계없이 일련의 dustrh 레코드의 각 레코드가 다른 파티션으로 전송되는 partitioning 전략. (참고 : 새 배치가 생성될 때 고르지 않은 배포를 일으키는 문제가 있음) org.apache.kafka.clients.producer.Partitioner인터페이스를 구현하면 custom partitioner에 연결할 수 있음 |
||
| request.timeout.ms | 30000(30초) | 클라이언트가 요청 응답을 기다리는 최대 시간을 제어함. 제어 시간이 경과하기 전에 응답이 수신되지 않으면, 클라이언트는 필요한 경우 요청을 다시 보내거나 재시도가 모두 소진되면 요청이 실패함. replica.lag.time.max.ms(불필요한 producer 재시도때문에 메시지가 복제되는 가능성을 줄여줌)보다 더 커야함 |
|
| max.block.ms | 60000(1분) | KafkaProducer구성은 , send(), , 및 메소드 partitionsFor()가 차단되는 기간을 제어함 이 시간 초과 의 경우 메타데이터 가져오기 및 버퍼 할당을 기다리는 총 시간이 제한됨 (사용자 제공 직렬 변환기 또는 파티셔너의 차단은 이 시간 초과에 대해 계산되지 않음) 이 제한 시간은 메타데이터를 사용할 수 없는 경우 이를 기다리는 데 소요되는 시간을 제한함 트랜잭션 관련 메서드는 항상 차단되지만, 트랜잭션 코디네이터를 찾을 수 없거나 시간 초과 내에 응답하지 않으면 시간 초과될 수 있음 |
|
| max.request.size | 1048576 | 요청의 최대 크기(바이트) 이 설정은 대규모 요청을 보내는 것을 피하기 위해 producer가 단일 요청으로 보내는 레코드 배치 수를 제한함 이는 또한 압축되지 않은 최대 레코드 배치 크겡 대한 사실상의 제한임 서버에는 레코드 배치 크기(압축이 활성화된 경우 압축 후)에 대한 자체 제한이 있으며 이와 다를 수 있음 |
|
| client.dns.lookup | use_all_dns_ips | 클라이언트가 DNS 조회를 사용하는 방법을 제어함 use_all_dns_ips로 설정돼 있을 경우, 성공적으로 연결될 때까지 반환된 각 IP 주소에 순서대로 연결함 연결이 끊기면 다음 IP가 사용되며, 모든 IP가 한 번 사용되면 클라이언트는 호스트 이름에서 IP를 다시 확인함 (다만 JVM 및 OS 캐시 DNS 이름 모두 조회함) resolve_canonical_bootstrap_servers_only로 설정된 경우, 각 부트스트랩 주소를 정식 이름 목록으로 확인하며, 부트스트랩 단계 이후에는 use_all_dns_ips와 동일하게 동작함 유효한 값 : use_all_dns_ips, resolve_canonical_bootstrap_servers_only |
|
| client.id | "" | 요청을 할 때 서버에 전달할 id 문자열 이 옵션의 목적은 논리적 애플리케이션 이름이 서버 측 요청 로깅에 포함되도록 허용하여 IP/port 이외의 요청 소스를 추적할 수 있도록 하는 것 |
|
| connections.max.idle.ms | 540000 (9 minutes) | 이 옵션은 지정된 시간(밀리초) 후에 유휴 연결을 닫음 | |
| delivery.timeout.ms | 120000 (2 minutes) | returns에 대한 호출 후 성공 또는 실패를 보고하는 시간의 상한함. | |
| partitioner.ignore.keys | FALSE | true'로 설정하면 생산자는 레코드 키를 사용하여 파티션을 선택하지 않음 기본값인 'false'인 경우 producer는 키가 있을 때의 키의 해시를 기반으로 파티션을 선택함 (참고: 이 설정은 사용자 지정 파티셔너를 사용하는 경우에는 적용되지 않음) |
|
| receive.buffer.bytes | 32768 (32 kibibytes) | 데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기 값이 -1이면 os 기본값이 사용됨 유효한 값 : -1,... |
|
| request.timeout.ms | 30000 (30 seconds) | 이 옵션은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어함. 제한 시간이 경과하기 전에 응답이 수신되지 않으면 클라이언트는 필요한 경우 요청을 다시 보내거나, 재시도가 소진되면 요청에 실패함. 이 값은 replica.lag.time.max.ms (broker config)보다 커야 불필요한 producer 재시도로 인한 메시지 중복 가능성을 줄일 수 있음 유효한 값 : 0,… |
|
| security.protocol | PLAINTEXT | 브로커와 통신하는 데 사용되는 프로토콜 유효한 값 : PLAINTEXT, SSL, SASL_PLAINTEXT SASL_SSL |
|
| send.buffer.bytes | 131072 (128 kibibytes) | 데이터를 보낼 때 사용할 TCP 송신 버퍼(SO_SNDBUF)의 크기. 값이 -1이면 OS기본값이 사용됨 유효한 값 : -1,… |
|
| socket.connection.setup.timeout.max.ms | 30000 (30 seconds) | 소켓 연결이 설정될 때까지 클라이언트가 대기하는 최대 시간 연결 설정 시간 제한은 이 최대값까지 각 연속 연결 실패에 대해 기하급수적으로 증가 연결 스톰을 방지하기위해 시간 제한에 임의화 계수 0.2가 적용되어 계산된 값보다 20% 낮거나, 20% 높은 임의 범위가 됨 |
|
| socket.connection.setup.timeout.ms | 10000 (10 seconds) | 소켓 연결이 설정될 때까지 클라이언트가 대기하는 시간 제한시간이 경과하기 전에 연결이 구축되지 않으면, 클라이언트는 소켓 채널을 닫음 이 값은 초기 backoff값이며 각 연속 연결 실패에 대해 socket.connection.setup.timeout.max.ms 값까지 기하급수적으로 증가함 |
|
| importance : low | |||
| acks | all | producer가 요청 완료를 고려하기 전에 리더에게 받아야 하는 승인 수. 이렇게 하면 전송되는 레코드의 내구성이 제어됨 [허용되는 설정] 1) acks=0 0으로 설정하면 생산자는 서버의 승인을 전혀 기다리지 않습니다. 레코드는 즉시 소켓 버퍼에 추가되고 전송된 것으로 간주됩니다. 이 경우 서버가 레코드를 수신했다고 보장할 수 없으며 클라이언트가 일반적으로 오류를 알지 못하기 때문에 retries config가 적용되지 않습니다. 각 레코드에 대해 다시 제공된 오프셋은 항상 -1로 설정됩니다. 2) acks=1 이는 리더가 로컬 로그에 레코드를 기록하지만 모든 팔로워의 완전한 승인을 기다리지 않고 응답한다는 것을 의미. 이 경우 리더가 레코드를 승인한 직후 실패하지만 팔로워가 복제하기 전에 실패하면 레코드가 손실됨. 3) acks=all 리더는 동기화된 복제본의 전체 집합이 레코드를 승인할 때까지 기다림. 이렇게 하면 하나 이상의 동기화된 복제본이 활성 상태로 유지되는 한 레코드가 손실되지 않음. 이는 acks=-1 설정과 동일 |
|
| auto.include.jmx.reporter | TRUE | 사용되지 않음 | |
| enable.idempotence | TRUE | true'로 설정하면 producer는 각 메시지의 복사본이 스트림에 정확히 하나만 기록되도록 함. 'false'인 경우 브로커 실패 등으로 인해 producer가 재시도하면 재시도된 메시지의 복제본을 스트림에 기록할 수 있음. 멱등성을 활성화하려면 max.in.flight.requests.per.connection이 5보다 작거나 같아야하고(허용 가능한 값에 대해 메시지 순서가 유지됨), retries옵션은 0보다 커야하며, acks옵션 값은 'all'이어야 함. 충돌하는 구성이 설정되지 않은 경우, 멱등원이 기본적으로 활성화됨 .충돌하는 구성이 설정되고 멱등성이 명시적으로 활성화되지 않은 경우, 멱등성이 비활성화됨 멱등성이 명시적으로 활성화되고 충돌하는 구성이 설정되면 ConfigException가 발생됨 |
|
| enable.metrics.push | TRUE | 클러스터에 이 클라이언트와 일치하는 클라이언트 메트릭 구독이 있는 경우 클러스터에 클라이언트 메트릭을 푸시할 수 있는지 여부 | |
| interceptor.classes | "" | 인터셉터로 사용할 클래스 목록 org.apache.kafka.clients.producer.ProducerInterceptor인터페이스를 구현하면 kafka 클러스터에 게시되기 전에 producer가 수신한 레코드를 가로채고 변경할 수 있음. 기본적으로 인터셉트는 없음 유효한 값 : non-null string |
|
| max.in.flight.requests.per.connection | 5 | 클라이언트가 차단하기 전에 단일 연결에서 보낼 승인되지 않은 요청의 최대 수. 이 구성이 1보다 크게 설정되고 enable.idempotence가 false로 설정된 경우 재시도로 인해 전송에 실패한 후( 즉, 재시도가 활성화 된 경우), 메시지 순서가 다시 지정될 위험이 있음. 재시도가 비활성화되거나, enable.idempotence가 true로 설정된 경우 순서가 유지됨. 또한 멱등성을 사용하도록 설정하려면 이 구성의 값이 5보다 작거나 같아야함. 충돌하는 구성이 설정되고 멱등성이 명시적으로 활성화되지 않은 경우 멱등성이 비활성화됨. 유효한값 : 1,... |
|
| metadata.max.age.ms | 300000 (5 minutes) | 파티션 리더십 변경 사항이 없는 경우에도 새 브로커 또는 파티션을 사전에 검색하기 위해 메타데이터를 강제로 새로 고치는 시간(밀리초) 유효한 값 : 0,... |
|
| metadata.max.idle.ms | 300000 (5 minutes) | 생산자가 유휴 상태인 주제에 대한 메타데이터를 캐시하는 기간을 제어함 topic 이 마지막으로 생성된 이후 경과된 시간이 메타데이터 유휴 기간을 초과하면 topic의 메타데이터가 잊혀지고 다음에 해당항목에 액세스할 때 메타데이터 가져오기 요청이 강제 실행됨 유효한 값 : 5000,… |
|
| metric.reporters | "" | 메트릭 리포터로 사용할 클래스 목록. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성에 대한 알림을 받을 클래스를 연결할 수 있음. JMX 통계를 등록하기 위해 JmxReporter 가 항상 포함됨 유효한 값 : non-null string |
|
| metrics.num.samples | 2 | 메트릭을 계산하기 위해 유지되는 샘플 수 유효한 값: 1,… |
|
| metrics.recording.level | INFO | 메트릭에 대한 가장 높은 기록 수준 유효한 값 : INFO, DEBUG, TRACE |
|
| metrics.sample.window.ms | 30000 (30 seconds) | 메트릭 샘플이 계산되는 기간 유효한 값 : 0,... |
|
| partitioner.adaptive.partitioning.enable | TRUE | 1) 'true'로 설정하면 producer는 브로커 성능에 적응하고 더 빠른 브로커에서 호스팅되는 파티션에 더 많은 메시지를 생성하려고 함. 2) 'false'인경우 producer는 메시지를 균일하게 배포하려고 함. ( 참고 : 이 설정은 사용자 지정 파티셔너를 사용하는 경우 적용되지 않음 ) |
|
| partitioner.availability.timeout.ms | 0 | 브로커가 partitioner.availability.timeout.ms시간 동안 파티션의 생성 요청을 처리할 수 없는 경우, 파티셔너는 해당 파티션을 사용할 수 없는 것으로 처리함. 값이 0이면 이 논리를 사용할 수 없음 (참고 : 이 설정은 사용자 지정 파티셔너를 사용하거나 partitioner.adaptive.partitioning.enable가 'false'로 설정된 경우에는 적용되지 않음 ) 유효한 값 : 0,... |
|
| reconnect.backoff.max.ms | 1000 (1 second) | 반복적으로 연결에 실패한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초) 제공된 경우 호스트당 백오프는 각 연속 연결 실패에 대해 이 최대값까지 기하급수적으로 증가하며 백오프를 계산한 후 연결 폭풍을 피하기 위해 20% 임의 지터가 추가됨 유효한 값 : 0,... |
|
| reconnect.backoff.ms | 50 | 지정된 호스트에 다시 연결을 시도하기 전에 대기하는 기본 시간 이렇게 하면 긴밀한 루프에서 호스트에 반복적으로 연결하는 것을 방지할 수 있음. 이 백오프는 클라이언트가 브로커에 시도하는 모든 연결 시도에 적용됨. 이 값은 초기 백오프 값이며 각 연속 연결 실패에 대해 reconnect.backoff.max.ms값까지 기하급수적으로 증가함. 유효한 값 : 0,… |
|
| retry.backoff.max.ms | 1000 (1 second) | 반복적으로 실패한 브로커에 대한 요청을 재시도할 때 대기하는 최대 시간(밀리초) 제공된 경우 클라이언트당 백오프는 실패한 각 요청에 대해 이 최대값까지 기하급수적으로 증가함. 재시도시 모든 클라이언트가 동기화되지 않도록 하기 위해 계수가 0.2인 임의 지터가 백오프에 적용되어 백오프가 계산된 값보다 20% 낮거나 20% 높은 범위 내에 속함. retry.backoff.ms가 retry.backoff.max.ms보다 높게 설정된 경우,retry.backoff.max.ms는 기하급수적 증가없이 처음부터 일정한 백오프로 사용됨 유효한 값 : 0,... |
|
| retry.backoff.ms | 100 | 지정된 topic 파티션에 대해 실패한 요청을 재시도하기 전에 대기하는 시간. 이렇게하면 일부 실패 시나리오에서 긴필한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있음 이 값은 초기 백오프 값이며 실패한 각 요청에 대해 해당 retry.backoff.max.ms값까지 기하급수적으로 증가함 |
|
| security.providers | null | 각각 보안 알고리즘을 구현하는 공급자를 반환하는 구성 가능한 작성자 클래스 목록 이러한 클래스는 org.apache.kafka.common.security.auth.SecurityProviderCreator를 구현해야 함 |
|
| transaction.timeout.ms | 60000 (1 minute) | 코디네이터가 사전에 중단하기 전에 트랜잭션이 열린 상태로 유지되는 최대 시간(밀리초) 트랜잭션의 시작은 첫 번째 파티션이 추가될 때 설정됨. 이 옵션의 값이 브로커에 설정된 transaction.max.timeout.ms이 값보다 크면 InvalidTxnTimeoutException 오류가 발생하여 요청이 실패함 |
|
| transactional.id | null | 트랜잭션 배달에 사용할 TransactionalId 이렇게 하면 클라이언트가 새 트랜잭션을 시작하기 전에 동일한 TransactionalId를 사용하는 트랜잭션이 완료되었음을 보장할 수 있으므로 여러 생산자 세션에 걸쳐 있는 안정성 의미 체계를 사용할 수 있음 TransactionalId가 제공되지 않으면 producer는 idempotent 배달로 제한되며 TransactionalId가 구성된 경우, enable.idempotence는 암시적임. 본적으로 TransactionId는 구성되지 않으므로 트랜잭션을 사용할 수 없음. 또한 ,트랜잭션에는 프로덕션에 권장되는 설정인 최소 3개의 브로커로 구성된 클러스터가 필요함. 개발의 경우, 브로커에 설정된 transaction.state.log.replication.factor를 조정하여 이를 변경할 수 있음 |
|