ApsaraMQ for Kafka:Best practices for consumers

Evite rebalanceamentos frequentes

Os rebalanceamentos pausam o consumo enquanto as partições são reatribuídas. Rebalanceamentos frequentes prejudicam o throughput e aumentam a latência de processamento. Eles ocorrem geralmente quando os heartbeats dos consumidores expiram.

Para evitar esse problema, ajuste os parâmetros relevantes ou aumente a taxa de consumo. Para obter etapas detalhadas de solução de problemas, consulte Por que ocorrem rebalanceamentos frequentes no meu cliente consumidor?

Contagem recomendada de partições

A contagem padrão de partições no console do ApsaraMQ for Kafka é 12, valor adequado para a maioria das cargas de trabalho. Ao dimensionar o sistema, siga estas diretrizes:

Um grupo assina vários tópicos

Um único grupo de consumidores pode assinar múltiplos tópicos. As mensagens de todos os tópicos assinados são distribuídas uniformemente entre os consumidores do grupo.

String topicStr = kafkaProperties.getProperty("topic");
String[] topics = topicStr.split(",");
for (String topic: topics) {
    subscribedTopics.add(topic.trim());
}
consumer.subscribe(subscribedTopics);

Vários grupos assinam um tópico

Diversos grupos de consumidores podem assinar o mesmo tópico de forma independente. Cada grupo recebe todas as mensagens e opera sem interferir nos demais.

Utilize este padrão quando diferentes aplicações precisarem processar o mesmo fluxo de dados independentemente — por exemplo, um grupo para análises em tempo real e outro para arquivamento de dados.

Mantenha um grupo por aplicação

Use um grupo de consumidores dedicado para cada aplicação. Caso uma única aplicação precise executar lógicas de consumo distintas, crie arquivos de configuração separados (por exemplo, kafka1.properties e kafka2.properties) com valores diferentes para group.id.

Alinhe as assinaturas dentro de um grupo

Todos os consumidores do mesmo grupo devem assinar o mesmo conjunto de tópicos. Assinaturas divergentes dificultam a solução de problemas e podem resultar em comportamentos inesperados de rebalanceamento.

Commit automático versus manual

O ApsaraMQ for Kafka disponibiliza dois parâmetros para confirmar os offsets do consumidor:

Com o commit automático ativado, o cliente verifica o tempo decorrido desde a última confirmação antes de cada poll. Se o tempo ultrapassar o valor definido em auto.commit.interval.ms, ele confirma o offset atual.

Confirme offsets manualmente

Para confirmar offsets manualmente, defina enable.auto.commit como false e chame a função commit(offsets) após processar cada lote.

Comportamento de redefinição de offset

Os offsets do consumidor são redefinidos em duas situações:

• Nenhum offset confirmado existe — por exemplo, quando um consumidor se conecta a um broker pela primeira vez.

• O offset confirmado é inválido — por exemplo, o offset máximo em uma partição é 10, mas o consumidor tenta ler a partir do offset 11.

Controle o comportamento de redefinição em clientes Java com auto.offset.reset:

Implemente consumo idempotente

Se sua aplicação for sensível a duplicatas — como transações financeiras ou processamento de pedidos — implemente a deduplicação no nível da aplicação:

1. Anexe uma chave única a cada mensagem durante a produção (por exemplo, um ID de transação).

2. Antes de processar uma mensagem consumida, verifique se a chave já foi processada anteriormente.

3. Ignore mensagens cujas chaves já tenham sido processadas.

Caso sua aplicação tolere duplicatas ocasionais (como agregação de métricas ou ingestão de logs), pule esta etapa.

Causas comuns de acúmulo

Aumente o throughput de consumo

Adicione mais consumidores. Inicie instâncias adicionais de consumidores (uma thread por consumidor) ou implante mais processos de consumo. O número de consumidores ativos não pode exceder a contagem de partições; os excedentes permanecerão ociosos.

Utilize um pool de threads para processamento. Desacople o polling do processamento para paralelizar o trabalho:

1. Defina um pool de threads com um número fixo de worker threads.

2. Faça o poll de um lote de mensagens.

3. Envie cada mensagem para o pool de threads para processamento concorrente.

4. Após a conclusão de todas as tarefas do lote, faça o poll do próximo lote.

Esse padrão mantém o loop de poll responsivo enquanto distribui o trabalho de processamento entre várias threads.