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:
|
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.