Compartilhar via


Configurações recomendadas para clientes Apache Kafka

Aqui estão as configurações recomendadas para usar Hubs de Eventos do Azure de aplicativos cliente Apache Kafka.

Java de configuração do cliente

Configurações de produtor e consumidor

Propriedade Valores recomendados Intervalo permitido Observações
metadata.max.age.ms 180000 (aproximado) < 240000 Pode ser rebaixado para buscar alterações de metadados mais cedo.
connections.max.idle.ms 180000 < 240000 O Azure fecha o TCP (Protocolo de Controle de Transmissão) de entrada ocioso > em 240.000 ms, o que pode resultar no envio de conexões inativas (mostradas como lotes expirados devido ao tempo limite de envio).

Somente configurações de produtor

Configurações de produtor podem ser encontradas aqui.

Propriedade Valores recomendados Intervalo permitido Observações
max.request.size 1.000.000 < 1046528 O serviço fecha conexões se solicitações maiores que 1.046.528 bytes forem enviadas. Esse valor deve ser alterado e causa problemas em cenários de produção de alta taxa de transferência.
retries > 0 Pode exigir o aumento do valor delivery.timeout.ms, consulte a documentação.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos usam internamente como padrão um mínimo de 20.000 ms. Embora as solicitações com valores de tempo-de-tempo mais baixos sejam aceitas, o comportamento do cliente não é garantido.

Verifique se o request.timeout.ms tem no mínimo o valor recomendado de 60000 e o session.timeout.ms tem no mínimo o valor recomendado de 30000. Ter essas configurações com valores muito baixos pode fazer com que os consumidores atinjam o tempo limite, o que causa redistribuições (que fazem com que mais tempos limites sejam atingidos, o que causa mais redistribuições e assim por diante).

metadata.max.idle.ms 180000 > 5000 Controla por quanto tempo o produtor armazena em cache os metadados de um tópico ocioso. Se o tempo decorrido desde que um tópico foi produzido pela última vez exceder a duração ociosa de metadados, os metadados do tópico serão esquecidos e o próximo acesso a ele forçará uma solicitação de busca de metadados.
linger.ms > 0 Para cenários de alta taxa de transferência, o valor persistente deve ser igual ao valor mais alto tolerável para aproveitar o envio em lote.
delivery.timeout.ms Defina conforme a fórmula (request.timeout.ms + linger.ms) * retries.
compression.type uncompressed, gzip No momento, apenas a compactação gzip é suportada.

Apenas configurações do consumidor

Configurações de consumidor podem ser encontradas aqui.

Propriedade Valores recomendados Intervalo permitido Observações
heartbeat.interval.ms 3000 3000 é o valor padrão e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000 e aumente se houver reequilíbrio frequente devido a pulsações perdidas.

Verifique se o request.timeout.ms tem no mínimo o valor recomendado de 60000 e o session.timeout.ms tem no mínimo o valor recomendado de 30000. Ter essas configurações com valores muito baixos pode fazer com que os consumidores atinjam o tempo limite, o que causa redistribuições (que fazem com que mais tempos limites sejam atingidos, o que causa mais redistribuições e assim por diante).

max.poll.interval.ms 300000 (padrão) >session.timeout.ms Usado para tempo limite de rebalanceamento, portanto, não deve ser definido muito baixo. Precisa ser maior que session.timeout.ms.

Propriedades de configuração librdkafka

O arquivo de configuração principal librdkafka (link) contém descrições estendidas para as propriedades descritas nas seções a seguir.

Configurações de produtor e consumidor

Propriedade Valores recomendados Intervalo permitido Observações
socket.keepalive.enable verdadeiro Necessário se for esperado que a conexão esteja ociosa. O Azure fecha a ociosidade TCP de entrada de > 240.000 ms.
metadata.max.age.ms ~180000 < 240000 Pode ser rebaixado para buscar alterações de metadados mais cedo.

Somente configurações de produtor

Propriedade Valores recomendados Intervalo permitido Observações
retries > 0 O padrão é 2147483647.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos usam internamente como padrão um mínimo de 20.000 ms. librdkafka o valor padrão é 5000, o que pode ser problemático. Embora as solicitações com valores de tempo-de-tempo mais baixos sejam aceitas, o comportamento do cliente não é garantido.
partitioner consistent_random Confira a documentação do librdkafka consistent_random é padrão e melhor. Chaves vazias e nulas são manipuladas idealmente para a maioria dos casos.
compression.codec none, gzip No momento, apenas a compactação gzip é suportada.

Apenas configurações do consumidor

Propriedade Valores recomendados Intervalo permitido Observações
heartbeat.interval.ms 3000 3000 é o valor padrão e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000 e aumente se houver reequilíbrio frequente devido a pulsações perdidas.
max.poll.interval.ms 300000 (padrão) >session.timeout.ms Usado para tempo limite de rebalanceamento, portanto, não deve ser definido muito baixo. Precisa ser maior que session.timeout.ms.

Outras observações

Confira a tabela a seguir de cenários de erro comuns relacionados à configuração.

Sintomas Problema Solução
Falhas de confirmação de deslocamento devido ao reequilíbrio Seu consumidor está esperando muito tempo entre chamadas para poll() e o serviço está expulsando o consumidor do grupo. Você tem várias opções:
  • Aumentar o tempo limite de processamento da investigação (max.poll.interval.ms)
  • Diminuir o tamanho do lote de mensagens para acelerar o processamento
  • Melhorar a paralelização de processamento para evitar o bloqueio de consumer.poll()
Aplicar alguma combinação das três opções é provavelmente melhor.
Exceções de rede com taxa de transferência de alta produtividade Se você estiver usando o cliente Java + max.request.size padrão, suas solicitações podem ser muito grandes. Consulte as configurações do Java mencionadas anteriormente.

Próximas etapas

Consulte Limites, cotas e restrições de assinatura e serviço do Azure para cotas e limites de todos os serviços do Azure.