| 재산 | 기본값 | 묘사 |
| broker.id | | 각 브로커는 고유한 음수 정수 ID로 식별할 수 있으며; 이 ID는 브로커의 "이름"으로 사용할 수 있으며, 이 ID의 존재 덕분에 브로커가 다른 호스트/포트로 이동할 때 소비자가 혼동하지 않습니다. ID가 고유해야 원하는 번호를 ID로 선택할 수 있습니다. |
| log.dirs | /tmp/kafka-logs | 카프카가 데이터를 저장하는 경로. 이 경로는 유일하지 않으며, 여러 개일 수 있고, 경로들은 쉼표로만 구분하면 됩니다; 새 파티션이 생성될 때마다, 파티션 수가 가장 적은 경로 아래에서 생성되도록 선택됩니다. |
| 항구 | 6667 | 서버는 클라이언트가 연결하는 포트를 받아들입니다 |
| Zookeeper.connect. | 영 | ZooKeeper 연결 문자열의 형식은 hostname:port이며, 여기서 hostname과 port는 각각 ZooKeeper 클러스터 내 노드의 호스트와 포트입니다. 호스트가 다운되었을 때 다른 ZooKeeper 노드와 연결하려면 다음과 같이 여러 호스트를 생성할 수 있습니다:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper는 클러스터 내 모든 카프카 데이터를 특정 경로로 저장하는 'chroot' 경로를 추가할 수 있게 해줍니다. 여러 Kafka 클러스터나 다른 애플리케이션이 동일한 ZooKeeper 클러스터를 사용할 경우, 이 방법을 사용해 데이터 저장 경로를 설정할 수 있습니다. 이는 연결 문자열을 다음과 같이 포맷하여 구현할 수 있습니다:
호스트이름1:포트1, 호스트네임2:포트2, 호스트네임3:포트3/chroot/패스
이 구성은 모든 kafka 클러스터 데이터를 /chroot/path 경로 아래에 저장합니다. 브로커를 시작하기 전에 반드시 이 경로를 만들어야 하며, 소비자도 동일한 연결 형식을 사용해야 합니다. |
| message.max.bytes | 1000000 | 서버가 받을 수 있는 메시지 최대 크기입니다. 이 특성에 대한 소비자와 생산자의 설정이 동기화되어야 하며, 그렇지 않으면 생산자가 전달하는 메시지가 소비자에게 너무 커집니다. |
| num.network.threads | 3 | 서버가 네트워크 요청을 처리하는 데 사용하는 네트워크 스레드 수; 일반적으로 이 부동산을 변경할 필요는 없습니다. |
| num.io.threads | 8 | 서버가 요청을 처리하는 데 사용하는 I/O 스레드 수; 스레드 수는 적어도 하드 디스크 수와 같아야 합니다. |
| 배경.스레드 | 4 | 백그라운드 처리(예: 파일 삭제)에 사용되는 스레드 수; 이 부동산을 변경할 필요는 없습니다. |
| queued.max.requests | 500 | 네트워크 스레드가 새 요청을 읽지 않기 전에 I/O 스레드가 처리할 수 있는 최대 요청 수입니다. |
| host.name | 영 | 중개인의 호스트네임; 호스트네임이 이미 설정되어 있다면, 브로커는 이 주소에만 묶여 있습니다; 설정이 없으면 모든 인터페이스에 바인딩되어 ZK에 한 복사본을 배포합니다 |
| advertised.host.name | 영 | 설정이 이루어지면, 이는 브로커의 호스트 이름으로 생산자, 소비자 및 기타 브로커에게 전송됩니다 |
| advertized.port | 영 | 이 포트는 생산자, 소비자 및 기타 중개인에게 제공되며, 연결을 구축하는 데 사용됩니다; 실제 포트와 서버가 바인딩해야 할 포트가 다를 때만 설정하면 됩니다. |
| 소켓.센드.버퍼.바이트 | 100 * 1024 | SO_SNDBUFF 서버가 소켓 연결을 위해 사용하는 캐시 크기입니다 |
| 소켓.수신.버퍼.바이트 | 100 * 1024 | SO_RCVBUFF 서버가 소켓에 연결하는 데 사용하는 캐시 크기입니다 |
| socket.request.max.바이트 | 100 * 1024 * 1024 | 서버가 허용하는 최대 요청 크기; 이렇게 하면 서버 오버플로우가 자바 힙 크기보다 작아야 하므로 이를 방지할 수 있습니다 |
| num.partitions | 1 | 주제를 생성할 때 파티션 수가 알려지지 않으면, 이 숫자가 주제 하의 기본 파티션 수가 됩니다. |
| 로그.세그먼트.바이트 | 1014*1024*1024 | 주제 파티션의 로그는 특정 디렉터리의 여러 파일에 저장되며, 이 파일들은 파티션의 로그를 여러 구간으로 나눕니다; 이 속성은 각 파일의 최대 크기를 의미합니다; 치수가 이 값에 도달하면 새 파일이 생성됩니다. 이 설정은 각 주제의 기초에 의해 무시될 수 있습니다.
전망 하이퍼링크 로그인이 보입니다. |
| 로그롤 시간 | 24 * 7 | 파일이 log.segment.bytes에 도달하지 않더라도, 파일 생성 시간이 이 속성에 도달할 때마다 새 파일이 생성됩니다. 이 설정은 주제 수준 설정으로도 덮어쓸 수 있습니다;
보기하이퍼링크 로그인이 보입니다. |
| log.cleanup.policy | 삭제 | |
| log.retention.minutes 및 log.retention.hours | 7일 | 각 로그 파일이 삭제되기 전에 저장된 시간입니다. 기본 데이터 절약 시간은 모든 주제에서 동일합니다.
log.retention.minutes와 log.retention.bytes는 오버플로우된 속성과 관계없이 로그 파일 삭제 설정에 사용됩니다.
이 속성 설정은 주제가 기본적으로 설정되었을 때 무시할 수 있습니다.
보기하이퍼링크 로그인이 보입니다. |
| 로그.리텐션.바이트 | -1 | 각 주제 아래 각 파티션이 저장한 총 데이터 양; 이는 파티션당 상한선이므로 이 숫자에 파티션 수를 곱하면 주제당 저장된 총 데이터 양이 됩니다. 참고: log.retention.hours와 log.retention.bytes가 모두 설정되어 있을 경우, 어느 한도를 초과하면 세그먼트 파일이 삭제됩니다.
이 설정은 각 주제에서 무시될 수 있다는 점에 유의하세요.
보기하이퍼링크 로그인이 보입니다. |
| log.retention.check.interval.ms | 5분 | 로그 세그먼트 파일 간의 간격을 확인하여 파일 속성이 삭제 요구사항을 충족하는지 확인하세요. |
| log.cleaner.enable | false | 이 속성이 false로 설정되면, 로그가 최대 시간 또는 크기로 저장되면 삭제됩니다. true로 설정하면 저장 속성이 상한에 도달할 때 발생합니다하이퍼링크 로그인이 보입니다.。 |
| log.cleaner.threads | 1 | 로그 압축을 수행하는 스레드 수 |
| log.cleaner.io.max.비트 단위 | 없음 | 로그 컴팩션을 수행할 때 로그 클리너가 가질 수 있는 최대 I/O의 수입니다. 이 설정은 청소 서비스를 제한하여 활성 요청 서비스에 간섭하지 않도록 합니다. |
| log.cleaner.io.buffer.size | 500*1024*1024 | 로그 클리너는 정리 과정에서 로그를 인덱싱하고 사용되는 캐시 크기를 줄입니다. 충분한 메모리를 확보하려면 크기를 크게 설정하는 것이 가장 좋습니다. |
| log.cleaner.io.buffer.load.factor | 512*1024 | 로그 청소에 필요한 I/O 청크의 크기. 이 설정을 바꿀 필요는 없습니다. |
| log.cleaner.io.buffer.load.factor | 0.9 | 로그 정리에 사용되는 해시 테이블의 부하 계수; 이 옵션을 변경할 필요는 없습니다. |
| log.cleaner.backoff.ms | 15000 | 로그가 정리되는 시간 간격이 수행됩니다 |
| log.cleaner.min.cleanable.ratio | 0.5 | 이 구성은 로그 압축기가 로그 정리를 얼마나 자주 시도하는지를 제어합니다(가정하이퍼링크 로그인이 보입니다.열려 있습니다). 기본적으로 로그의 50% 이상을 청소하지 마세요. 이 비율은 백업 로그가 차지하는 최대 공간(로그의 50%가 50%로 압축됨)과 연동됩니다. 높은 비율은 폐기물이 줄고 더 넓은 공간을 더 효율적으로 정리할 수 있다는 뜻입니다. 이 설정은 각 주제 설정에서 무시할 수 있습니다.
보기하이퍼링크 로그인이 보입니다.。 |
| log.cleaner.delete.retention.ms | 하루 | 저장 시간; 압축된 로그를 보관하는 최대 시간; 또한 클라이언트가 메시지를 소비할 수 있는 최대 시간이며, log.retention.minutes의 차이는 하나는 압축되지 않은 데이터를 제어하고 다른 하나는 압축된 데이터를 제어한다는 점이며, 이 데이터는 주제가 생성될 때 지정된 시간에 덮어쓰입니다. |
| log.index.size.max.바이트 | 10*1024*1024 | 로그 세그먼트당 최대 크기. 로그 크기가 이 값에 도달하면, 크기가 log.segment.bytes 한도를 초과하지 않더라도 새로운 로그 세그먼트를 생성해야 합니다. |
| log.index.interval.bytes | 4096 | 페치를 수행할 때는 일정 공간이 있는 가장 가까운 오프셋을 스캔해야 하며, 설정이 클수록 좋습니다. 일반적으로 기본값을 사용하세요 |
| log.flush.interval.messages | 롱맥스밸류 | 메시지가 쌓이기 전에 디스크에 파일 "동기화"를 기록하세요. 디스크 IO 작업은 느린 작업이지만 "데이터 신뢰성"을 위한 필수 수단이므로, 하드 디스크에 경화하는 시간 간격이 필요한지 확인하세요. 이 값이 너무 크면 '동기화' 시간이 너무 길어지고(IO 차단), 너무 작으면 'fsync'(IO 차단)가 길어지며, 너무 작으면 많은 '동기화' 시간이 발생하여 전체 클라이언트 요청에 일정 지연이 발생하고, 물리적 서버가 실패하면 fsync 없이 메시지가 손실됩니다. |
| log.flush.scheduler.interval.ms | 롱맥스밸류 | fsync 간격이 필요한지 확인해 보세요 |
| log.flush.interval.ms | 롱맥스밸류 | 이 숫자는 "fsync" 시간 간격을 제어하는 데 사용되며, 메시지 수가 디스크에 고정된 메시지 수에 도달하지 못하지만 마지막 디스크 동기화 시점의 시간 간격이 임계값에 도달하면 디스크 동기화도 함께 트리거됩니다. |
| log.delete.delay.ms | 60000 | 인덱스에서 파일이 삭제된 후 보존 시간은 일반적으로 수정할 필요가 없습니다 |
| auto.create.topics.enable | true | 주제 자동 생성 허용 여부. 만약 사실이라면, produce 또는 fetch가 존재하지 않을 때 존재하지 않는 주제가 자동으로 생성됩니다. 그렇지 않으면 명령줄을 사용해 주제를 만들어야 합니다 |
| controller.socket.timeout.ms | 30000 | 파티션 관리 컨트롤러가 백업을 수행할 때 소켓의 타임아웃 시간입니다. |
| controller.message.queue.size | 지능.최대 가치 | controller-to-broker-channles |
| default.replication.factor | 1 | 기본 백업 복사본 수는 자동으로 생성된 주제에만 해당됩니다 |
| replica.lag.time.max.ms | 10000 | 이 시간 내에 추종자가 호출을 보내지 않으면, 리더는 그 추종자를 ISR에서 다시 제거하고 그 추종자를 행 상태에 놓은 것으로 간주합니다 |
| replica.lag.max.메시지 | 4000 | 복제체에 백업되지 않은 수가 이 이상이라면, 리더는 팔로워를 제거하고 팔로워를 교수형 상태로 간주합니다 |
| replica.socket.timeout.ms | 30*1000 | 데이터 백업 시 소켓 네트워크 요청에 대한 리더 타임아웃 시간 |
| 복제본.소켓.수신.buffer.바이트 | 64*1024 | 백업 중 리더에게 네트워크 요청을 보낼 때 소켓 수신 버퍼가 발생합니다 |
| replica.fetch.max.바이트 | 1024*1024 | 백업 시점의 각 페치의 최대 값 |
| 복제본.fetch.min.bytes | 500 | 리더가 백업 요청을 할 때 데이터가 리더에 도달하는 최대 대기 시간입니다 |
| 복제본.fetch.min.bytes | 1 | 백업할 때 각 페치 후 응답 크기가 가장 작아야 |
| num.replica.fetchers | 1 | 리더의 데이터를 뒷받침하는 스레드 수 |
| replica.high.watermark.checkpoint.interval.ms | 5000 | 각 복제품은 가장 높은 수위가 얼마나 자주 경화되는지 확인합니다 |
| fetch.purgatory.purge.interval.requests | 1000 | fetch 요청 정지 간격 |
| producer.purgatory.purge.interval.requests | 1000 | 프로듀서가 정지 간격을 요청함 |
| zookeeper.session.timeout.ms | 6000 | 동물원 사육사 세션 타임아웃. |
| zookeeper.connection.timeout.ms | 6000 | 클라이언트가 zookeeper와 연결을 구축하기 위해 기다리는 최대 시간 |
| zookeeper.sync.time.ms | 2000 | ZK 팔로워가 오랫동안 ZK 리더에 뒤처져 있다 |
| 제어.종료.활성화 | true | 중개인의 폐쇄를 통제할 수 있는지 여부에 대해서도 중요합니다. 가능하다면, 중개인은 모든 리더를 다른 중개인으로 이전할 수 있습니다. 이로 인해 셧다운 과정 중 사용 불가가 줄어듭니다. |
| controlled.shutdown.max.retries | 3 | 불완전한 종료를 수행하기 전에 성공적으로 종료를 실행할 수 있는 명령의 수입니다. |
| controlled.shutdown.retry.backoff.ms | 5000 | 셧다운 사이의 후퇴 시간 |
| auto.leader.rebalance.enable | true | 만약 이 경우, 컨트롤러는 자동으로 분할 간 브로커의 리더십을 균형 있게 조정합니다 |
| leader.imbalance.per.broker.percent | 10 | 각 중개인이 허용하는 최대 불균형 비율 |
| 리더.불균형.체크.간격.초 | 300 | 리더 불균형의 빈도를 확인하세요 |
| offset.metadata.max.비트 | 4096 | 클라이언트가 오프셋을 최대한 저장할 수 있게 해줍니다 |
| max.connections.per.ip | 지능.최대 가치 | 각 IP 주소마다 브로커당 최대 연결 수 수 있습니다 |
| max.connections.per.ip.overrides | | IP 또는 호스트명별 기본 연결 최대 커버리지 |
| connections.max.idle.ms | 600000 | 빈 연결에 대한 타임아웃 제한 |
| 로그.롤.지터. {ms,hours} | 0 | logRollTimeMillis에서 추상화한 최대 지터 수 |
| num.recovery.threads.per.data.dir | 1 | 각 데이터 디렉터리가 복구 로그에 사용하는 스레드 수 |
| unclean.leader.election.enable | true | ISR에서 비복제체 설정을 리더로 사용할 수 있는지 여부를 나타냅니다 |
| delete.topic.enable | false | 주제를 삭제할 수 있습니다 |
| offsets.topic.num.partitions | 50 | 오프셋 커밋 주제의 파티션 수. 배포 후 이 설정을 변경하는 것은 현재 지원되지 않기 때문에, 프로덕션에서는 더 높은 설정(예: 100-200)을 사용하는 것을 권장합니다. |
| offsets.topic.retention.minutes | 1440 | 이 시간 제한을 초과한 오프셋은 삭제 대기 상태로 표시됩니다 |
| offsets.retention.check.interval.ms | 600000 | 오프셋 매니저는 오래된 오프셋의 빈도를 확인합니다 |
| offsets.topic.replication.factor | 3 | 주제 오프셋의 백업 복사본 수. 더 높은 가용성을 보장하기 위해 더 높은 숫자를 설정하는 것이 권장됩니다 |
| offset.topic.segment.bytes | 104857600 | 상쇄 주제. |
| offsets.load.buffer.size | 5242880 | 이 설정은 배치 크기와 관련이 있으며, 오프셋 세그먼트에서 읽을 때 사용됩니다. |
| offsets.commit.required.acks | -1 | 오프셋 커밋이 허용되기 전에 확인 횟수를 설정해야 하며, 일반적으로 변경할 필요가 없습니다 |
| 재산 | 기본값 | 서버 기본 속성 | 묘사 |
| cleanup.policy | 삭제 | log.cleanup.policy | "delete" 또는 "compact" 중 하나; 이 문자열은 오래된 통나무 부분을 어떻게 활용하는지를 나타냅니다; 기본 방법("delete")은 재활용 시간이나 크기 한도에 도달하면 기존 부품을 폐기합니다. "컴팩트"는 통나무를 압축합니다 |
| delete.retention.ms | 86400000 (24시간) | log.cleaner.delete.retention.ms | log.retention.minutes의 차이점은 하나는 압축되지 않은 데이터를 제어하고, 다른 하나는 압축된 데이터를 제어한다는 점입니다. 이 구성은 주제가 생성될 때 고정 매개변수에 의해 무시될 수 있습니다 |
| flush.messages | 없음 | log.flush.interval.messages | 이 구성은 fsync 로그를 강제로 진행하는 시간 간격을 지정합니다. 예를 들어, 이 옵션을 1로 설정하면 각 메시지 뒤에 fsync가 필요하고, 5로 설정하면 5개 메시지마다 fsync가 필요합니다. 일반적으로 이 값을 설정하지 않는 것이 권장됩니다. 이 매개변수를 설정하려면 "데이터 신뢰성"과 "성능" 사이의 필수적인 절충이 필요합니다. 이 값이 너무 크면 매번 오랜 시간 동안 "fsync"가 발생하는데(IO 차단), 너무 작으면 많은 "fsync"가 발생하여 전체 클라이언트 요청에 일정 지연이 생깁니다. 물리적 서버 장애는 fsync가 없으면 메시지가 사라지게 됩니다. |
| flush.ms | 없음 | log.flush.interval.ms | 이 구성은 fsync 로그를 강제로 디스크에 입력하는 시간 간격을 고정하는 데 사용됩니다; 예를 들어, 1000으로 설정하면 1000ms마다 fsync가 필요합니다. 이 옵션은 일반적으로 권장되지 않습니다 |
| index.interval.bytes | 4096 | log.index.interval.bytes | 기본 설정은 메시지에 4096바이트마다 인덱스를 추가하도록 보장하며, 인덱스가 많을수록 읽은 메시지가 더 가까워지지만 인덱스 크기는 커집니다. 이 옵션은 일반적으로 필수는 아닙니다 |
| 맥스.메시지.바이트 | 1000000 | 맥스.메시지.바이트 | 카프카 부가 메시지의 최대 크기. 이 크기를 늘리면 소비자가 메시지를 최대 크기로 가져오기 수 있도록 페치 크기도 함께 늘려야 합니다. |
| 최소 청소 가능 오염 비율 | 0.5 | 최소 청소 가능 오염 비율 | 이 구성은 로그 압축기가 원목을 얼마나 자주 제거하려 하는지 조절합니다. 기본적으로 압축률이 50%를 초과하는 로그는 피합니다. 이 비율은 공간 낭비를 최소화합니다 |
| min.insync.replicas | 1 | min.insync.replicas | 프로듀서가 request.required.acks를 -1로 설정하면, min.insync.replicas는 최소 레플리본 수를 지정하며(각 repica 쓰기가 성공해야 합니다), 이 수에 도달하지 못하면 프로듀서는 예외를 생성합니다. |
| retention.bytes | 없음 | 로그.리텐션.바이트 | "delete" 보존 정책을 사용할 경우, 이 구성은 로그가 삭제되기 전에 도달할 수 있는 최대 크기를 의미합니다. 기본적으로 크기 제한은 없고 시간 제한만 있습니다 |
| retention.ms | 7일 | 기록.유지.분 기록 | "delete" 보존 정책을 사용한다면, 이 구성은 삭제 기록보다 로그가 저장된 시점을 의미합니다. |
| segment.bytes | 1GB | 로그.세그먼트.바이트 | Kafka에서는 로그 로그가 청크로 저장되며, 이 구성은 로그 로그를 청크로 나눈 크기를 의미합니다 |
| segment.index.bytes | 10MB | log.index.size.max.바이트 | 이 구성은 오프셋과 파일 위치 사이에 매핑된 인덱스 파일의 크기와 비슷합니다; 이 구성은 일반적으로 수정할 필요가 없습니다 |
| segment.ms | 7일 | 로그롤 시간 | 로그 청크 파일이 삭제하거나 압축해야 할 크기에 미치지 못하더라도, 로그 시간이 이 상한에 도달하면 새로운 로그 청크 파일이 강제로 생성됩니다 |
| segment.jitter.ms | 0 | 로그.롤.지터. {ms,hours} | logRollTimeMillis에서 빼는 최대 지터입니다. |
| 재산 | 기본값 | 묘사 |
| group.id | | 소비자 프로세스가 위치한 그룹을 고유하게 식별하는 문자열이며, 동일한 그룹 ID가 설정되어 있으면 이 프로세스들이 동일한 소비자 그룹에 속함을 의미합니다 |
| Zookeeper.connect. | | Zookeeper 연결 문자열을 지정하세요. 형식은 hostname:port입니다. 여기서 호스트와 포트는 Zookeeper 서버의 호스트이자 포트입니다. Zookeeper 머신이 다운된 후 연결이 끊기지 않도록, 쉼표를 구분하여 여러 hostname:port를 지정할 수 있습니다:
호스트 이름1: 포트1, 호스트네임 2:포트2, 호스트네임 3:포트3
ZooKeeper의 chroot 경로를 ZooKeeper 연결 문자열에 추가할 수 있는데, 이 연결 문자열은 자체 데이터를 저장하는 데 사용됩니다:
호스트이름1:포트1, 호스트네임2:포트2, 호스트네임3:포트3/chroot/패스 |
| consumer.id | 영 | 설정이 필요 없으며 일반적으로 자동으로 생성됩니다 |
| socket.timeout.ms | 30*100 | 네트워크 요청에 대한 타임아웃 제한. 실제 타임아웃 제한은 max.fetch.wait+socket.timeout.ms입니다 |
| 소켓.수신.버퍼.바이트 | 64*1024 | 소켓은 네트워크 요청의 캐시 크기를 수신하는 데 사용됩니다 |
| fetch.message.max.바이트 | 1024*1024 | 페치 요청당 페치 메시지당 최대 바이트 수. 이 바이트들은 각 파티션에 사용되는 메모리에서 감독되므로, 이 설정은 소비자가 사용하는 메모리 양을 제어합니다. 가져오기 요청 크기는 서버가 허용하는 최대 메시지 크기와 같아야 하며, 그렇지 않으면 제작자가 보낼 수 있는 메시지 크기가 소비자가 소비할 수 있는 크기보다 커집니다. |
| num.consumer.fetchers | 1 | 페치 데이터에 사용되는 페처 스레드 수 |
| auto.commit.enable | true | 만약 그렇다면, 소비자가 가져온 메시지의 오프셋이 자동으로 동물원 키퍼와 동기화됩니다. 이 커밋 오프셋은 프로세스가 종료될 때 새 소비자가 사용합니다 |
| auto.commit.interval.ms | 60*1000 | 소비자가 사육사에게 오프셋을 제출하는 빈도는 초 단위입니다 |
| queued.max.message.chunks | 2 | 캐시에 사용되는 최대 메시지 수. 각 청크는 fetch.message.max.바이트와 동일해야 합니다 |
| rebalance.max.retries | 4 | 새로운 소비자가 소비자 그룹에 추가되면, 소비자 집합은 각 소비자에게 할당된 파티션 수를 재조정하려고 시도합니다. 소비자 컬렉션이 변경되면 이 재균형은 실패하고 할당이 실행될 때 재조정됩니다 |
| fetch.min.bytes | 1 | 서버가 각 fetch 요청마다 반환해야 할 최소 바이트 수입니다. 데이터가 충분하지 않으면, 충분한 데이터가 반환될 때까지 요청이 기다립니다. |
| fetch.wait.max.ms | 100 | fetch.min.bytes를 만족할 만큼 충분한 데이터가 없을 경우, 이 구성은 서버가 fetch 요청에 응답하기 전에 차단할 수 있는 최대 시간을 의미합니다. |
| rebalance.backoff.ms | 2000 | Reblance를 다시 시도하기 전에 물러날 시간입니다 |
| refresh.leader.backoff.ms | 200 | 분할의 지도자가 지도력을 잃었는지 판단하기 전에 후퇴 시간이 있다 |
| auto.offset.reset | 가장 큰 | Zookeeper에 초기화된 오프셋이 없으면, 오프셋이 다음 값에 대한 응답이라면:
최소: 자동 리셋 오프셋을 가장 작은 오프셋으로
가장 큰 것: 자동 리셋 오프셋을 최대 오프셋으로
그 외: 소비자에게 예외를 부여합니다 |
| consumer.timeout.ms | -1 | 특정 시간을 기다려도 메시지가 없으면 타임아웃 예외가 발기됩니다 |
| exclude.internal.topics | true | 내부 주제에서 온 메시지를 소비자에게 노출할지 여부 |
| 파리티션.할당.전략 | 범위 | 소비자 흐름에 파티션을 할당하는 정책을 선택하고, 선택적으로 범위, 라운드로빈 |
| client.id | 그룹 ID 값 | 각 요청에서 통화를 추적하는 데 도움을 주는 사용자 전용 문자열입니다. 요청을 생성한 애플리케이션이 논리적으로 확인되어야 합니다 |
| zookeeper.session.timeout.ms | 6000 | 사육사 세션의 타임아웃 제한. 이 시간 동안 소비자가 동물원 사육사에게 심장박동 메시지를 보내지 않으면, 해당 메시지는 끊긴 것으로 간주되어 리블런스가 생성됩니다 |
| zookeeper.connection.timeout.ms | 6000 | 클라이언트가 Zookeeper 연결을 설정하는 데 걸리는 최대 대기 시간입니다 |
| zookeeper.sync.time.ms | 2000 | ZK 팔로워는 최대 시간 동안 ZK 리더보다 뒤처질 수 있습니다 |
| offsets.storage | 사육사 | 오프셋을 보관하는 장소: 동물원 사육사 또는 카프카 |
| offset.channel.backoff.ms | 1000 | 오프셋 채널에 다시 연결하거나 실패한 오프셋의 fetch/커밋 요청을 재시도하는 백오프 시간입니다 |
| offsets.channel.socket.timeout.ms | 10000 | 오프셋을 읽을 때 fetch/commit 요청 응답에 대한 소켓 타임아웃 제한. 이 타임아웃 제한은 consumerMetadata 요청에서 오프셋 관리를 요청하는 데 사용됩니다 |
| offsets.commit.max.retries | 5 | 오프셋 커밋이 재시도된 횟수. 이 재시도는 종료 사이의 오프셋 커밋에만 적용됩니다. 그 사람 |
| dual.commit.enabled | true | offsets.storage로 "kafka"를 사용하면 Zookeeper에 offset을 두 번(그리고 kafka에 한 번) 커밋할 수 있습니다. Zookeeper 기반 오프셋 저장에서 kafka 기반 오프셋 저장으로 전환할 때 반드시 필요한 기능입니다. 어떤 소비자 그룹이든 마이그레이션이 완료되면 이 옵션을 끄는 것이 안전한 권장사항입니다 |
| partition.assignment.strategy | 범위 | 소비자 데이터플로우에 파티션을 할당하는 정책으로서 "범위"와 "라운드로빈" 정책 중 하나를 선택하세요; 원형 파티션 할당기는 모든 사용 가능한 파티션과 모든 사용 가능한 소비자 스레드를 할당합니다. 파티션 루프를 소비자 스레드에 할당합니다. 모든 소비자 인스턴스가 결정된 분포에 가입되어 있다면, 분할은 결정론적 분포로 나뉩니다. 라운드로빈 할당 전략은 다음 조건이 충족될 때만 가능합니다: (1) 각 주제가 소비자 강도당 동일한 데이터 흐름 수를 가진다. (2) 구독된 주제의 집합은 각 소비자 그룹의 각 소비자 인스턴스에 대해 결정됩니다. |
| 재산 | 기본값 | 묘사 |
| metadata.broker.list | | 부트스트래핑을 해. 프로듀서는 메타데이터(주제, 파티션, 복제본)를 얻는 데만 사용됩니다. 실제 데이터를 보내는 소켓 연결은 반환된 메타데이터 데이터를 기반으로 설정됩니다. 포맷은 다음과 같습니다:
호스트1: 포트1, 호스트2: 포트2
이 목록은 중개인의 하위 목록일 수도 있고, 중개인을 가리키는 VIP일 수도 있습니다 |
| request.required.acks | 0 | 이 구성은 프로듀서 요청이 완료된 것으로 간주될 때를 나타내는 확인 값입니다. 특히, 얼마나 많은 다른 중개인들이 로그에 데이터를 제출하고 이 정보를 리더에게 확인했는지에 대한 질문입니다. 일반적인 값은 다음과 같습니다:
0: 생산자가 브로커의 확인을 기다리지 않는다는 것을 나타냅니다(0.7과 동일). 이 방법은 지연 시간이 가장 적지만 동시에 가장 큰 위험이 있습니다(서버가 다운되면 데이터가 손실되기 때문입니다).
1: 리더 복제본이 데이터 확인을 받았음을 나타냅니다. 이 옵션은 지연 시간이 낮고 서버가 수신 여부를 확인합니다.
-1: 프로듀서는 모든 동기화된 복제본이 데이터를 받았다는 확인을 받습니다. 지연 시간이 가장 크지만, 이 방법은 메시지 손실 위험을 완전히 없애지는 못합니다. 동기화된 복제본 수가 1개일 수 있기 때문입니다. 일부 복제본이 데이터를 받도록 보장하고 싶다면, 주제 수준 설정에서 min.insync.replicas 옵션을 설정해야 합니다. 더 깊이 있는 논의를 원하시면 설계 문서를 읽어보세요. |
| request.timeout.ms | 10000 | 브로커는 request.required.acks 요구사항을 최대한 구현하려고 노력하며, 그렇지 않으면 클라이언트에 오류가 전송됩니다 |
| 프로듀서.타입 | 싱크 | 이 옵션은 메시지가 백그라운드 스레드에서 비동기로 전송되는지 여부를 고정합니다. 정확한 값:
(1) 비동기: 비동기 전송
(2) 동기화: 동기화된 송신
프로듀서를 비동기식으로 설정하면 요청을 배치로 처리할 수 있는데(이는 더 높은 처리량에 유리합니다), 하지만 이로 인해 클라이언트 머신이 전송되지 않은 데이터를 잃을 가능성도 생깁니다 |
| serializer.class | kafka.serializer.DefaultEncoder | 메시지의 직렬화 카테고리입니다. 기본 인코더는 1바이트[]를 입력하고 동일한 바이트[]를 반환합니다. |
| key.serializer.class | | 키워드용 직렬화 클래스. 만약 이 정보가 제공되지 않으면, 기본적으로 메시지와 일치하게 됩니다 |
| partitioner.class | kafka.producer.DefaultPartitioner | 파티셔너 클래스는 메시지를 하위 주제 간 나누기 위해 사용됩니다. 기본 파티셔너는 키의 해시 테이블을 기반으로 합니다 |
| compression.codec | 없음 | 이 매개변수는 데이터 압축을 위한 코덱을 설정할 수 있으며, "없음", "gzip", "snappy" 등 선택할 수 있습니다. |
| compressed.topics | 영 | 이 매개변수는 특정 주제가 압축되었는지 여부를 결정하는 데 사용할 수 있습니다. 압축된 코덱이 NoCompressCodec이 아닌 다른 코덱이라면, 이 코덱들은 지정된 주제 데이터에 적용됩니다. 압축된 주제 목록이 비어 있다면, 특정 압축 코덱을 모든 주제에 적용하세요. 압축된 코덱이 NoCompressionCodec이라면, 모든 주제에 대해 압축이 적용되지 않습니다. |
| message.send.max.retries | 3 | 이 매개변수는 프로듀서가 실패한 전송 요청을 자동으로 재시도하게 만듭니다. 이 매개변수는 재시도 횟수를 고정합니다. 참고: 0이 아닌 값을 설정하면 특정 네트워크 오류가 반복됩니다: 전송을 유발하고 확인 응답 손실을 유발합니다 |
| retry.backoff.ms | 100 | 재시도 전에 프로듀서는 관련 주제의 메타데이터를 업데이트하여 새로운 리더가 할당되었는지 확인합니다. 리더 선택에 시간이 조금 걸리기 때문에, 이 옵션은 제작자가 메타데이터를 업데이트하기 전에 얼마나 기다려야 하는지 명시합니다. |
| topic.metadata.refresh.interval.ms | 600*1000 | 프로듀서는 일반적으로 일부 실패 시나리오(파티션 누락, 리더 사용 불가 등)에서 주제의 메타데이터를 업데이트합니다. 그는 규칙적인 주기를 겪게 됩니다. 음수로 설정하면 메타데이터가 실패할 때만 업데이트됩니다. 0으로 설정하면 각 메시지 전송 후 메타데이터가 업데이트됩니다(이 옵션은 권장되지 않으며, 시스템이 너무 많은 데이터를 소비합니다). 중요: 업데이트는 메시지가 전송된 후에만 이루어지므로, 제작자가 메시지를 보내지 않으면 메타데이터는 업데이트되지 않습니다. |
| queue.buffering.max.ms | 5000 | 비동기 모드가 적용될 때 사용자가 데이터를 캐시하는 최대 시간 간격입니다. 예를 들어, 메시지가 100으로 설정되어 있으면 100ms 이내에 일괄 처리됩니다. 이렇게 하면 처리량은 향상되지만 캐싱으로 인한 지연 시간이 증가합니다. |
| queue.buffering.max.메시지 | 10000 | 비동기 모드를 사용할 때, 제작자 이전에 큐에 캐시할 수 있는 최대 미전송 메시지 수를 차단하거나 데이터가 손실되어야 합니다 |
| batch.num.messages | 200 | 비동기 모드를 사용할 때는 최대 메시지 수를 일괄 처리할 수 있습니다. 또는 온라인에 도달한 메시지 수나 queue.buffer.max.ms 도착한 상태에서 프로듀서가 처리합니다 |
| send.buffer.bytes | 100*1024 | 소켓 쓰기 캐시 크기 |
| client.id | “” | 이 클라이언트 ID는 각 요청에 포함된 사용자 전용 문자열로, 통화를 추적하기 위해 논리적으로 애플리케이션이 요청을 했다는 것을 확인할 수 있어야 합니다. |
| 이름 | 유형 | 기본값 | 중요성 | 묘사 |
| boostrap.servers | 목록 | | 하이 | 호스트/포트 그룹을 통해 Kafka 클러스터에 연결을 설정하는 것. 데이터는 부트스트래핑 대상이 된 서버와 관계없이 모든 서버에 균등하게 로드됩니다. 이 목록은 초기화된 호스트에만 영향을 주며(모든 서버를 발견하는 데 사용됩니다). 이 목록 형식은 다음과 같습니다:
host1:port1,host2:port2,...
이 서버들은 클러스터의 모든 멤버십을 발견하기 위해 연결을 초기화하는 데만 사용되기 때문에(멤버십은 동적으로 변할 수 있음), 이 리스트에 모든 서버를 포함할 필요는 없습니다(여러 서버를 원할 수도 있지만, 이 경우 한 서버가 다운될 수 있습니다). 이 목록에 서버가 없으면 목록이 제공될 때까지 전송 데이터가 실패합니다. |
| 알자 | 스트링 | 1 | 하이 | 생산자는 데이터를 받은 후 서버로부터 수신 확인 신호가 필요하며, 이 구성은 수주자가 필요한 확인 신호 수를 나타냅니다. 이 구성은 실제로 데이터 백업의 가용성을 나타냅니다. 다음 설정들이 일반적인 옵션입니다:
(1) acks=0: 0으로 설정하면 제작자가 수신한 정보에 대한 확인을 기다릴 필요가 없음을 의미합니다. 복제본은 즉시 소켓 버퍼에 추가되어 전송된 것으로 간주됩니다. 이 경우 서버가 데이터를 성공적으로 수신했다는 보장은 없으며, 구성 재시도는 실패했는지 모르기 때문에 작동하지 않고, 피드백 오프셋은 항상 -1로 설정됩니다.
(2) acks=1: 이는 최소한 리더가 데이터를 로컬 로그에 성공적으로 쓰기를 기다리지만, 모든 팔로워가 성공적으로 쓰기를 기다리지 않아야 한다는 의미입니다. 이 경우 팔로워가 데이터를 성공적으로 백업하지 못하고 리더가 다시 전화를 끊으면 메시지가 사라집니다.
(3) acks=all: 이는 리더가 모든 백업이 로그를 성공적으로 작성할 때까지 기다려야 하며, 이 전략은 한 개의 백업이 살아남는 한 데이터가 손실되지 않도록 보장합니다. 이것이 가장 강력한 보증입니다.
(4) acks=2와 같은 다른 설정도 가능하며, 이는 정해진 수의 ack이 필요하지만, 이 전략은 일반적으로 거의 사용되지 않습니다. |
| buffer.memory | 길게 | 33554432 | 하이 | 프로듀서는 데이터의 메모리 크기를 캐시하는 데 사용할 수 있습니다. 데이터가 브로커로 전송되는 속도보다 빠르게 생성되면, 생산자는 "block.on.buffer.full"으로 표시하는 예외를 차단하거나 송제합니다.
이 설정은 생산자가 사용할 수 있는 총 메모리와 관련이 있지만, 제작자가 사용하는 모든 메모리가 캐싱에 사용되는 것은 아니므로 엄격한 제한은 아닙니다. 압축이 도입될 경우 일부 추가 메모리는 압축용으로 사용되고, 일부는 유지보수 요청에 사용됩니다. |
| compression.type | 스트링 | 없음 | 하이 | 프로듀서는 데이터를 압축하는 데 사용되는 압축 방식입니다. 기본값은 압축되지 않습니다. 올바른 옵션 값은 '없음', 'gzip', 'snappy'입니다.
압축은 배치 처리에 가장 적합하며, 더 많은 메시지가 배치로 처리될수록 압축 성능이 향상됩니다. |
| 재도전 | 지능 | 0 | 하이 | 0보다 큰 값을 설정하면 해당 데이터가 실패하면 클라이언트가 데이터를 다시 전송합니다. 이 재시도는 클라이언트가 전송 오류를 받았을 때와 다르지 않다는 점에 유의하세요. 재시도가 데이터 순서를 변경할 수 있는 경우, 두 메시지 레코드가 동일한 파티션으로 전송되면 첫 번째 메시지가 실패하고 두 번째 메시지가 첫 번째 메시지보다 먼저 나타날 경우, 재시도가 데이터 순서를 변경할 수 있습니다. |
| batch.size | 지능 | 16384 | 보통 | 프로듀서는 요청 수를 줄이기 위해 메시지 레코드를 배치하려고 시도합니다. 이렇게 하면 클라이언트와 서버 간 성능이 향상됩니다. 이 구성은 배치 처리 메시지의 기본 바이트 수를 제어합니다.
이 바이트 수를 초과하는 메시지 바이트는 처리하지 않습니다.
브로커에게 보내지는 요청은 여러 배치로 구성되며, 각 배치마다 하나의 요청이 포함됩니다.
더 작은 배치 값은 덜 사용되며 처리량을 줄일 수 있습니다(0은 배치 처리만 사용합니다). 배치 값이 클수록 메모리 공간이 더 많이 낭비되기 때문에 특정 배치 값에 맞게 메모리를 할당해야 합니다. |
| client.id | 스트링 | | 보통 | 이 문자열은 요청이 이루어질 때 서버에 전송됩니다. 목적은 요청의 출처를 추적하여 IP/포트 허용 목록에 없는 일부 애플리케이션이 정보를 전송할 수 있도록 하는 것입니다. 이 앱은 녹음과 추적 외에는 기능적인 목적이 없기 때문에 어떤 줄도 설정할 수 있습니다 |
| linger.ms | 길게 | 0 | 보통 | 프로듀서 그룹은 요청과 전송 사이에 도착한 모든 메시지를 집계하여 별도의 요청 배치를 기록합니다. 일반적으로 이는 레코드가 전송 속도보다 빠르게 생성될 때만 발생합니다. 하지만 특정 조건에서는 클라이언트가 요청 수를 줄이거나 적당한 부하로 줄이길 원할 것입니다. 이 설정은 작은 지연을 추가하여 이루어집니다. 즉, 레코드를 즉시 전송하는 대신 제작자가 주어진 지연 시간을 기다려 다른 메시지 레코드를 전송할 수 있도록 하며, 이 레코드들은 배치로 전송될 수 있습니다. 이는 TCP Nagle과 유사한 알고리즘으로 볼 수 있습니다. 이 설정은 배치 처리에 더 높은 지연 시간을 설정합니다: 파티션의 batch.size를 얻으면 이 설정과 상관없이 바로 전송되지만, 이 설정보다 훨씬 적은 바이트 수를 가진 메시지를 받으면 더 많은 메시지를 받기 위해 특정 시간을 "기다리기"해야 합니다. 이 설정은 기본값이 0, 즉 지연이 없습니다. 예를 들어 linger.ms=5를 설정하면 요청 수가 줄어들지만, 동시에 지연 시간이 5ms 증가합니다. |
| Max.request.size | 지능 | 1028576 | 보통 | 요청된 최대 바이트 수. 이것은 또한 최대 기록된 크기에 대한 효과적인 보장입니다. 참고: 서버는 메시지 레코드 크기를 자체 오버라이드하여 이 설정과는 다릅니다. 이 설정은 생산자가 한 번에 대량으로 보낼 수 있는 요청 수를 제한하여 많은 요청을 방지합니다. |
| receive.buffer.bytes | 지능 | 32768 | 보통 | TCP 수신 캐시 크기는 데이터를 읽을 때 사용됩니다 |
| send.buffer.bytes | 지능 | 131072 | 보통 | TCP 전송 캐시 크기는 데이터를 전송할 때 사용됩니다 |
| timeout.ms | 지능 | 30000 | 보통 | 이 구성 옵션은 팔로워로부터 확인을 기다리는 최대 시간을 제어합니다. 이 시간 내에 확인된 요청 수가 충족되지 않으면 오류가 반환됩니다. 이 타임아웃 제한은 서버 측에서 측정되며, 요청 포함 네트워크 지연 시간이 없습니다 |
| block.on.buffer.full | 불리언 | true | 낮게 | 메모리 캐시가 다 떨어지면 새 메시지 기록 수신을 중단하거나 오류를 투기해야 합니다. 기본값은 true로 설정되어 있지만, 일부 차단이 예상치 못할 수 있으므로 바로 오류를 던지는 것이 좋습니다. 이는 false로 설정했을 때 발생하며, 레코드가 전송되고 캐시가 가득 찼을 경우 BufferExhaustedException이라는 예외 오류를 생성합니다 |
| metadata.fetch.timeout.ms | 길게 | 60000 | 낮게 | 이는 우리가 얻은 일부 요소의 첫 번째 데이터를 의미합니다. 요소로는 주제, 호스트, 파티션이 포함됩니다. 이 구성은 fetch에 따라 요소가 성공적으로 완료되기까지 필요한 시간을 의미하며, 그렇지 않으면 클라이언트에 예외가 전송됩니다. |
| metadata.max.age.ms | 길게 | 300000 | 낮게 | 마이크로초 단위의 시간은 메타데이터를 강제로 갱신하는 간격입니다. 비록 분할 지도부 교체가 없더라도 말이죠. |
| Metric.Reporters | 목록 | [] | 낮게 | 지표를 측정하는 데 사용되는 클래스 목록입니다. MetricReporter 인터페이스를 구현하면 새로운 지표가 생성될 때마다 클래스가 변경될 수 있습니다. JmxReporter는 항상 JMX 통계를 등록하는 방법을 포함할 것입니다 |
| metrics.num.samples | 지능 | 2 | 낮게 | 지표를 유지하는 데 사용되는 샘플 수 |
| metrics.sample.window.ms | 길게 | 30000 | 낮게 | 메트릭스 시스템은 보정 가능한 창 크기에 대해 구성 가능한 샘플 수를 유지합니다. 이 구성은 예를 들어 창 크기를 설정합니다. 30초 동안 두 개의 샘플을 유지할 수 있습니다. 창을 펼칠 때, 가장 오래된 창을 지우고 다시 작성합니다 |
| recoonect.backoff.ms | 길게 | 10 | 낮게 | 연결이 끊기면 다시 연결할 때 대기 시간이 생깁니다. 이로 인해 반복적인 클라이언트 재연결을 방지할 수 있습니다 |
| retry.backoff.ms | 길게 | 100 | 낮게 | 실패한 신제품 요청을 재시도하기 전 대기 시간. 전송-실패 같은 데드 루프에 빠지지 마세요.
|
게시됨 2021. 6. 24. 오전 11:47:12
|
|
|
집주인