01
직렬화 형식을 먼저 정하기
UTF-8은 공백과 줄바꿈을 보존합니다. 16진수에는 ASCII 공백을 넣을 수 있지만 0x를 붙이지 않고 두 자리씩 입력해야 합니다. 표준 Base64의 필요한 패딩도 생략하지 마세요. 인코딩 변경은 현재 텍스트를 다시 해석하며 내용을 변환하지 않습니다.
Protocols & Binary Serialization
Kafka 파티션 계산실제 키 바이트로 확인
키 하나와 파티션 수를 지정하여 Java 호환 Murmur2 계산을 확인하세요.
Kafka 파티션 계산
직렬화된 키 입력
공백과 줄바꿈을 그대로 사용합니다. 빈 바이트 키는 유효합니다. 키가 없으면 null을 선택하세요.
파티션 결과
- 파티션 번호 (0부터 시작)
- 9
- 바이트 수
- 5
- 부호 있는 32비트 해시
- 2132663229
- 부호 없는 32비트 해시
- 2132663229
- 부호 비트를 지운 값
- 2132663229
계산 과정
- 키를 5바이트로 디코딩합니다.
- 시드 0x9747b28c로 Murmur2 계산 → 2132663229.
- 2132663229 & 0x7fffffff → 2132663229.
- 2132663229 % 12 → 파티션 9.
키 바이트 (16진수)
68 65 6c 6c 6f
현재 브라우저에서 계산합니다. 키를 전송하거나 저장하지 않으며 Kafka 클러스터에 연결하지 않습니다.
옵션
Java 호환 키 기반 Murmur2 라우팅에 적용됩니다. 명시적 파티션, 키 무시 설정, 다른 직렬화기나 파티셔너는 실제 목적지를 바꿀 수 있습니다.
계산을 완료했습니다.
동일한 고객 키가 예상과 다른 파티션에 도착하면 먼저 직렬화 결과를 살펴보세요. Kafka 파티션 계산 과정에서 바이트와 해시값을 함께 보면 키가 달라진 것인지, 라우팅 조건이 달라진 것인지 구분할 수 있습니다.
화면에 표시된 숫자와 정수 직렬화기가 만든 바이트는 같지 않습니다. 문자열을 복사할 때 붙은 줄바꿈도 해시에 참여합니다. 바이너리 키를 재현할 때는 직렬화 결과를 16진수나 Base64로 입력하는 편이 정확합니다.
Kafka 파티션 계산을 활용하는 이유
문자 모양보다 바이트를 먼저 비교
Kafka 파티션 계산 도구는 세 가지 입력을 같은 바이트 기준으로 보여 줍니다. 공백, 다중 바이트 문자, 0바이트 값을 16진수로 확인할 수 있습니다. 입력 형식이 달라도 바이트가 같으면 해시와 같은 조건의 목적지는 같아야 합니다.
빈 값과 키 없음의 의미를 분리
빈 문자열을 UTF-8로 변환하면 길이가 0인 바이트 배열이 됩니다. null은 배열 자체가 없는 상태입니다. 빈 배열은 해시를 계산할 수 있지만, 키 없음은 프로듀서의 실행 상태가 필요하므로 임의의 고정 번호를 제시하지 않습니다.
프로듀서 조건을 맞추는 방법
02
현재 전체 파티션 수 사용하기
기본값 12는 예제일 뿐 권장 개수가 아닙니다. 번호는 0부터 시작하므로 12개일 때 범위는 0부터 11입니다. 개수를 늘리면 해시는 그대로여도 나머지가 달라져 이후 레코드의 목적지가 바뀔 수 있습니다.
03
중간값을 참조 벡터로 검증하기
테스트 벡터에서 abc나 foobar를 불러와 예상 부호 있는 해시와 비교하세요. 자동 계산은 마지막 변경 후 350ms를 기다립니다. 자동을 끄면 Ctrl/Cmd + Enter로 실행할 수 있으며 오래된 결과는 내보낼 수 없습니다.
재현 가능한 라우팅의 구성 요소
고정 시드의 Kafka Murmur2
시드는 0x9747b28c이며 리틀 엔디언 4바이트 블록과 32비트 곱셈을 사용합니다. 부호 있는 해시와 없는 해시는 동일한 비트의 두 표현입니다. 라우팅은 0x7fffffff로 부호 비트를 지운 뒤 나머지를 구하며, 절댓값을 취하는 방식과 다릅니다.
엄격한 바이트 디코딩
16진수와 표준 Base64로 00과 ff를 포함한 임의의 바이트를 전달할 수 있습니다. 홀수 자릿수, 잘못된 패딩, 마지막 비트가 비정상인 Base64는 오류로 처리합니다. 텍스트의 대소문자나 Unicode 정규화 형식을 임의로 바꾸지 않습니다.
공식 벡터와 전체 JSON
abc, foobar, 21의 Apache Kafka 참조 해시를 함께 제공합니다. 미리 보기는 100바이트씩 확장되며 보고서에는 전체 바이트를 담습니다. 알고리즘, 인코딩, 키 유형, 파티션 수와 중간 계산값을 프로듀서 로그와 비교할 수 있습니다.
결과 해석 시 지켜야 할 조건
- 모든 클라이언트의 기본값은 아님
- 지원 알고리즘은 Java 호환 Murmur2 하나입니다. librdkafka의 기본값은 다를 수 있고 사용자 정의 파티셔너나 partitioner.ignore.keys도 이 공식을 우회할 수 있습니다. 명시적 파티션 지정도 확인하세요. CRC32, Murmur3, FNV와 사용자 시드는 제공하지 않습니다.
- null의 목적지를 예측하지 않음
- null을 선택하면 입력 문자를 보존하되 계산에서 제외합니다. sticky나 random 전략은 실행 중인 상태에 의존합니다. 바이트 모드에서 null이라는 글자를 입력하면 일반 UTF-8 네 바이트로 처리되므로 키 없음과 혼동하지 마세요.
- 업무용 직렬화기는 실행하지 않음
- Avro, Protobuf, 정수 직렬화나 schema registry 조회는 하지 않습니다. 공백 제거와 Unicode 정규화도 하지 않으며, 짝이 없는 서로게이트는 자동 대체하지 않고 거부합니다. 실제 프로듀서의 직렬화 결과를 제공해야 동일한 입력이 됩니다.
- 상한은 브라우저 보호 기준
- 입력은 UTF-16 코드 단위 196608개, 디코딩 후 65536바이트까지 허용합니다. 파티션 수는 1부터 2147483647까지 십진 정수입니다. 파일, URL, 일괄 입력은 없으며 이 수치가 Kafka 브로커 메시지 상한을 의미하지는 않습니다.
- 용량과 과거 데이터 이동은 범위 밖
- 권장 파티션 수나 브로커, 컨슈머, 오프셋을 산출하지 않습니다. 개수를 바꾸면 미래 레코드의 위치가 달라질 수 있지만 기존 메시지는 이동하지 않습니다. 하나의 키로 전체 분포나 파티션 간 순서를 보장할 수 없습니다.
Kafka 파티션 계산 관련 질문
키가 어느 파티션으로 전송되는지 어떻게 확인하나요?
선택한 키 기반 라우팅이라면 직렬화한 바이트의 Murmur2를 구하고 부호 비트를 지운 뒤 전체 파티션 수로 나머지를 계산합니다. abc의 부호 있는 해시는 479470107이며 파티션 12개에서는 번호 3입니다. 실제 총수는 토픽 메타데이터로 확인하세요.
서로 다른 키가 같은 파티션에 들어갈 수 있나요?
가능합니다. 많은 키가 제한된 수의 파티션을 공유하므로 자연스러운 결과입니다. 전체 32비트 해시가 충돌하지 않아도 서로 다른 값의 나머지가 같을 수 있습니다. 목적지가 같다는 사실만으로 키가 같다고 판단할 수는 없습니다.
같은 키인데 다른 파티션으로 전송되는 이유는 무엇인가요?
직렬화된 바이트, 파티션 수, 클라이언트의 파티셔너 설정을 순서대로 비교하세요. 같은 문자열처럼 보여도 다른 바이트로 인코딩될 수 있습니다. 명시적 목적지와 키 무시 설정도 영향을 줍니다. 컨슈머 리밸런싱 자체는 이 해시 공식을 바꾸지 않습니다.
Kafka 메시지를 보낼 때 키가 반드시 필요한가요?
필수는 아닙니다. 애플리케이션의 그룹화와 순서 요구에 따라 키를 사용할지 정할 수 있습니다. 키 없이도 전송할 수 있지만 키 기반 Murmur2 공식만으로 목적지를 알 수는 없습니다. 빈 문자열은 키 없음과 별개의 경우입니다.
키가 없으면 파티션은 어떻게 선택되나요?
클라이언트 버전, 설정, 배치 같은 실행 상태에 따라 달라집니다. Java 프로듀서는 sticky 동작을 사용할 수 있고 다른 클라이언트에는 다른 정책이 있습니다. 이 도구는 null에 고정 번호를 할당하거나 항상 라운드 로빈이라고 가정하지 않습니다.
Murmur2 시드는 실행할 때마다 달라지나요?
Kafka의 이 Murmur2 변형은 고정 시드 0x9747b28c를 사용합니다. 바이트가 같으면 실행할 때마다 해시를 재현할 수 있습니다. 다만 전체 파티션 수가 달라지면 나머지가 달라질 수 있고 다른 파티셔너는 다른 규칙을 사용합니다.
계산 또는 검증 오류를 발견했나요?