A quantidade de partições só pode aumentar, nunca diminuir. Essa é uma restrição de design do Apache Kafka, e não algo específico do ApsaraMQ for Kafka.
Como funciona a atribuição de partições
O Kafka atribui cada mensagem a uma partição com base em hash(key) % number_of_partitions. Cada partição armazena um log de mensagens independente e ordenado. Remover uma partição causa dois problemas:
Perda de dados. Todas as mensagens armazenadas nessa partição são perdidas.
Redistribuição de chaves. O módulo muda e altera o mapeamento de hash para todas as chaves. Consumidores que dependem da ordenação por chave — por exemplo, ao processar todos os eventos de um único usuário em sequência — recebem mensagens fora de ordem ou as perdem completamente.
Alternativas recomendadas
Planeje a quantidade de partições antecipadamente. Estime com base no throughput alvo e no paralelismo dos consumidores e arredonde para cima. Adicionar partições posteriormente é possível, mas isso ainda altera a atribuição das chaves; portanto, provisione recursos acima do necessário desde o início.
Recrie o tópico se precisar de menos partições. Crie um novo tópico com a quantidade desejada de partições, migre produtores e consumidores para ele e desative o antigo após todas as mensagens terem sido consumidas ou expirado.
Limitações de alta disponibilidade (HA) em tópicos de partição única
No modo de armazenamento em nuvem, um tópico com apenas uma partição (partitionNum=1) não oferece alta disponibilidade (HA). Caso o nó que hospeda essa partição fique indisponível — seja por falha ou durante uma atualização — o tópico permanece inacessível até que o nó volte a ficar online.
O console do Message Queue for Apache Kafka exibe um alerta quando você tenta criar um tópico de armazenamento em nuvem com uma única partição. Tópicos de armazenamento em nuvem com partição única não são recomendados.
Comportamento de novas tentativas em tópicos de partição única
O mecanismo de nova tentativa do produtor Kafka afeta tópicos de partição única da seguinte forma:
Durante atualizações contínuas — Quando um nó fica temporariamente offline durante uma atualização planejada, o mecanismo de nova tentativa pode reduzir o impacto da interrupção. Os produtores podem tentar reenviar as mensagens e retomar o envio assim que o nó se recuperar. Isso reduz (mas não elimina) a perda de mensagens durante manutenções programadas.
Em falhas inesperadas de nós — As novas tentativas não evitam a perda de dados quando um nó falha subitamente. Se o nó não se recuperar dentro da janela de tentativas, as mensagens na fila de repetição ainda poderão ser perdidas. Políticas de repetição não substituem a HA.
Para garantir alta disponibilidade em cargas de trabalho de produção, configure seu tópico com pelo menos duas partições. Com múltiplas partições, o Message Queue for Apache Kafka continua a atender solicitações de leitura e escrita a partir de réplicas em nós íntegros, mesmo que um nó falhe.
Quais são os riscos de modificar a quantidade de partições de um tópico interno do Kafka?
O Kafka utiliza tópicos internos (como __consumer_offsets) para controle interno e gerenciamento de estado. Embora os clientes Kafka geralmente detectem alterações na quantidade de partições automaticamente, modificar manualmente esse valor em um tópico interno (por exemplo, aumentando de 1 para 12) introduz riscos significativos:
Problemas de ordenação de mensagens — Alterar a quantidade de partições muda a forma como as mensagens são roteadas. Mensagens anteriormente atribuídas a uma partição podem passar a ser mapeadas para outra, resultando em processamento fora de ordem.
Inconsistência de estado — Tópicos internos armazenam dados críticos de estado, como offsets de grupos de consumidores. Modificar a quantidade de partições pode corromper esse estado, causando comportamento inesperado nos consumidores, falhas de rebalanceamento ou instabilidade no cluster.
Não modifique manualmente a quantidade de partições de tópicos internos. Se considerar necessária alguma alteração, entre em contato com o suporte técnico da Alibaba Cloud para avaliar os riscos antes de prosseguir.