Partilhar via

Configurações recomendadas para clientes Apache Kafka

  • Artigo

Eis as configurações recomendadas para utilizar Hubs de Eventos do Azure a partir de aplicações cliente do Apache Kafka.

Propriedades de configuração do cliente Java

Configurações de produtor e consumidor

Propriedade Valores recomendados Intervalo permitido Notas
metadata.max.age.ms 180000 (aproximado) < 240000 Pode ser reduzida para recolher as alterações de metadados mais cedo.
connections.max.idle.ms 180000 < 240000 O Azure fecha o TCP de entrada inativo > 240 000 ms, o que pode resultar no envio de ligações inativas (mostradas como lotes expirados devido ao tempo limite de envio).

Apenas configurações de produtor

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

Propriedade Valores Recomendados Intervalo Permitido Notas
max.request.size 1000000 < 1046528 O serviço fechará as ligações se forem enviados pedidos superiores a 1 046 528 bytes. Este valor tem de ser alterado e causará problemas em cenários de produção de alto débito.
retries > 0 Pode exigir o aumento do valor delivery.timeout.ms, veja a documentação.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos serão predefinidos internamente para um mínimo de 20 000 ms. Embora os pedidos com valores de tempo limite inferiores sejam aceites, o comportamento do cliente não é garantido..

Certifique-se de que o request.timeout.ms é, pelo menos, o valor recomendado de 60000 e que o session.timeout.ms é, pelo menos, o valor recomendado de 30000. Ter estas definições demasiado baixas pode causar tempos limite do consumidor, o que causa reequilíbrios (o que causa mais tempos limite, o que causa mais reequilíbrio, etc.).
metadata.max.idle.ms 180000 > 5000 Controla quanto tempo o produtor irá colocar metadados em cache para um tópico que está inativo. Se o tempo decorrido desde que um tópico foi produzido pela última vez exceder a duração inativa dos metadados, os metadados do tópico serão esquecidos e o acesso seguinte ao mesmo forçará um pedido de obtenção de metadados.
linger.ms > 0 Para cenários de débito elevado, o valor de perduração deve ser igual ao valor tolerável mais elevado para tirar partido da criação de batches.
delivery.timeout.ms Defina de acordo com a fórmula (request.timeout.ms + linger.ms) * . retries
compression.type none A compressão não é atualmente suportada..

Apenas configurações de consumidor

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

Propriedade Valores Recomendados Intervalo Permitido Notas
heartbeat.interval.ms 3.000 3000 é o valor predefinido e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000, aumente se vir um reequilíbrio frequente devido a heartbeats perdidos.

Certifique-se de que o request.timeout.ms é, pelo menos, o valor recomendado de 60 000 e que o session.timeout.ms é, pelo menos, o valor recomendado de 30000. Ter estas definições demasiado baixas pode causar tempos limite do consumidor, o que causa reequilíbrios (o que causa mais tempos limite, o que causa mais reequilíbrio, etc.).
max.poll.interval.ms 300000 (predefinição) >session.timeout.ms Utilizado para reequilibrar o tempo limite, pelo que não deve ser definido demasiado baixo. Tem de ser maior que session.timeout.ms.

propriedades de configuração librdkafka

O ficheiro de configuração principal librdkafka (ligação) contém descrições expandidas para as propriedades abaixo.

Configurações de produtor e consumidor

Propriedade Valores Recomendados Intervalo Permitido Notas
socket.keepalive.enable true Necessário se a ligação estiver inativa. O Azure fechará o TCP de entrada inativo > 240 000 ms.
metadata.max.age.ms ~ 180000 < 240000 Pode ser reduzida para recolher as alterações de metadados mais cedo.

Apenas configurações de produtor

Propriedade Valores Recomendados Intervalo Permitido Notas
retries 2 A predefinição é 2147483647.
request.timeout.ms 30000 .. 60000 > 20000 Os Hubs de Eventos serão predefinidos internamente para um mínimo de 20 000 ms. librdkafka O valor predefinido é 5000, o que pode ser problemático. Embora os pedidos com valores de tempo limite inferiores sejam aceites, o comportamento do cliente não é garantido.
partitioner consistent_random Veja a documentação do librdkafka consistent_random é predefinido e melhor. As chaves vazias e nulas são processadas idealmente para a maioria dos casos.
compression.codec none A compressão não é atualmente suportada.

Apenas configurações de consumidor

Propriedade Valores Recomendados Intervalo Permitido Notas
heartbeat.interval.ms 3.000 3000 é o valor predefinido e não deve ser alterado.
session.timeout.ms 30000 6000 .. 300000 Comece com 30000, aumente se vir um reequilíbrio frequente devido a heartbeats perdidos.
max.poll.interval.ms 300000 (predefinição) >session.timeout.ms Utilizado para reequilibrar o tempo limite, pelo que não deve ser definido demasiado baixo. Tem de ser maior que session.timeout.ms.

Mais notas

Verifique a seguinte tabela de cenários de erro comuns relacionados com a configuração.

Sintomas Problema Solução
Falhas de consolidação de compensação devido ao reequilíbrio O consumidor está a aguardar demasiado tempo entre as chamadas para o inquérito() e o serviço está a expulsar o consumidor do grupo. Tem várias opções:
  • Aumentar o tempo limite de processamento de inquéritos (max.poll.interval.ms)
  • Diminuir o tamanho do lote de mensagens para acelerar o processamento
  • Melhorar a paralelização do processamento para evitar bloquear consumer.poll()
Aplicar alguma combinação dos três é provavelmente mais sensato.
Exceções de rede com débito de produção elevado Está a utilizar o cliente Java + max.request.size predefinido? Os seus pedidos podem ser demasiado grandes. Veja Configurações de Java acima.

Passos seguintes

Veja Subscrição do Azure e limites de serviço, quotas e restrições para quotas e limites de todos os serviços do Azure.