Protocols & Binary Serialization

Calcular partição Kafkapelos bytes reais da chave

Confira uma chave e a quantidade total de partições usando Murmur2 compatível com Java.

Calcular partição Kafka

Chave serializada

Espaços e quebras de linha são preservados. Uma chave de zero bytes é válida; selecione null se a chave estiver ausente.

Resultado

Partição (a partir de 0)
9
Quantidade de bytes
5
Hash de 32 bits com sinal
2132663229
Hash de 32 bits sem sinal
2132663229
Hash sem o bit de sinal
2132663229

Etapas do cálculo

  1. Decodificar a chave em 5 bytes.
  2. Murmur2 com semente 0x9747b28c → 2132663229.
  3. 2132663229 & 0x7fffffff → 2132663229.
  4. 2132663229 % 12 → partição 9.

Bytes da chave em hexadecimal

68 65 6c 6c 6f

O cálculo fica nesta aba. Nenhuma chave é enviada ou salva, e não há conexão com um cluster Kafka.

Opções

Válido para roteamento por chave com Murmur2 compatível com Java. Partição explícita, chaves ignoradas, outro serializador ou particionador podem mudar o destino real.

Cálculo concluído.

Calcular partição Kafka é útil quando uma mensagem aparece em um destino inesperado. Antes de investigar o particionador, confira a serialização: uma chave que parece igual no log pode ter bytes diferentes. O painel permite acompanhar os valores que levam ao destino.

Uma chave de partição numérica pode ser serializada como texto ou como inteiro binário. A função de hash não enxerga o significado do valor, apenas os bytes. Para reproduzir um serializador que não usa strings UTF-8, informe sua saída em hex ou Base64.

Por que usar Calcular partição Kafka

Comparar a entrada que chega ao hash

Calcular partição Kafka coloca três formas de entrada na mesma base de comparação. Espaços finais, quebras de linha e caracteres de vários bytes ficam visíveis no hexadecimal. Se os bytes forem iguais, a forma escolhida para digitá-los não muda o hash nem o destino nas mesmas condições.

Três canais de entrada convergem nos mesmos blocos de bytes e em um resultado comum.

Separar chave vazia de chave ausente

Uma string UTF-8 vazia gera um array existente com zero bytes. null indica a ausência do array. O primeiro caso tem um hash determinístico; o segundo depende do estado de execução do produtor. O resultado não atribui uma partição fictícia à chave ausente.

Uma chave em bytes segue um caminho fixo; uma chave ausente aponta por linhas tracejadas para destinos possíveis.

Reproduzir as condições de envio

01

Começar depois da serialização

UTF-8 mantém espaços e quebras de linha. Hex permite espaços ASCII, mas exige pares completos sem 0x. Base64 padrão exige o preenchimento adequado. Trocar a codificação reinterpreta o conteúdo atual; não o converte automaticamente para outro formato.

02

Conferir o total atual do tópico

O padrão 12 é um exemplo, não uma recomendação de capacidade. As partições começam em zero, portanto os destinos vão de 0 a 11. Alterar o total pode mudar o resto e a partição de futuras mensagens mesmo quando o hash permanece igual.

03

Validar com uma referência fixa

Carregue abc ou foobar nos vetores e compare o hash com sinal ao valor esperado. O modo automático aguarda 350 ms após a última edição. Desative-o para calcular com Ctrl/Cmd + Enter. Resultados desatualizados ficam bloqueados para exportação.

Acompanhar cada valor do roteamento

Murmur2 com a semente do Kafka

A variante usa 0x9747b28c, blocos little endian de quatro bytes e multiplicação de 32 bits. Os valores com e sem sinal representam os mesmos bits. Antes do módulo, o bit de sinal é removido com 0x7fffffff. Usar valor absoluto é outra operação e pode mudar a partição.

Decodificação sem correções silenciosas

Hex e Base64 padrão representam bytes arbitrários, incluindo 00 e ff. Quantidade ímpar de dígitos, preenchimento incorreto e bits finais não canônicos são rejeitados. O texto mantém maiúsculas, espaços e forma Unicode, de modo que a ferramenta não altera a entrada para fazê-la passar.

Vetores oficiais e relatório integral

abc, foobar e 21 vêm com valores esperados do Apache Kafka. A prévia mostra 100 bytes e cresce de 100 em 100. O JSON inclui todos os bytes, algoritmo, codificação, tipo de chave, total de partições e valores intermediários para comparação com o produtor.

Condições e limites do resultado

Não representa o padrão de todo cliente
Somente Murmur2 compatível com Java está implementado. O padrão do librdkafka pode ser baseado em CRC32. Um particionador próprio, partitioner.ignore.keys ou uma partição explícita podem ignorar esta fórmula. CRC32, Murmur3, FNV e sementes personalizadas não são opções disponíveis.
null não recebe um destino fixo
Selecionar null preserva o texto, mas o exclui do cálculo. Estratégias sticky ou aleatórias exigem estado de execução. No modo de bytes, escrever literalmente null continua sendo uma chave UTF-8 de quatro bytes. Confira também a política do cliente para arrays vazios.
O serializador precisa fornecer os bytes
A página não executa Avro, Protobuf, serializadores de inteiros ou consultas ao schema registry. Não remove espaços nem normaliza Unicode. Substitutos isolados são recusados para evitar a troca automática de caracteres pelo navegador. Forneça os bytes reais se o produtor se comportar de outra forma.
Limites para manter a resposta local
A entrada aceita 196608 unidades de código UTF-16 e 65536 bytes decodificados. A quantidade de partições precisa ser um inteiro decimal de 1 a 2147483647. Não há entrada por arquivo, URL ou lote. Esses limites não equivalem ao tamanho máximo de mensagem de um broker.
Sem estimar capacidade ou mover dados
Uma única chave não indica o número ideal de partições, broker, consumidor ou offset. Aumentar o total pode alterar futuras gravações sem mover mensagens já existentes. Não há simulação de distribuição ou migração, nem garantia de ordem entre partições diferentes.

Calcular partição Kafka: dúvidas frequentes

Como descobrir a partição de destino de uma chave?

Para a política selecionada, aplique Murmur2 aos bytes serializados, remova o bit de sinal e obtenha o resto em relação ao total de partições. abc produz o hash com sinal 479470107 e vai para a partição 3 quando há 12. Confirme o total nos metadados do tópico.

Chaves diferentes podem cair na mesma partição?

Sim. Muitas chaves precisam compartilhar um conjunto finito de destinos. Isso não exige colisão do hash completo: valores positivos diferentes podem ter o mesmo resto. Estar na mesma partição não prova que duas chaves são iguais nem que seus hashes de 32 bits coincidem.

Por que a mesma chave chega a partições diferentes?

Compare os bytes serializados, o total e a configuração do particionador. Clientes diferentes podem usar algoritmos e serializadores diferentes. Partição explícita e a opção de ignorar chaves também interferem. O rebalanceamento dos consumidores muda a atribuição de leitura, não esta fórmula de hash.

É obrigatório informar uma chave ao enviar uma mensagem Kafka?

Não. A necessidade de uma chave depende dos requisitos de agrupamento e ordem da aplicação. É possível enviar sem chave, mas a fórmula Murmur2 baseada em chave não basta para determinar o destino. Uma string vazia é diferente de uma chave ausente.

Como a partição é escolhida quando não há chave?

Depende do cliente, da versão, da configuração e do estado em execução, inclusive dos lotes. Produtores Java podem usar comportamento sticky; outros clientes seguem políticas próprias. Por isso, a página não atribui uma partição fixa a null nem presume sempre um antigo rodízio circular.

A semente do Murmur2 muda a cada execução?

A variante do Kafka usa a semente fixa 0x9747b28c. Com os mesmos bytes, o hash é reproduzível entre execuções. O destino final ainda pode mudar: outra quantidade de partições altera o módulo, e outro particionador pode escolher uma regra diferente.

Encontrou um erro no cálculo ou na validação?

Conferir outra chave do produtor

Calcular partição Kafka permite comparar a saída real do serializador e os valores intermediários com a implementação de roteamento usada no produtor.