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 TCP (Transmission Control Protocol) de entrada ocioso > 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 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 o aumento do valor delivery.timeout.ms, consulte a 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. Embora solicitações com valores de tempo limite mais baixos sejam aceitas, o comportamento do cliente não é garantido. 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 essas configurações muito baixas pode causar tempos limite do consumidor, o que causa reequilíbrios (que causam mais tempos limites, que causam mais reequilíbrio, e assim por diante). |
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 |
uncompressed, 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 essas configurações muito baixas pode causar tempos limite do consumidor, o que causa reequilíbrios (que causam mais tempos limites, que causam mais reequilíbrio, e assim por diante). |
max.poll.interval.ms |
300000 (padrão) | >session.timeout.ms | Usado para reequilibrar o tempo limite, por isso não deve ser definido muito 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 solicitações com valores de tempo limite mais baixos sejam aceitas, 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 reequilibrar o tempo limite, por isso não deve ser definido muito 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:
|
| 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.