Como usar melhor o Kafka

introdução

Para garantir a estabilidade do Kafka durante o uso, é necessário garanti-lo na sequência do ciclo de uso do Kafka no negócio. Pode ser dividido principalmente em três etapas: prevenção antecipada (prevenção de problemas por meio de uso e desenvolvimento padronizados), monitoramento de tempo de execução (garantir a estabilidade do cluster e detectar problemas a tempo) e solução de problemas (ter um plano de emergência completo).

prevenção com antecedência

Prevenção preventiva significa prevenir a ocorrência de problemas através do uso e desenvolvimento padronizados. Inclui principalmente algumas práticas recomendadas no lado do cluster/produção/consumidor, testes de pré-lançamento e algumas funções de comutação temporária para emergências (como backlog de mensagens, etc.).

Princípios de ajuste Kafka:

1. Determine as metas de otimização e forneça-as quantitativamente (as metas de otimização comuns para Kafka são rendimento, latência, durabilidade e disponibilidade).

2. Após determinar o objetivo, é necessário esclarecer as dimensões da otimização.

Otimização universal: sistema operacional, JVM, etc.

Otimização direcionada: otimize o TPS do Kafka, velocidade de processamento, latência, etc.

Melhores práticas do lado da produção

Ajuste de parâmetros

Utilize a versão Java do Cliente;
Use kafka-producer-perf-test.sh para testar seu ambiente;
Definir memória, CPU, compactação em lote;
batch.size: Quanto maior for esse valor definido, maior será a taxa de transferência, mas maior será o atraso;
linger.ms: indica o tempo limite do lote. Quanto maior o valor, maior o rendimento, mas maior o atraso;
max.in.flight.requests.per.connection: O padrão é 5, que indica o número máximo de solicitações não confirmadas enviadas pelo cliente para uma única conexão (broker) antes do bloqueio. Quando exceder 1, a ordem dos dados será ser afetado;
compression.type: configurações de compactação, que irão melhorar o rendimento;
acks: configurações de durabilidade de dados;
Evite mensagens grandes (ocupando muita memória e reduzindo a velocidade de processamento do broker);
Ajuste do corretor: adicione num.replica.fetchers, melhore a sincronização do seguidor TPS, evite o Broker Full GC, etc.;
Quando a taxa de transferência for menor que a largura de banda da rede: adicione threads, aumente o tamanho do lote, adicione mais instâncias de produtor e aumente o número de partições;
Ao definir acks=-1, se o atraso aumentar: você pode aumentar num.replica.fetchers (o número de threads para dados de sincronização do seguidor) para mediar;
Transmissão entre data centers: adicione configurações de buffer de soquete e configurações de buffer tcp do sistema operacional.

práticas de desenvolvimento

a. Faça um bom trabalho no isolamento de tópicos

Diferencie os tópicos do Kafka de acordo com cenários específicos (se é permitido um certo atraso, mensagens em tempo real, tarefas periódicas agendadas, etc.) para evitar a exclusão ou bloqueio do processamento de mensagens comerciais em tempo real.

b. Faça um bom trabalho no controle do fluxo de mensagens

Se houver um gargalo no consumo de mensagens downstream ou a carga do cluster for muito alta, é necessário implementar controle de taxa de produção de tráfego ou estratégias de atraso/tentativa de envio de mensagens no final da produção (ou gateway de mensagens) para evitar o envio de um grande número de mensagens em um curto período de tempo.

c. Faça um bom trabalho de promoção de notícias complementares

Consulte manualmente a parte ausente dos dados e, em seguida, reenvie a mensagem para mq para restaurar os dados perdidos.

d. Garantir a ordem das mensagens

Se você precisar garantir que o Kafka esteja estritamente ordenado dentro da partição (ou seja, você precisa garantir que as duas mensagens estejam em ordem estrita), será necessário definir uma chave para permitir que certos tipos de mensagens sejam roteadas para a mesma partição do mesmo tópico de acordo com regras especificadas (pode resolver a maioria dos problemas de ordem de consumo).
No entanto, é necessário evitar o problema de distorção da mensagem dentro da partição (por exemplo, o roteamento de acordo com os IDs da loja pode facilmente levar ao desequilíbrio da mensagem).

1. Lado da produção: envie mensagens com chaves especificadas para garantir que as mensagens com a mesma chave sejam enviadas para a mesma partição.

2. Lado do consumidor: um único thread consome ou grava N filas de memória, e os dados com a mesma chave vão para a mesma fila de memória; então, para N threads, cada thread consome uma fila de memória, respectivamente.

e. Melhorar adequadamente a eficiência do envio de mensagens

Envio em lote : o Kafka primeiro armazena em cache as mensagens em uma fila dupla (buffer) na memória e as envia em lotes quando o volume da mensagem atinge o tamanho especificado pelo tamanho do lote, o que reduz a frequência de transmissão da rede e melhora a eficiência da transmissão;

Mensagens compactadas de ponta a ponta : um lote de mensagens é empacotado e compactado e depois enviado ao servidor do Broker. No entanto, a compactação e a descompactação frequentes também reduzirão o desempenho. Finalmente, elas são entregues aos consumidores de maneira compactada e são processado no lado do Consumidor. descompactar;

Envio assíncrono : transformar o produtor em um método assíncrono pode melhorar a eficiência do envio, mas se as mensagens forem geradas de forma assíncrona muito rapidamente, isso levará a muitos threads suspensos, memória insuficiente e, eventualmente, perda de mensagens;

Consumo paralelo da partição de índice : quando uma tarefa relativamente longa é executada, ela ocupará a partição de índice onde a mensagem está localizada e será bloqueada. As tarefas subsequentes não podem ser despachadas para clientes ociosos a tempo de processamento. Se o servidor permitir o consumo paralelo de partições de índice , recurso, tarefas subsequentes podem ser despachadas para outros clientes para execução em tempo hábil e não há necessidade de ajustar o número de partições de índice (mas este tipo de mensagem só é aplicável a mensagens que não precisam garantir a ordem da mensagem relação).

f. Garantir a confiabilidade da entrega de mensagens

Produtor : Se você possui altos requisitos de confiabilidade de dados, ao enviar mensagens, você precisa escolher uma API com callBack para enviar, e definir parâmetros como acks, retries, fatores, etc. perdido.

Corretor : Para obter maior desempenho e rendimento, o Kafka armazena dados em discos de forma assíncrona em lotes e adota o método de liberação em lote. Se os requisitos de confiabilidade dos dados forem altos, ele pode ser modificado para liberação síncrona. Melhorar a confiabilidade da mensagem.

Melhores práticas do lado do consumidor

Ajuste de parâmetros

Taxa de transferência: ajuste o número de partições e cache de páginas do sistema operacional (aloque memória suficiente para armazenar dados em cache);
tópico de deslocamento (__consumer_offsets): offsets.topic.replication.factor (o padrão é 3), offsets.retention.minutos (o padrão é 1440, que é 1 dia);
A confirmação de deslocamento é mais lenta: confirmação assíncrona ou confirmação manual;
fetch.min.bytes,fetch.max.wait.ms;
max.poll.interval.ms: O tempo máximo de atraso após chamar poll().Se poll() não for chamado após esse tempo, o consumidor será considerado morto e o rebalanceamento será realizado;
max.poll.records: O número máximo de registros retornados após chamar poll(), o padrão é 500;
sessão.timeout.ms;
Reequilíbrio do consumidor: verificar tempos limite, verificar tempos/lógica de processamento, problemas de GC;
Configuração de rede.

práticas de desenvolvimento

a. Torne o consumo de mensagens idempotente

A idempotência do consumo de mensagens é ajustada principalmente com base na lógica de negócios.

Tomemos como exemplo o processamento de mensagens de pedidos :

1. A chave idempotente exclusiva que consiste no número do pedido + status do pedido é armazenada no redis;

2. Antes do processamento, primeiro verificará se a chave existe no Redis. Se existir, significa que foi processada e será descartada diretamente;

3. Se o Redis não os tiver processado, insira os dados processados no banco de dados comercial e, por fim, insira a chave idempotente no Redis;

Resumindo, a idempotência é alcançada por meio do Redis como pré-processamento + índice exclusivo do banco de dados como garantia final.

b. Faça um bom trabalho de isolamento do consumidor

Quando o volume de mensagens é muito grande, os consumidores em tempo real e offline consomem um cluster ao mesmo tempo, e as operações pesadas de E/S de disco de dados offline afetarão diretamente o desempenho em tempo real dos negócios em tempo real e a estabilidade do conjunto.

De acordo com a natureza do consumo em tempo real, o comportamento do consumidor de mensagens pode ser dividido em duas categorias: consumidores em tempo real e consumidores offline.

Consumidor em tempo real : Altos requisitos para dados em tempo real; em cenários de consumo em tempo real, Kafka usará o cache de páginas do sistema para encaminhar dados diretamente da memória para consumidores em tempo real (leitura a quente), com pressão zero no disco e adequado para publicidade e recomendações e outros cenários de negócios.

Consumidor offline (consumidor periódico programado) : geralmente consome mensagens de minutos ou horas atrás. Esse tipo de mensagem geralmente é armazenado no disco. Quando consumido, acionará a operação IO do disco (leitura fria) e é adequado para cálculos de relatórios ., cálculo em lote e outros cenários de negócios executados periodicamente.

c. Evite o acúmulo de consumo de mensagens

Atrasar o processamento, controlar a velocidade e alocar mensagens dentro do intervalo de tempo (para mensagens com baixo desempenho em tempo real);
A velocidade de produção é maior que a velocidade de consumo, então você pode aumentar adequadamente as partições, aumentar o número de consumidores e aumentar o consumo de TPS;
Evite lógicas de consumo pesado e otimize o TPS do consumidor:

Se há um grande número de operações de banco de dados;

Tempo limite de chamada da interface de serviço downstream/externa;

Se há uma operação de bloqueio (levando ao bloqueio do thread);

Atenção especial precisa ser dada à lógica que envolve a amplificação de mensagens no link assíncrono Kafka.

Caso haja lógica de consumo pesado, os parâmetros xx precisam ser ajustados para evitar a saída do grupo de consumidores quando a mensagem não for consumida, causando problemas como reblance;
Garantir que o lado do consumidor não provoque a suspensão do consumo devido a exceções;
Se você estiver usando um grupo de consumidores, certifique-se de que o rebalanceamento não ocorra com frequência;
Consumo multithread, processamento pull em lote.

Nota: Ao fazer o processamento pull em lote, você precisa prestar atenção à versão do kafka, versão spring-kafka 2.2.11.RELEASE ou inferior. Se você configurar kafka.batchListener=true, mas definir o elemento recebido pela mensagem como um único elemento (lista não em lote), pode fazer com que o Kafka consuma apenas a primeira mensagem no cabeçalho após extrair um lote de mensagens.

d.Evite problemas de reequilíbrio

Condições de desencadeamento:

1. Mudanças no número de consumidores: novos consumidores ingressam, consumidores ficam offline (não conseguem enviar batimentos cardíacos a tempo e são “expulsos” do grupo), consumidores saem voluntariamente do grupo de consumidores (causado pelo tempo de consumo do consumidor ser muito longo);

2. O número de tópicos ou partições de tópicos inscritos no grupo de consumidores muda;

3. O nó GroupCoorinator correspondente ao grupo de consumidores é alterado.

Como evitar o reequilíbrio desnecessário (reequilíbrio causado por consumidores que ficam off-line ou abandonam voluntariamente grupos de consumidores):

1. Você precisa definir cuidadosamente os valores de session.timeout.ms (que determina o intervalo de tempo para a sobrevivência do consumidor) e heartbeat.interval.ms (um parâmetro que controla a frequência de envio de solicitações de pulsação).

Configuração do parâmetro 2.max.poll.interval.ms: controla o impacto da capacidade real de consumo do Consumidor no Rebalance e limita o intervalo máximo de tempo entre duas chamadas ao método poll pela aplicação do lado do Consumidor. O valor padrão é 5 minutos, o que significa que se o programa Consumidor não puder consumir as mensagens retornadas pelo método poll em 5 minutos, o Consumidor iniciará ativamente uma solicitação de "sair do grupo" e o Coordenador também iniciará uma nova rodada de Rebalanceamento. . Especificamente, você pode contar o tempo histórico gasto e definir o tempo mais longo como referência.

e. Garantir a confiabilidade do consumo de mensagens

Em circunstâncias normais, há mais cenários em que o cliente consome o corretor e perde mensagens.Se os dados de consumo do cliente não puderem ser perdidos, o autoCommit não deve ser usado, portanto deve ser enviado manualmente.

O mecanismo de envio automático do Consumidor consiste em submeter as mensagens recebidas de acordo com um determinado intervalo de tempo. O processo de confirmação e o processo de consumo de mensagens são assíncronos. Em outras palavras, o processo de consumo pode não ser bem-sucedido (por exemplo, uma exceção é lançada) e a mensagem de commit foi enviada e a mensagem foi perdida neste momento.

f. Garantir a ordem de consumo das mensagens

1. Tópicos diferentes (mensagens de fora de ordem): Se o pagamento e a geração de pedidos corresponderem a tópicos diferentes, só poderão ser processados ao nível do consumidor.

2. O mesmo tópico (mensagens fora de ordem): Um tópico pode corresponder a múltiplas partições, e cada uma corresponde a vários consumidores.Não há diferença essencial de "tópicos diferentes". (Pode-se entender que nosso serviço possui vários pods, e os produtores enviam mensagens sequencialmente, mas quando são roteadas para partições diferentes, podem ficar fora de serviço e o serviço consumir mensagens fora de ordem).

3. O mesmo tópico, a mesma partição (mensagens sequenciais): As mensagens Kafka são estritamente ordenadas dentro da partição. Por exemplo, todas as mensagens da mesma ordem são enviadas uma por uma para a mesma partição do mesmo tópico na ordem de geração .

Para mensagens fora de ordem :

Por exemplo: Pedido e pagamento encapsulam suas próprias mensagens respectivamente, mas o cenário de negócios do lado do consumidor precisa consumir as mensagens na ordem de mensagem de pedido -> mensagem de pagamento.

Tabela ampla (tabela de banco de dados na qual estão associados indicadores, dimensões e atributos relacionados aos temas de negócio): Ao consumir mensagens, apenas os campos correspondentes são atualizados. As mensagens terão apenas inconsistências de status temporárias, mas o status eventualmente será consistente. . Por exemplo, pedidos e pagamentos têm seus próprios campos de status, pedidos têm seus próprios campos de status e pós-venda têm seus próprios campos de status. Não há necessidade de garantir que as mensagens de pagamento, pedido e pós-venda estejam em ordem. Mesmo se as mensagens estiverem fora de ordem, apenas o seu próprio status será atualizado. O campo não afetará outros estados;

Mecanismo de compensação de mensagens: compare a mensagem com o banco de dados.Se os dados forem inconsistentes, reenvie a mensagem ao processo principal para processamento para garantir a consistência final;

Fila MQ: um intermediário (como fila redis) para manter a ordem do MQ;

Garantia do negócio: Garantir a ordem de consumo através da lógica de negócio;

Para mensagens sequenciais :

Ambos garantem a sequência vinculando mensagens a partições ou filas direcionadas e aumentam os recursos de consumo adicionando partições ou threads.

1. Consumo sequencial de thread único do consumidor

Quando o produtor envia uma mensagem, ele garante que a mensagem está ordenada na partição.Uma partição corresponde a um consumidor, garantindo a ordem de consumo da mensagem.

2. Consumo sequencial multithread do consumidor (estratégias específicas estão em capítulos posteriores)

O consumo sequencial de thread único é mal dimensionado. Para melhorar a velocidade de processamento dos consumidores, além de expandir horizontalmente o número de partições e adicionar consumidores, também é possível utilizar o consumo sequencial multithread.

Faça hash dos dados kafka recebidos para pegar o módulo (nota: se a partição kafka receber a mensagem, ela já está pegando o módulo, aqui você deve fazer um hash do ID e depois pegar o módulo) e enviar para filas diferentes, e em seguida, inicie vários threads para consumir Corresponde aos dados na fila.

Além disso, o centro de configuração é usado para alternar e expandir/diminuir dinamicamente o conjunto de threads.

g. Processar transações do consumidor

Através de mensagens de transação, a lógica de transação de alguns cenários de negócios pode ser bem garantida e não ocorrerão inconsistências de status entre sistemas devido à indisponibilidade da rede e outros motivos.

Quando qualquer serviço de atualização falhar, uma exceção será lançada. A mensagem de transação não será enviada ou revertida. O servidor de mensagens chamará de volta a interface de consulta de transação do final do envio para determinar o status da transação. O programa do final do envio pode executar tarefas inacabadas processamento de acordo com o conteúdo da mensagem. A tarefa é reexecutada e o servidor de mensagens é informado sobre o status da transação.

Práticas recomendadas de configuração de cluster

Configuração de cluster

Avaliação do Broker: O número de partições para cada Broker não deve exceder 2k e o tamanho da partição deve ser controlado (não exceder 25GB).

Avaliação do cluster (o número de Brokers é configurado de acordo com as seguintes condições): tempo de retenção de dados, tamanho do tráfego do cluster.

Expansão do cluster: o uso do disco deve estar abaixo de 60% e o uso da rede deve estar abaixo de 75%.

Monitoramento de cluster: mantenha o balanceamento de carga, garanta que as partições de tópico sejam distribuídas uniformemente em todos os Brokers e garanta que os estágios do cluster não esgotem o disco ou a largura de banda.

Avaliação do tópico

1. Número da partição:

O número de partições deve ser pelo menos consistente com o número de threads de consumo no maior grupo de consumidores;

Para tópicos usados com frequência, mais partições devem ser definidas;

Controlar o tamanho da partição (cerca de 25GB);

Considerar o crescimento futuro da aplicação (pode utilizar um mecanismo de expansão automática);

2. Use tópico com chave;

3. Expansão da partição: Quando o volume de dados da partição excede um limite, ela deve ser expandida automaticamente (na verdade, o tráfego de rede também deve ser considerado).

Configuração de partição

A configuração de múltiplas partições pode melhorar a simultaneidade do consumo do consumidor até certo ponto, mas muitas partições podem causar: sobrecarga excessiva de manipulação, uso excessivo de memória no final da produção, possível aumento no atraso de ponta a ponta e impacto na disponibilidade do sistema ., longo tempo de recuperação de falhas e outros problemas.

Defina o número de partições de acordo com os requisitos de rendimento:

1. Suponha que a taxa de transferência de uma única partição do Produtor seja P

2. A taxa de transferência do consumidor que consome uma partição é C

3. E a taxa de transferência necessária é T

4.Então o número de partições deve ser pelo menos maior que os valores máximos de T/P e T/c

Ajuste de desempenho

Metas de ajuste: alto rendimento, baixa latência.

Ajuste hierárquico

De cima para baixo, é dividido em camada de aplicativo, camada de estrutura, camada JVM e camada de sistema operacional.Quanto mais alta a camada, mais óbvio será o efeito de ajuste.

Tipo de ajuste	sugestão
sistema operacional	Desativar atualizações atime ao montar o sistema de arquivos; selecionar sistema de arquivos ext4 ou XFS; trocar configurações de espaço; tamanho do cache de página
JVM (configurações de heap e coletor GC)	Defina o tamanho de heap da JVM para 6 ~ 8 GB; é recomendado usar o coletor G1, que é conveniente e sem problemas e é menos difícil de otimizar do que o coletor CMS.
Lado do corretor	Mantenha as versões do servidor e do cliente consistentes
Camada de aplicação	Crie frequentemente instâncias de objetos Produtor e Consumidor; feche-os imediatamente quando terminar; faça uso racional de multi-threading para melhorar o desempenho.

Ajuste de taxa de transferência (TPS)

	lista de parâmetros
Lado do corretor	Aumente o valor do parâmetro num.replica.fetchers adequadamente, mas não exceda o número de núcleos de CPU.
	Ajustando os parâmetros do GC para evitar GC completo frequente
Lado do produtor	Aumente o valor do parâmetro batch.size adequadamente, como aumentá-lo do padrão de 16 KB para 512 KB ou 1 MB
	Aumente o valor do parâmetro linger.ms apropriadamente, como 10~100
	Definir compressão.type=lz4 ou zstd
	Definir acks = 0 ou 1
	definir tentativas = 0
	Se vários threads compartilharem a mesma instância do Produtor, aumente o valor do parâmetro buffer.memory
Consumidor	Use vários processos ou threads de consumo para consumir dados ao mesmo tempo
	Aumente o valor do parâmetro fetch.min.bytes, como defini-lo para 1 KB ou maior

Ajuste de latência

	lista de parâmetros
Lado do corretor	Defina o valor num.replica.fetchers apropriadamente
Lado do produtor	Definir linger.ms=0
	Desative a compactação, defina compression.type=none
	ataques = 1
Consumidor	Definir fetch.min.bytes=1

Teste de estabilidade

O teste de estabilidade do Kafka testa principalmente a integridade e a alta disponibilidade das instâncias/clusters do Kafka antes que o negócio fique online.

exame de saúde

1. Verifique a instância: Verifique o objeto da instância Kafka para obter todas as informações (como IP, porta, etc.);

2. Testar disponibilidade: acessar produtores e consumidores e testar conexões.

Testes de alta disponibilidade

Teste de exceção de nó único: reinicie o pod onde a cópia líder ou a cópia seguidora está localizada

etapa:

1. Visualize as informações da cópia do tópico

2. Exclua o pod correspondente

3. Script para detectar a disponibilidade do Kafka

Expectativa: Nenhum impacto na disponibilidade para produtores e consumidores.

Teste de exceção de cluster: reinicie todos os pods

etapa:

1. Exclua todos os pods

2. Script para detectar a disponibilidade do Kafka

Expectativa: O atendimento será normal depois que todos os corretores estiverem prontos.

Monitoramento de tempo de execução

O monitoramento do tempo de execução inclui principalmente práticas recomendadas para configuração de estabilidade do cluster e monitoramento do Kafka, com o objetivo de descobrir prontamente problemas relacionados e exceções geradas pelo Kafka durante o tempo de execução.

Monitoramento de estabilidade de cluster

Configuração do cluster Tencent Cloud CKafka

Para configurar corretamente as instâncias do Kafka, concentre-se nestes dados:

Capacidade do disco e pico de largura de banda
tempo de retenção de mensagens;
Política de retenção dinâmica;

a. Capacidade de disco e largura de banda de pico

Ele pode ser estimado com base no tamanho real do conteúdo da mensagem comercial, no qps de envio de mensagens, etc. Você pode defini-lo o maior possível; o valor específico pode ser verificado com base no monitoramento da instância. Se a porcentagem de uso do disco atingir um valor alto em um curto período de tempo, a expansão é necessária.

Largura de banda máxima = tráfego máximo de produção * número de cópias

b. Tempo de retenção de mensagens

Mesmo que a mensagem seja consumida, ela persistirá enquanto o armazenamento em disco for retido. Esta configuração ocupará espaço em disco. Se a quantidade de mensagens diárias for grande, o tempo de retenção poderá ser reduzido de forma adequada.

c. Política de retenção dinâmica

Recomenda-se ativar as configurações de retenção dinâmica. Quando a capacidade do disco atingir o limite, as mensagens mais antigas serão excluídas e as mensagens fora do intervalo de duração garantido serão excluídas no máximo (estratégia de eliminação), o que pode impedir em grande parte que o disco fique cheio.

Porém, não haverá notificação ativa quando os ajustes forem feitos, mas podemos detectar alterações na capacidade do disco configurando alarmes.

Configuração de cluster Kafka autoconstruída

1. Defina parâmetros de configuração de log para facilitar o gerenciamento dos logs;

2. Compreender os (baixos) requisitos de hardware do kafka;

3. Faça uso completo do Apache ZooKeeper;

4. Configure a replicação e a redundância da maneira certa;

5. Preste atenção na configuração do tema;

6. Use processamento paralelo;

7. Configure e isole o Kafka com a segurança em mente;

8. Evite paradas aumentando os limites;

9. Mantenha a latência da rede baixa;

10. Aproveite o monitoramento e alertas eficazes.

Isolamento de recursos

a. Isolamento físico no nível do corretor

Se tópicos em diferentes linhas de negócios compartilharem um disco, se ocorrer um problema com um consumidor e atrasos no consumo, resultando em leituras frequentes do disco, isso afetará a gravação de TPs de outras linhas de negócios no mesmo disco.

Solução: Isolamento físico no nível do corretor: criação de tópicos, migração de tópicos e processo de recuperação de tempo de inatividade

b.Isolamento de fila RPC

A fila RPC do Kafka carece de isolamento. Uma vez que um determinado tópico é processado lentamente, todas as solicitações serão interrompidas.

Solução: É necessário separar o fluxo de controle do fluxo de dados, e o fluxo de dados deve ser isolado conforme tópico.

1. Divida a fila de chamadas em várias chamadas e aloque um conjunto de threads para cada fila de chamadas.

2. Uma fila processa as solicitações do controlador sozinha (isola o fluxo de controle) e as filas restantes são hashadas de acordo com o tópico (isola os fluxos de dados).

Se houver um problema com um tópico, apenas um dos pools de threads de processamento RPC e a fila de chamadas serão bloqueados, garantindo que outros links de processamento funcionem sem problemas.

Limite de velocidade inteligente

Toda a lógica de limite de velocidade é implementada no final do processamento do thread de trabalho RPC. Depois que o RPC é processado, a detecção do limite de velocidade é realizada por meio do módulo de controle de limite de velocidade.

1. Configure o tempo de espera e, em seguida, coloque-o na fila atrasada; caso contrário, coloque-o na fila de resposta.

2. As solicitações colocadas na fila atrasada serão colocadas na fila de resposta pelo thread atrasado após o tempo de espera ser atingido.

3. Finalmente, a solicitação na fila de resposta é devolvida ao consumidor.

Monitoramento Kafka

Monitoramento de caixa branca: indicadores próprios do serviço ou sistema, como carga de CPU, informações de stack, número de conexões, etc.;

Monitoramento de caixa preta: Geralmente, é um método de monitoramento que monitora as funções do sistema visíveis simulando usuários externos.Os indicadores relacionados incluem indicadores de desempenho e disponibilidade, como atraso de mensagens, taxa de erros e taxa de repetição.

monitor	Recursos/Métricas	Detalhes
Monitoramento de caixa preta	operar	Operações de tópico: criar, visualizar, visualizar, atualizar, excluir
	Servir	A gravação e o consumo de dados são bem-sucedidos
	sistema	Carga da CPU, informações de pilha, número de conexões, etc.
Monitoramento de caixa branca	capacidade	Espaço de armazenamento total, espaço de armazenamento utilizado, utilização máxima da partição, recursos do cluster, número de partições, número de tópicos;
	fluxo	Escrita de mensagens, taxa de consumo, entrada e saída da rede do cluster;
	Atraso	Tempo de escrita e consumo de mensagens (média, percentil 99, tempo máximo), atraso no consumo do tópico (atraso de deslocamento)
	erro	O número de nós anormais no cluster, o número de rejeições de gravação de mensagens, o número de falhas no consumo de mensagens e erros relacionados que dependem do zookeeper

Alarme Tencent Cloud CKafka

Para CKafka, os alarmes precisam ser configurados (esses alarmes geralmente são para backlog de mensagens, disponibilidade, integridade do cluster/máquina, etc.).

a. Indicadores

Por exemplo: status de integridade da instância, número de nós, número de nós íntegros, número de partições problemáticas, número de mensagens de produção, número de solicitações de consumo, utilização de memória JVM, tempo médio de resposta de produção, deslocamento de consumo de partição, etc.

Para indicadores específicos, consulte: https://cloud.tencent.com/document/product/597/54514

b.Configuração

Documento de configuração: https://cloud.tencent.com/document/product/597/57244

Selecione uma instância de monitoramento e configure o conteúdo e os limites do alarme.

Geralmente, as configurações de alarme são feitas para o cluster Kafka do próprio serviço atual. No entanto, se um serviço downstream que depende de suas próprias mensagens tiver um problema de consumo, não teremos conhecimento disso. Além disso, se o serviço ao consumidor não compartilhar No mesmo cluster, as mensagens podem ser enviadas repetidamente. O problema com o serviço em si é difícil de encontrar.

c.Plano

Antes que o negócio fique online, é melhor classificar as mensagens de tópico envolvidas em seu próprio serviço (final da produção upstream e final do consumidor downstream) e refinar a configuração do alarme.Se ocorrer uma exceção Kafka upstream ou ocorrer acúmulo de mensagens Kafka downstream, você pode detectá-lo a tempo. Em particular, certos alarmes ou planos precisam ser feitos para cenários onde pode haver uma grande quantidade de mensagens instantâneas (como importação de dados em lote, sincronização completa programada de dados, etc.) para evitar indisponibilidade do serviço ou impacto nas mensagens comerciais normais.

Plataforma de alarme autoconstruída

Use a plataforma de alarme autoconstruída para configurar alarmes de exceção para o próprio serviço, incluindo exceções de negócios lançadas pela estrutura ao usar o componente Kafka e durante o processo de lógica de consumo do Kafka.

Entre elas, as situações que podem exigir atualização anormal (devido a) devem ser tratadas separadamente (para Spring Kafka):

1. Manipulador de exceção Kafka personalizado: implemente o método da interface KafkaListenerErrorHandler, registre um ouvinte de exceção personalizado, distinga exceções de negócios e lance-as;

2. Ao consumir mensagens Kafka, defina o parâmetro errorHandler de @KafkaListener para o manipulador de exceção Kafka definido;

3. Depois disso, a exceção de negócios especificada será lançada em vez de ser encapsulada em uma exceção da estrutura Spring Kafka, resultando na incapacidade de compreender claramente as informações específicas da exceção.

Componente de monitoramento Kafka

Atualmente não existe uma solução reconhecida no setor e cada empresa possui seu próprio método de monitoramento.

Gerente Kafka: Deve ser considerado o mais famoso quadro de monitoramento exclusivo do Kafka.É um sistema de monitoramento independente.

Kafka Monitor: a estrutura gratuita de código aberto do LinkedIn oferece suporte a testes de sistema de clusters e monitoramento em tempo real dos resultados dos testes.

CruiseControl: É também uma estrutura de monitoramento de código aberto desenvolvida pelo LinkedIn, usada para monitorar o uso de recursos em tempo real e fornecer operações comuns de operação e manutenção. Não há interface UI, apenas a API REST é fornecida.

Monitoramento JMX: Como os indicadores de monitoramento fornecidos pelo Kafka são todos baseados em JMX, qualquer framework do mercado que possa integrar JMX pode ser utilizado, como Zabbix e Prometheus. Existem plataformas de big data com seus próprios sistemas de monitoramento: plataformas de big data como o CDH fornecido pela Cloudera fornecem naturalmente soluções de monitoramento Kafka.

JMXTool: Uma ferramenta de linha de comando fornecida pela comunidade que pode monitorar indicadores JMX em tempo real. Responder a essa pergunta é um bônus absoluto, porque poucas pessoas sabem disso e dará às pessoas a sensação de que você está familiarizado com a ferramenta Kafka. Se você ainda não entende seu uso, pode executar kafka-run-class.sh kafka.tools.JmxTool sem parâmetros na linha de comando para aprender seu uso.

Monitor Kafka

Entre eles, o Kafka Monitor simula o comportamento do cliente, produz e consome dados e coleta indicadores de desempenho e disponibilidade, como atraso de mensagens, taxa de erros e taxa de repetição.Ele pode descobrir a situação de consumo de mensagens downstream e ajustar dinamicamente o envio de mensagens. (Durante o uso, preste atenção ao controle de cobertura de amostra, cobertura de função, tráfego, isolamento de dados e atraso)

Vantagens do monitor Kakfa :

1. Garanta que o monitoramento cubra todas as partições iniciando uma tarefa de produção separada para cada partição.

2. As mensagens produzidas contêm carimbos de data e hora e números de sequência. O Kafka Monitor pode usar esses dados para fazer estatísticas sobre atraso de mensagens, taxa de perda e taxa de repetição.

3. Alcançar o objetivo de controlar o tráfego definindo a frequência de geração de mensagens.

4. A mensagem produzida é especificada como um tamanho configurável durante a serialização (para verificar a capacidade de processamento de dados de diferentes tamanhos e comparação de desempenho do mesmo tamanho de mensagem).

5. Ao definir IDs de tópico e de produtor separados para operar o cluster Kafka, você pode evitar a contaminação de dados online e obter um certo grau de isolamento de dados.

Com base na ideia de design do Kafka Monitor, monitoramento de desempenho e indicadores de alarme, como atraso de mensagens, taxa de erros e taxa de repetição, podem ser introduzidos com base nas características do negócio.

Solucionar problemas

Evite pequenas alterações e tenha um plano de emergência completo ao encontrar problemas/falhas para localizar e resolver problemas rapidamente.

Plano de emergência de acumulação de mensagens Kafka

Descrição do problema : Há um acúmulo de mensagens no lado do consumidor, fazendo com que os serviços que dependem das mensagens não consigam detectar mudanças nos negócios em tempo hábil, causando atrasos em alguma lógica de negócios e processamento de dados e causando facilmente bloqueio de negócios e dados questões de consistência.

Planejar : solução de problemas, estratégia de expansão de capacidade e atualização de configuração, estratégia de conversão de tópicos de mensagens, estratégia de consumo multithread configurável.

Solução de problemas

Ao encontrar um acúmulo de mensagens, você pode localizar a causa do problema a partir das seguintes perspectivas:

1. Se há um aumento repentino na quantidade de dados no final da produção da mensagem.

2. Se o poder de consumo dos consumidores de notícias diminuiu.

3. O backlog de mensagens ocorre em todas as partições ou todas as partições têm um backlog?

Em relação ao backlog de mensagens causado pelos pontos 1 e 2: Para o backlog temporário de mensagens, aumentar a velocidade de consumo por meio de expansão de partição, expansão de capacidade e atualização de configuração, consumo multithread, consumo de lote, etc.

Para o backlog de mensagens causado pelo ponto 3: Você pode usar a estratégia de transferência de tópicos de mensagens.

Estratégia de expansão de capacidade e atualização de configuração

1. Verifique o estado de consumo e envio do final da produção (verificando principalmente se as mensagens continuam a ser geradas, se existem defeitos lógicos e se são enviadas mensagens duplicadas);

2. Observar a situação de consumo por parte do consumidor (estimar o processamento e limpeza das mensagens acumuladas e se existe tendência de queda);

3. Se for um problema do lado da produção, avalie se pode ser resolvido aumentando o número de partições, ajustando o deslocamento, excluindo o tópico (o impacto precisa ser avaliado), etc.;

4. Adicionar novas máquinas e recursos dependentes do lado do consumidor para melhorar a capacidade de consumo;

5. Se houver um problema de consistência de dados, ele deverá ser verificado através de comparação de dados, reconciliação e outras funções.

Configurar estratégia de consumo multithread

Resumindo, ou seja, consumo do pool de threads + estratégia de configuração dinâmica do pool de threads: hash dos dados kafka recebidos para pegar o módulo (se a partição kafka receber a mensagem, já é módulo, aqui você deve fazer um hash no id e depois pegue o módulo)) são enviados para filas diferentes e, em seguida, vários threads são iniciados para consumir os dados nas filas correspondentes.

Idéias de design:

1. Inicialize o pool de threads de consumo sequencial do negócio correspondente quando o aplicativo for iniciado (na demonstração, é o pool de threads de consumo do pedido);

2. A classe de monitoramento de pedido extrai a mensagem e envia a tarefa para a fila correspondente no pool de threads;

3. O thread do pool de threads processa os dados da tarefa na fila vinculada;

4. Após cada thread concluir a tarefa, aumente o número de deslocamentos a serem enviados;

5. Na aula de escuta, verificar se o número de offsets a serem submetidos é igual ao número de registros extraídos, e se sim;

6. Envie manualmente o deslocamento (desative o envio automático do kafka e espere até que a tarefa extraída desta vez seja processada antes de enviar o deslocamento)

Além disso, a configuração do thread e a configuração do pod podem ser ajustadas de acordo com o tráfego comercial. Por exemplo, um nível de simultaneidade relativamente alto é definido durante os períodos de pico para processar mensagens rapidamente, e um nível de simultaneidade menor é definido durante os períodos fora de pico para liberar recursos do sistema. Aqui, você pode consultar o centro de configuração fornecido pela Meituan para modificar a configuração e definir dinamicamente os parâmetros do pool de threads para obter expansão ou contração dinâmica.

Realiza expansão e contração dinâmicas :

1. Atualize o valor simultâneo de configuração na classe de escuta OrderKafkaListener por meio do centro de configuração.

2. Ao modificar o valor simultâneo por meio do método set, primeiro modifique o valor interrompido para interromper o conjunto de threads em execução no momento.

3. Após a execução, um novo pool de threads é criado com o novo nível de simultaneidade para obter expansão e contração dinâmicas.

Além disso, você também pode adicionar uma nova opção. Se estiver definido como verdadeiro, você pode interromper o pool de threads durante a inicialização e alternar a função quando houver uma falha.

Nota: Se estiverem envolvidos problemas de consistência de dados, a verificação deverá ser realizada através de comparação de dados, reconciliação e outras funções.

Estratégia de transferência de tópico

Quando ocorre backlog de mensagens em todas as partições ou todas as partições estão com backlog, a expansão temporária só pode ser executada para consumir dados em uma velocidade mais rápida.

Idéias de design:

1. Crie temporariamente 10 ou 20 vezes o número original de filas (crie um novo tópico e particione 10 vezes o número original);

2. Em seguida, escreva um programa consumidor que distribua mensagens temporariamente. Este programa é implantado para consumir o backlog de mensagens. Após o consumo, nenhum processamento demorado é executado e as mensagens são pesquisadas diretamente e gravadas na fila construída temporariamente dividida em 10 números;

3. Em seguida, requisite 10 vezes o número de máquinas para implantar consumidores, e cada lote de consumidores consome uma mensagem de fila temporária;

4. Essa abordagem equivale a expandir temporariamente os recursos da fila e do consumidor em 10 vezes e consumir mensagens a 10 vezes a velocidade normal.

5. Após a conclusão do consumo rápido, restaure a estrutura de implantação original e reutilize a máquina consumidora original para consumir mensagens.

Melhorias :

1. O programa do consumidor pode ser escrito no serviço;

2. Especifique um “tópico do plano” e escreva o “tópico do plano” antecipadamente no serviço;

3. Use o modo de estratégia para converter "tópico de negócios" -> "tópico de plano".

Nota :

1. Se estiverem envolvidos problemas de consistência de dados, a verificação precisa ser feita através de comparação de dados, reconciliação e outras funções;

2. Você precisa ter um serviço de conversão de tópico separado, ou modificar o código do serviço, ou escrever a lógica multithread antecipadamente.

Exceção de consumo Kafka causa bloqueio de consumo

Descrição do problema: Um determinado consumo de mensagens é anormal ou uma determinada operação é demorada, resultando em diminuição da capacidade de consumo de um único pod, ou até mesmo bloqueio.

Solução: definir deslocamento; mudar estratégia de consumo multithread.

Definir deslocamento

1. Ajuste o deslocamento: Entre em contato com a operação e manutenção e mova o deslocamento para trás uma posição;

2. Push suplementar de mensagem: Push suplementar de mensagem para mensagens ou dados ignorados dentro de um determinado período de tempo;
3. Se houver problemas de consistência de dados, eles precisam ser verificados por meio de comparação de dados, reconciliação e outras funções.

Mudar estratégia de consumo multithread

Consulte a "Estratégia de consumo multithread configurável" acima para ativar a chave de consumo multithread quando ocorrer bloqueio.

Nota: você precisa modificar o código ou escrever a lógica multithreading antecipadamente

Plano de perda de mensagens Kafka

Descrição do problema: o serviço não consumiu mensagens Kafka conforme esperado, causando problemas de negócios.

Plano: análise de causa raiz; envio de notícias.

análise de causa raiz

1. Se o final da produção envia o consumo com sucesso (a fonte é perdida)

Mensagens perdidas do corretor: para obter maior desempenho e rendimento, o Kafka armazena dados em lotes de forma assíncrona no disco. A liberação assíncrona do disco pode causar a perda dos dados de origem;

O Produtor perdeu a mensagem: houve um bug na lógica de envio, fazendo com que a mensagem fosse enviada com sucesso.

Solução: A integridade do final da produção e do cluster precisa ser verificada; a mensagem é reemitida.

2. Se foi consumido com sucesso

Além disso, se houver algum bug na lógica de consumo, também levará à ilusão de perda de mensagem.

Solução: Resolva o problema e modifique o mecanismo de confirmação de consumo conforme apropriado.

3. Existem outros serviços que partilham o mesmo grupo de consumidores?

O uso indevido do mesmo grupo de consumidores por vários serviços resultará na perda de mensagens em uma determinada taxa ou regularidade.

Por exemplo, ao criar uma mensagem Kafka de um usuário, o centro de preços e o serviço de promoção podem ter utilizado indevidamente um grupo de consumidores, fazendo com que cada serviço consuma parte da mensagem, causando a ocorrência ocasional de alguns problemas.

Solução: Modifique a configuração, reinicie o serviço e crie vários grupos de consumidores; é necessário verificar antecipadamente se vários serviços compartilham o mesmo consumidor (detecção + comparação).

Envio de notícias

1. Consultar as informações dos dados afetados através do impacto nos negócios;

2. Construir mensagens kafka e realizar compensação de mensagens;

3. Se estiverem envolvidos problemas de consistência de dados, a verificação precisa ser realizada através de comparação de dados, reconciliação e outras funções.

Para cada serviço enviado externamente, a extremidade da produção geralmente precisa ter uma interface de envio de mensagens relativamente completa, e a extremidade do consumidor também precisa garantir a idempotência do consumo da mensagem.

outro

Controle de custos Kafka

Máquinas, armazenamento e redes

máquina

Precisa reavaliar suas decisões de tipo de instância: seu cluster está saturado? Em que circunstâncias está saturado? Existem outros tipos de instância que podem ser mais apropriados do que aquele que você selecionou quando criou o cluster pela primeira vez? Uma combinação de instâncias otimizadas para EBS com drives GP2/3 ou IO2 realmente oferece melhor preço/desempenho do que máquinas i3 ou i3en (e as vantagens que elas trazem)?

Armazenamento e rede

A compactação não é novidade no Kafka, e a maioria dos usuários já sabe que pode escolher entre GZIP, Snappy e LZ4. Mas desde que o KIP-110 foi incorporado ao Kafka e o compressor para compressão Zstandard foi adicionado, ele alcançou melhorias significativas de desempenho e é uma maneira perfeita de reduzir custos de rede.

Ao custo de um uso de CPU um pouco maior por parte do produtor, você obtém maior compactação e “espreme” mais informações na linha.

A Amplitude disse em sua postagem que depois de mudar para o Zstandard, o uso da largura de banda foi reduzido em dois terços, economizando dezenas de milhares de dólares em custos mensais de transferência de dados apenas no pipeline de processamento.

conjunto

Um cluster desequilibrado pode prejudicar o desempenho do cluster, fazendo com que alguns corretores sejam mais carregados do que outros, resultando em latências de resposta mais altas e, em alguns casos, saturando os recursos desses corretores, levando a expansão desnecessária e afetará ainda mais os custos do cluster.

Além disso, um cluster desequilibrado corre o risco de um MTTR mais alto após uma falha do corretor (por exemplo, quando esse corretor mantém mais partições desnecessariamente) e um risco maior de perda de dados (imagine um fator de replicação de 2 tópicos, um dos nós é difícil de iniciar devido a muitos segmentos a serem carregados na inicialização).

Idempotência de consumo de mensagens

definição:

A chamada idempotência, o conceito matemático é: f(f(x)) = f(x). A função f representa o processamento de mensagens. Em termos leigos, quando os consumidores recebem mensagens duplicadas e as processam repetidamente, devem também garantir a consistência dos resultados finais.

Por exemplo, transferência bancária, colocação de pedidos, etc., não importa quantas vezes você tente novamente, você deve garantir que o resultado final seja consistente.

Aproveite as restrições exclusivas do banco de dados

Combine vários campos no banco de dados para criar uma restrição única, que garante que exista no máximo um registro na tabela mesmo com múltiplas operações (como criar um pedido, criar uma fatura, criar um fluxo, etc.).

Além disso, qualquer sistema de classe de armazenamento que suporte semântica semelhante a "INSERT IF NOT EXIST" (como o SETNX do Redis) pode ser usado para implementar o consumo idempotente.

Definir condições prévias

1. Defina uma pré-condição para alteração de dados (número da versão, updateTime);

2. Atualizar os dados se as condições forem satisfeitas, caso contrário recusar a atualização dos dados;

3. Ao atualizar os dados, altere os dados na pré-condição ao mesmo tempo (número da versão + 1, atualização updateTime).

Registrar e revisar ações

1. Registre um ID globalmente exclusivo para cada mensagem;

2. Ao consumir, primeiro verifique se esta mensagem foi consumida com base neste ID globalmente exclusivo;

3. Caso não tenha sido consumido, atualize os dados e defina o status de consumo para “consumido”.

Dentre elas, ao “verificar o status do consumo, depois atualizar os dados e definir o status do consumo”, as três operações devem ser utilizadas como um conjunto de operações para garantir a atomicidade.