Find and optimize large keys and hot keys - Tair (Redis® OSS-Compatible): Central de Documentação do Alibaba Cloud

Chaves grandes e chaves quentes podem degradar o desempenho do service, causar timeouts em requisições ou até mesmo provocar falhas no sistema. Este tópico descreve como localizar e otimizar rapidamente essas chaves. Também analisa suas causas e efeitos, além de fornecer medidas preventivas para reduzir o impacto nos seus negócios.

Etapa 1: Localize rapidamente chaves grandes e quentes

Ferramentas do console Alibaba Cloud

Tair and Redis oferecem os recursos Top Key Statistics e Offline Full Key Analysis no console para ajudar você a identificar rapidamente chaves grandes e quentes.

Método	Limites	Descrição	Procedimento
Top Key Statistics (Recomendado)	Este recurso é compatível apenas com o Redis Open-Source Edition 5.0 ou posterior e com instâncias de memória otimizada e memória persistente do Tair (Enterprise Edition).	Exibe informações em tempo real sobre as três principais chaves grandes e quentes de cada estrutura de dados em cada shard. Permite visualizar o histórico de chaves grandes e quentes dos últimos quatro dias.	Faça login no console e acesse a página Instances. Na barra de navegação superior, selecione a região onde reside a instância que você deseja gerenciar. Em seguida, localize a instância e clique em ID da instância. No painel de navegação à esquerda, clique em CloudDBA > Top Key Statistics ou Offline Key Analysis.
Offline Full Key Analysis	Este recurso não é compatível com instâncias baseadas em disco.	Analisa personaliza o arquivo de backup RDB para obter informações como uso de memória, distribuição e tempo de expiração das chaves. A análise não ocorre em tempo real e pode ser demorada para arquivos RDB grandes. Não analisa informações de chaves quentes.

Caso sua instância não seja compatível com esses recursos, utilize os métodos abaixo.

Outros métodos para localizar chaves grandes e quentes

Método	Vantagens e desvantagens	Descrição
Use os parâmetros bigkeys, memkeys e hotkeys do redis-cli	Vantagens: Prático, rápido e seguro. Desvantagens: Os resultados da análise não são personalizáveis e podem ter baixa precisão ou atualidade. Este método percorre todas as chaves da instância, o que pode afetar o desempenho.	Os parâmetros bigkeys, memkeys e hotkeys do redis-cli recuperam estatísticas gerais de chaves e a principal chave grande ou quente de cada estrutura de dados. As diferenças são as seguintes: bigkeys: Estatísticas para chaves grandes. Para coleções ou listas, retorna o número de elementos. memkeys: Estatísticas para chaves grandes. Retorna o tamanho de memória ocupado pelo valor da chave. hotkeys: Estatísticas para chaves quentes. Estruturas de dados compatíveis: STRING, LIST, HASH, SET, ZSET e STREAM. Por exemplo, o comando para bigkeys é `redis-cli -h r-*.redis.rds.aliyuncs.com -a <password> --bigkeys`.
Analise chaves-alvo usando comandos integrados	Vantagens: Impacto mínimo nos services online. Desvantagens: O comprimento serializado retornado de uma chave não corresponde ao seu comprimento real na memória. Portanto, o resultado não é preciso e serve apenas como referência.	Para chaves de diferentes estruturas de dados, use os seguintes comandos de baixo risco para determinar se são chaves grandes. Tipo STRING: O comando STRLEN retorna o número de bytes do valor da chave correspondente. Tipo LIST: O comando LLEN retorna o comprimento da lista da chave correspondente. Tipo HASH: O comando HLEN retorna o número de membros da chave correspondente. Tipo SET: O comando SCARD retorna o número de membros da chave correspondente. Tipo ZSET: O comando ZCARD retorna o número de membros da chave correspondente. Tipo STREAM: O comando XLEN retorna o número de membros da chave correspondente. Nota Os comandos DEBUG OBJECT e MEMORY USAGE consomem muitos recursos e têm complexidade de tempo O(N). Eles podem bloquear a instância e não são recomendados.
Localize chaves quentes na camada de aplicação	Vantagens: Localiza chaves quentes com precisão e rapidez. Desvantagens: Aumenta a complexidade do código da aplicação e pode degradar levemente o desempenho.	Adicione código na camada de aplicação para registrar acessos à instância e realizar análises assíncronas.
Use a ferramenta redis-rdb-tools para análise personalizada de chaves grandes	Vantagens: Compatível com análise personalizada sem impacto nos services online. Desvantagens: A análise não ocorre em tempo real e pode ser demorada para arquivos RDB grandes.	O Redis-rdb-tools é uma ferramenta open-source escrita em Python compatível com análise personalizada de arquivos de snapshot RDB. Após baixar o arquivo RDB, analise o uso de memória de todas as chaves na instância e execute consultas flexíveis conforme necessário.
Encontre chaves quentes usando o comando MONITOR	Vantagens: Prático e seguro. Desvantagens: Consome recursos de CPU, memória e rede. Os resultados podem não ser oportunos ou precisos.	O comando MONITOR imprime todas as requisições enviadas à instância, incluindo horário, informações do cliente, comandos e dados das chaves. Em situações de emergência, execute brevemente o comando MONITOR e salve a saída em um arquivo. Após interromper o comando MONITOR, analise as requisições no arquivo para identificar chaves quentes durante aquele período. Nota Como o comando MONITOR pode degradar significativamente o desempenho da instância, não o utilize exceto em circunstâncias especiais.

Etapa 2: Otimize chaves grandes e quentes

Chaves grandes

Solução	Cenários	Ações recomendadas
Limpe dados expirados	Acúmulo de grande volume de dados expirados, como dados incrementais não limpos em um HASH.	Utilize o comando HSCAN combinado com o comando HDEL para limpar dados inválidos. Isso evita o bloqueio da instância, que pode ocorrer ao limpar uma grande quantidade de dados de uma só vez.
Comprima chaves grandes	Dados compressíveis, como texto JSON e XML, incluindo logs e configurações.	Ative a compactação durante a serialização, usando GZIP ou Snappy, por exemplo. Adote um protocolo de serialização binária, como Protocol Buffers. Nota As operações de compactação e descompactação consomem recursos extras de CPU e podem afetar o desempenho do processamento.
Divida chaves grandes	Estruturas de dados como HASH e ZSET frequentemente acessadas, como tabelas de classificação.	Divida as chaves com base na lógica de negócios, como por ID de usuário ou intervalo de tempo. Utilize um design de chave de sharding, como user:1001:shard1 e user:1001:shard2. A divisão de chaves grandes previne eficazmente a distorção de dados.
Descarregue chaves grandes	Arquivos grandes ou Binary Large Objects (BLOBs) do tipo String.	Armazene dados inadequados em outros sistemas de armazenamento, como o OSS, e exclua-os da instância. Para o Redis Open-Source Edition 4.0 e posterior: Use o comando UNLINK para excluir com segurança chaves grandes ou até mesmo extra-grandes. Este comando limpa as chaves de forma assíncrona para evitar o bloqueio da thread principal. Para versões anteriores ao Redis Open-Source Edition 4.0: Utilize o comando SCAN para percorrer e excluir dados em lotes. Isso evita o bloqueio da thread principal causado pela exclusão de muitas chaves simultaneamente.

Chaves quentes

Solução	Cenários	Ações recomendadas
Replicar chaves quentes em arquitetura cluster	Uma chave quente é armazenada integralmente em um único shard, e as requisições não podem ser distribuídas migrando dados parciais.	Copie a chave quente e migre as réplicas para outros shards de dados. Por exemplo, copie uma chave quente chamada `foo` para criar três chaves idênticas chamadas `foo2`, `foo3` e `foo4`. Migre essas três chaves para outros shards de dados para aliviar a pressão sobre o único shard que contém a chave quente. Nota A desvantagem desta solução é a necessidade de modificar seu código para manter múltiplas réplicas, sendo difícil garantir a consistência de dados entre elas. Por exemplo, uma operação de atualização deve ser sincronizada em todas as réplicas. Utilize esta solução como medida temporária para mitigar problemas urgentes.
Enable read/write splitting	Cargas de trabalho com muitas leituras e poucas escritas	Se a carga de requisições de leitura ainda estiver alta após ativar este recurso, adicione mais nós somente leitura para aliviar ainda mais a carga. Nota Em cenários com volumes de requisição extremamente altos, a sincronização primário/secundário inevitavelmente terá latência, o que pode causar leitura de dados inconsistentes. Portanto, não ative a divisão de leitura/escrita em cenários com alta pressão de leitura e escrita e requisitos rigorosos de consistência de dados. Após ativar a divisão de leitura/escrita, se a CPU do nó mestre permanecer alta enquanto os nós somente leitura ficarem ociosos, geralmente há dois motivos. Primeiro, a divisão de leitura/escrita descarrega apenas requisições de leitura — requisições de escrita (incluindo escritas em chaves quentes) são sempre tratadas pelo nó mestre. Segundo, alguns comandos de leitura seguem regras especiais de encaminhamento: por exemplo, o comando SCAN é sempre encaminhado para o nó mestre (enquanto HSCAN, SSCAN e ZSCAN são distribuídos uniformemente entre o mestre e os nós somente leitura por módulo de slot), então o uso intenso de SCAN mantém a CPU do nó mestre alta. Para as regras de roteamento, consulte Read/write splitting. Nesses casos, divida as chaves quentes, mude para comandos como HSCAN ou Change the shard count of a cluster instance para distribuir a pressão no nó mestre.

Etapa 3: Evite que chaves grandes e quentes afetem seus negócios

Causas de chaves grandes e quentes

No Tair and Redis, a unidade mínima para distribuição de dados é a chave. Uma única chave é armazenada em um shard de dados específico e não é dividida. Fatores como planejamento insuficiente de negócios, acúmulo de dados inválidos e aumentos repentinos no volume de acesso podem levar à geração de chaves grandes e quentes em uma instância. Os exemplos incluem:

Categoria	Causa
Chave grande	Uso do Tair and Redis em cenários inadequados, resultando em valores de chave excessivamente grandes. Por exemplo, usar uma chave do tipo String para armazenar dados de arquivos binários grandes. Planejamento e design insuficientes antes da entrada em produção. Membros dentro das chaves não são divididos adequadamente, resultando em um número excessivo de membros em algumas chaves. Falha na limpeza periódica de dados inválidos, causando aumento contínuo dos membros de chaves do tipo HASH. Falha de código no lado consumidor de uma aplicação que usa chaves do tipo LIST, fazendo com que os membros da chave correspondente apenas aumentem.
Chave quente	Aumentos abruptos e inesperados no volume de acesso. Exemplos incluem um product que viraliza repentinamente, uma notícia quente com tráfego disparado, um evento de streamer em canal ao vivo gerando muitos likes, ou uma batalha entre múltiplas guildas em um jogo envolvendo muitos jogadores em uma área específica.

Efeitos de chaves grandes e quentes

Categoria	Efeito
Chave grande	Torna lenta a execução de comandos no cliente. Quando a memória da instância atinge o limite de maxmemory, pode causar bloqueio de operações, evicção de chaves importantes ou até mesmo erro de falta de memória (OOM). Em arquitetura cluster, o uso de memória de um shard de dados excede muito o dos outros, impedindo o uso equilibrado dos recursos de memória entre os shards. A execução de requisições de leitura em uma chave grande pode saturar a largura de banda da rede da instância, desacelerando seus próprios services e afetando services relacionados. A exclusão de uma chave grande pode facilmente bloquear o banco de dados primário por um longo período, o que pode desencadear uma quebra de sincronização ou failover primário/secundário.
Chave quente	Consome grande quantidade de recursos de CPU e pode aumentar o uso da largura de banda da rede, afetando outras requisições e reduzindo o desempenho geral. Em arquitetura cluster, causa distorção de acesso, onde um shard de dados é intensamente acessado enquanto outros ficam ociosos. Isso pode levar a problemas como exaustão do limite de conexões desse shard e rejeição de novas requisições de conexão. Em cenários de flash sale, o volume de requisições para a chave de estoque de um product pode exceder a capacidade de processamento da instância, levando a vendas excessivas. Se a pressão de requisições em uma chave quente exceder a capacidade da instância, pode facilmente causar uma quebra de cache. Isso significa que muitas requisições são direcionadas à camada de armazenamento backend, causando um pico no acesso ao armazenamento ou até mesmo sua falha, afetando outros services.

Estratégias de prevenção

Estratégia	Descrição
Configure monitoring and alerts	Defina limiares de alerta razoáveis para métricas como uso de CPU, uso de memória e Connections. Por exemplo, configure um alerta para quando o uso de memória exceder 70% ou quando a memória crescer mais de 20% em uma hora. Quando um alerta for acionado, siga as instruções nas Etapas 1 e 2 deste tópico para localizar e otimizar chaves grandes e quentes. Isso resolve o problema antes que ele afete seus negócios.
Use o Tair (Enterprise Edition) para evitar a limpeza de dados inválidos	Para cenários envolvendo chaves grandes do tipo hash, o Tair (Enterprise Edition) fornece uma estrutura de dados aprimorada, TairHash. Ela suporta a definição de tempo de expiração e versão para cada campo. Usando o TairHash corretamente, reduza significativamente a carga operacional, simplifique a complexidade do código da aplicação e lide eficazmente com problemas causados por chaves grandes e quentes.