Partilhar via

Configurações recomendadas para clientes Apache Kafka

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

Propriedades de configuração do cliente Java

Configurações de produtor e consumidor

Property Valores recomendados Intervalo permitido Notas
metadata.max.age.ms 180000 (aproximado) < 240000 Pode ser reduzido para captar alterações de metadados mais cedo.
connections.max.idle.ms 180000 < 240000 O Azure fecha o Protocolo de Controlo de Transmissão (TCP) de entrada em inatividade > por 240.000 ms, o que pode resultar em envio de ligações mortas (indicadas como lotes expirados devido ao time-out de envio).

Somente configurações do produtor

As configurações do produtor podem ser encontradas aqui.

Property Valores recomendados Intervalo permitido Notas
max.request.size 1000000 < 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 aumento delivery.timeout.ms de valor, veja documentação.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos internamente têm como padrão um mínimo de 20.000 ms. Os timeouts dos produtores são seguros com valores tão baixos quanto 10.000 ms e não serão um problema para os produtores.

Certifique-se de que o seu request.timeout.ms é pelo menos o valor recomendado de 60000 e o seu session.timeout.ms é pelo menos o valor recomendado de 30000. Ter estas definições demasiado baixas pode causar time-outs do consumidor, o que depois provoca reequilíbrios (o que depois causa mais time-outs, mais reequilíbrio, e assim sucessivamente).
metadata.max.idle.ms 180000 > 5000 Controla por quanto tempo o produtor armazena em cache metadados para um tópico que está ocioso. Se o tempo decorrido desde que um tópico foi produzido pela última vez exceder a duração ociosa dos 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 de permanência deve ser igual ao valor tolerável mais alto para aproveitar o processamento em lote.
delivery.timeout.ms Definir de acordo com a fórmula (request.timeout.ms + linger.ms) * . retries
compression.type none, gzip Atualmente, apenas a compactação gzip é suportada.

Somente configurações de consumidor

As configurações do consumidor podem ser encontradas aqui.

Property Valores recomendados Intervalo permitido Notas
heartbeat.interval.ms 3000 3000 é o valor padrão e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000, aumente se ver reequilíbrio frequente por causa de batimentos cardíacos perdidos.

Certifique-se de que o seu request.timeout.ms é pelo menos o valor recomendado de 60000 e o seu session.timeout.ms é pelo menos o valor recomendado de 30000. Ter estas definições demasiado baixas pode causar time-outs do consumidor, o que depois provoca reequilíbrios (o que depois causa mais time-outs, mais reequilíbrio, e assim sucessivamente).
max.poll.interval.ms 300000 (padrão) >session.timeout.ms Usado para time-out de reequilíbrio, por isso não deve estar demasiado baixo. Deve 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

Property Valores recomendados Intervalo permitido Notas
socket.keepalive.enable verdadeiro Necessário se se espera que a conexão fique ociosa. O Azure fecha o TCP de entrada ocioso > 240.000 ms.
metadata.max.age.ms ~ 180000 < 240000 Pode ser reduzido para captar alterações de metadados mais cedo.

Somente configurações do produtor

Property Valores recomendados Intervalo permitido Notas
retries > 0 O padrão é 2147483647.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos internamente têm como padrão um mínimo de 20.000 ms. librdkafka O valor padrão é 5000, o que pode ser problemático. Embora pedidos com valores de time-out mais baixos sejam aceites, o comportamento do cliente não é garantido.
partitioner consistent_random Consulte a documentação da librdkafka consistent_random é padrão e melhor. As chaves vazias e nulas são tratadas idealmente para a maioria dos casos.
compression.codec none, gzip Atualmente, apenas a compactação gzip é suportada.

Somente configurações de consumidor

Property Valores recomendados Intervalo permitido Notas
heartbeat.interval.ms 3000 3000 é o valor padrão e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000, aumente se ver reequilíbrio frequente por causa de batimentos cardíacos perdidos.
max.poll.interval.ms 300000 (padrão) >session.timeout.ms Usado para o reequilíbrio do timeout, por isso não deve estar demasiado baixo. Deve ser maior que session.timeout.ms.

Outras notas

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

Sintomas Problema Solução
Compensar falhas de confirmação devido ao reequilíbrio Seu consumidor está esperando muito tempo entre as chamadas para poll() e o serviço está expulsando o consumidor do grupo. Tem várias opções:
  • Aumentar o tempo de processamento das sondagens (max.poll.interval.ms)
  • Diminua o tamanho do lote de mensagens para acelerar o processamento
  • Melhore a paralelização do processamento para evitar o bloqueio de consumer.poll()
Aplicar alguma combinação dos três é provavelmente o mais sensato.
Exceções de rede com alta taxa de transferência de produção Se você estiver usando o cliente Java + padrão max.request.size, suas solicitações podem ser muito grandes. Consulte Configurações Java mencionadas anteriormente.

Próximos passos

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

  • Last updated on