problema:
Estamos usando a versão do Kafka 0.10.2.1,
#kafka.bootstrap.servers=
kafka.bootstrap.servers=
kafka.group.id=
kafka.topic=
kafka.concurrency=5
kafka.key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
kafka.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
kafka.auto.offset.reset=latest
kafka.enable.auto.commit=true
kafka.auto.commit.interval=100
kafka.max.poll.records=20
kafka.session.timeout.ms=30000
kafka.security.protocol=SASL_PLAINTEXT
kafka.sasl.mechanism=PLAINMas haverá redistribuição frequente de consumidores kafka
Versão Kafka alta e baixa de batimentos cardíacos e mecanismo de tempo limite de sessão
Kafka 0.10.0.0 e Kafka 0.10.1.0
0.10.0.0 heartbeat e mecanismo de tempo limite:
heartbeats e polling são acoplados, apenas os parâmetros session.timeout.ms são fornecidos e não há nenhum parâmetro de polling de controle independente.
Supondo que leve 1 minuto para o consumidor processar a mensagem, você precisa definir session.timeout.ms maior que 1 minuto, caso contrário, o consumidor atingirá o tempo limite.
session.timeout.ms
O tempo limite usado para detectar falhas ao usar os recursos de gerenciamento de grupo do Kafka.
Quando a pulsação de um consumidor não é recebida dentro do tempo limite da sessão, o corretor marca o consumidor como com falha e reequilibra o grupo.
Como as pulsações são enviadas apenas quando poll () é invocado, um tempo limite de sessão maior permite mais tempo para o processamento de mensagens no loop de pesquisa do consumidor ao custo de um tempo mais longo para detectar falhas graves.
Consulte também max.poll.records para obter outra opção para controlar o tempo de processamento no loop de pesquisa.
Observe que o valor deve estar no intervalo permitido, conforme configurado na configuração do broker por group.min.session.timeout.ms e group.max.session.timeout.ms. 官方
提到 还 可以 通过 max.poll.records 参数 从另外 一个 维度 来 控制 影响 每次 poll 的 时间.
heartbeat.interval.ms
O tempo esperado entre as pulsações para o coordenador do consumidor ao usar os recursos de gerenciamento de grupo do Kafka.
Os batimentos cardíacos são usados para garantir que a sessão do consumidor permaneça ativa e para facilitar o rebalanceamento quando novos consumidores entram ou saem do grupo.
O valor deve ser definido abaixo de session.timeout.ms, mas normalmente não deve ser definido acima de 1/3 desse valor.
Pode ser ajustado ainda mais baixo para controlar o tempo esperado para rebalanceamentos normais.
0.10.1.0 mecanismo de pulsação: a
partir desta versão, pulsações e pesquisa são desacopladas, e cada encadeamento tem um mecanismo de manutenção de pulsação independente.
A partir desta versão, um parâmetro independente max.poll.interval.ms foi adicionado. Desta forma, o intervalo entre duas pesquisas pode ser configurado separadamente, o que permite configurar o intervalo de pesquisa para ser maior que o intervalo de heartbeat, ou seja, o tempo para os consumidores processarem as mensagens pode ser configurado de forma independente, permitindo o processamento da mensagem o tempo deve ser maior que o tempo de pulsação (tempo limite da sessão. timeout.ms).
session.timeout.ms é usado para encadeamentos de manutenção de pulsação e max.poll.interval.ms é usado para encadeamentos de processamento de consumo. Existem dois tópicos separados nesta versão.
Assumindo session.timeout.ms = 30000, que é 30 segundos, o encadeamento de pulsação do consumidor deve enviar uma pulsação ao servidor antes desse tempo limite.
Por outro lado, se o processamento de uma única mensagem levar 1 minuto, max.poll.interval.ms pode ser configurado para mais de 1 minuto para fornecer mais tempo para o encadeamento de processamento do consumidor processar a mensagem.
Caso contrário, se max.poll.interval.ms <1 minuto, fará com que uma única mensagem seja processada e espere pela próxima votação, porque as duas pesquisas excedem max.poll.interval.ms e causam a falha da votação (mesmo se a sessão não expirou), a pesquisa ainda falhará).
Se o encadeamento de processamento (pol) travar, o servidor pode detectá-lo por meio de max.poll.interval.ms.
Se todo o consumidor (Consumidor) travar, ele só poderá ser detectado por meio de session.timeout.ms.
0.10.1.0 的 重大 修改 修改:
O novo Java Consumer agora suporta pulsação de um thread em segundo plano.
Há uma nova configuração max.poll.interval.ms que controla o tempo máximo entre as chamadas de pesquisa antes que o consumidor saia proativamente do grupo (5 minutos por padrão).
O valor da configuração request.timeout.ms deve ser sempre maior que max.poll.interval.ms porque este é o tempo máximo que uma solicitação JoinGroup pode bloquear no servidor enquanto o consumidor está rebalanceando, portanto, alteramos seu valor padrão para pouco mais de 5 minutos.
Finalmente, o valor padrão de session.timeout.ms foi ajustado para 10 segundos e o valor padrão de max.poll.records foi alterado para 500.
0.10.1.0 版本 的 官方 说明 （http://kafka.apache.org/0101/documentation.html）
max.poll.interval.ms
O atraso máximo entre as invocações de poll () ao usar o gerenciamento de grupo de consumidores. Isso coloca um limite superior na quantidade de tempo que o consumidor pode ficar inativo antes de buscar mais registros. Se poll () não for chamado antes da expiração desse tempo limite, o consumidor será considerado com falha e o grupo será rebalanceado para reatribuir as partições a outro membro.
session.timeout.ms
O tempo limite usado para detectar falhas do consumidor ao usar o recurso de gerenciamento de grupo do Kafka. O consumidor envia batimentos cardíacos periódicos para indicar sua atividade ao corretor. Se nenhuma pulsação for recebida pelo broker antes da expiração do tempo limite da sessão, o broker removerá esse consumidor do grupo e iniciará um rebalanceamento. Observe que o valor deve estar no intervalo permitido, conforme configurado na configuração do broker por group.min.session.timeout.ms e group.max.session.timeout.ms.
request.timeout.ms
A configuração controla a quantidade máxima de tempo que o cliente aguardará pela resposta de uma solicitação.
Se a resposta não for recebida antes que o tempo limite expire, o cliente reenviará a solicitação, se necessário, ou falhará na solicitação se as tentativas se esgotarem.
Observe também:
O parâmetro padrão (max.poll.interval.ms) da versão 0.10.2.1 é ajustado para Integer.MAX_VALUE
http://kafka.apache.org/0102/documentation.html
Mudanças notáveis no 0.10.2.1
Os valores padrão para duas configurações da classe StreamsConfig foram alterados para melhorar a resiliência dos aplicativos Kafka Streams.
O valor padrão de novas tentativas do produtor Kafka Streams interno foi alterado de 0 para 10.
O valor padrão max.poll.interval.ms do consumidor Kafka Streams interno foi alterado de 300000 para Integer.MAX_VALUE.