Top 5 Gargalos de Desempenho no Redis e Como Corrigi-los

Os problemas de desempenho do Redis geralmente parecem misteriosos até que você se lembre de uma coisa: o Redis é rápido, mas não está isento de trabalho. Um comando que percorre um milhão de chaves ainda percorre um milhão de chaves. Um cliente que envia um comando por viagem de ida e volta na rede ainda paga por cada viagem. Um servidor que fica sem memória ainda precisa despejar, trocar, rejeitar gravações ou cair, dependendo da configuração.

Quando o Redis fica lento, não comece alterando configurações aleatórias. Comece com evidências:

redis-cli INFO
redis-cli SLOWLOG GET 20
redis-cli LATENCY DOCTOR
redis-cli INFO commandstats
redis-cli INFO memory

Esses comandos geralmente apontam para um dos cinco gargalos: comandos lentos, viagens de ida e volta na rede, pressão de memória, sobrecarga de persistência ou saturação da CPU.

1. Comandos lentos em grandes dados

O Redis tem muitas operações minúsculas de tempo constante, mas nem todo comando é minúsculo. Comandos como KEYS, LRANGE grande, SMEMBERS, HGETALL, ZRANGE em grandes intervalos, SORT e scripts Lua longos podem bloquear outros clientes enquanto são executados.

O incidente clássico começa com um comando de limpeza ou depuração:

KEYS *

Em uma pequena instância de desenvolvimento, ele retorna imediatamente. Em um espaço de chaves de produção com milhões de chaves, pode travar o servidor por tempo suficiente para que as solicitações do aplicativo se acumulem. O mesmo padrão acontece com um hash que começou como "alguns campos por usuário" e silenciosamente se tornou um objeto gigante.

Encontre a evidência:

redis-cli SLOWLOG GET 20
redis-cli INFO commandstats
redis-cli LATENCY LATEST

SLOWLOG registra comandos que excederam o limite configurado. INFO commandstats mostra contagens de chamadas por comando e tempo cumulativo. Se um comando domina o tempo, comece por aí.

Corrija o padrão de acesso:

redis-cli --scan --pattern 'user:*'

Use SCAN em vez de KEYS para iteração no espaço de chaves. Use HSCAN, SSCAN e ZSCAN para hashes, conjuntos e conjuntos ordenados grandes. Busque páginas ou intervalos em vez de estruturas inteiras:

LRANGE feed:user:42 0 49
ZRANGE leaderboard 0 99 WITHSCORES

Se um objeto cresceu demais, divida-o com base em como o aplicativo o lê. Um único hash user:42 com milhares de campos não relacionados pode ser conveniente para gravações, mas doloroso para leituras que precisam apenas de configurações de perfil. Chaves separadas como user:42:profile, user:42:prefs e user:42:counters podem reduzir a quantidade de dados tocados por solicitação.

Para exclusão, prefira UNLINK quando os valores podem ser grandes:

UNLINK old:large:set

UNLINK remove a chave do espaço de chaves e libera memória de forma assíncrona. É mais seguro que DEL para valores grandes, embora a limpeza em massa ainda precise de limitação.

2. Muitas viagens de ida e volta na rede

O Redis pode processar um comando em microssegundos enquanto seu aplicativo gasta milissegundos esperando na rede. Se um caminho de solicitação envia 50 comandos Redis sequenciais, a rede pode dominar o tempo total, mesmo quando o Redis está saudável.

Isso é comum em código como:

for user_id in user_ids:
    profile = redis.get(f"user:{user_id}:profile")

Cada GET espera sua própria resposta antes que o próximo comece. Através de uma rede, isso é caro.

Use pipelining:

pipe = redis.pipeline(transaction=False)
for user_id in user_ids:
    pipe.get(f"user:{user_id}:profile")
profiles = pipe.execute()

O pipelining envia vários comandos sem esperar por cada resposta individualmente. O Redis ainda executa comandos em ordem, mas o cliente evita pagar uma viagem de ida e volta para cada comando.

Use comandos de várias chaves onde eles se encaixam:

MGET user:1:profile user:2:profile user:3:profile

Não transforme cada solicitação em um pipeline enorme. Pipelines grandes podem aumentar o uso de memória e criar rajadas de resposta. Agrupe o suficiente para remover o desperdício óbvio de viagens de ida e volta e, em seguida, meça.

Para caminhos com muita leitura, verifique também se seu aplicativo pergunta repetidamente ao Redis por valores que poderiam ser buscados uma vez e reutilizados durante a duração de uma solicitação. Um pequeno cache de solicitação local pode remover leituras duplicadas acidentais sem alterar o Redis.

3. Pressão de memória e rotatividade de despejo

O Redis é centrado em memória. Quando a memória fica escassa, o desempenho piora de várias maneiras: o despejo custa CPU, as gravações podem falhar sob noeviction, os forks de persistência podem se tornar mais difíceis, as réplicas podem ficar para trás e o sistema operacional pode trocar se o host estiver mal configurado ou sobrecarregado.

Verifique a memória:

redis-cli INFO memory
redis-cli INFO stats | grep evicted_keys
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Sinais importantes:

• used_memory está próximo de maxmemory.
• evicted_keys está aumentando rapidamente.
• O host está trocando.
• Chaves grandes consomem mais memória do que o esperado.
• Chaves de cache expiradas não têm TTLs.

Encontre chaves grandes com cuidado. Não execute comandos amplos e caros durante o tráfego de pico. A amostragem com --bigkeys pode ajudar:

redis-cli --bigkeys

Para caches, defina um limite de memória e uma política de despejo que corresponda aos dados:

maxmemory 4gb
maxmemory-policy allkeys-lru

allkeys-lru ou allkeys-lfu podem fazer sentido quando todas as chaves são entradas de cache. volatile-lru apenas despeja chaves com TTLs, o que é útil quando chaves persistentes compartilham a instância com chaves de cache. noeviction geralmente é correto para Redis usado como armazenamento de dados primário, porque despejar silenciosamente dados de aparência durável seria pior do que retornar um erro.

Defina TTLs no momento da gravação:

SET cache:product:123 "$json" EX 300

Para armazenamentos de sessão, seja deliberado. Uma chave de sessão sem expiração geralmente é um bug. Para limitadores de taxa, os contadores devem expirar com a janela. Para Streams, corte entradas antigas. Vazamentos de memória no Redis geralmente são dados de aplicativo que nunca receberam um ciclo de vida.

Reduza também a sobrecarga de chave e valor onde isso importa. Milhares de chaves minúsculas podem custar mais metadados do que o esperado. Às vezes, um hash compacto é melhor do que muitas chaves individuais; às vezes, o oposto é verdadeiro porque as leituras precisam apenas de um campo. Meça com padrões de acesso reais em vez de assumir que uma forma é sempre a melhor.

4. Persistência e paradas de E/S de disco

A persistência protege os dados, mas introduz comportamento de disco e fork que você precisa entender. Snapshots RDB e reescritas AOF são normalmente operações em segundo plano, mas ainda podem causar latência através do tempo de fork, pressão de memória copy-on-write e E/S de disco.

Verifique o estado da persistência:

redis-cli INFO persistence
redis-cli LATENCY LATEST
iostat -xz 1

Procure por salvamentos em segundo plano com falha, tempos de fork longos, atividade de reescrita AOF e saturação de disco. Se os picos de latência coincidirem com BGSAVE ou BGREWRITEAOF, o ajuste de persistência pertence à lista de prioridades.

Para AOF, a principal configuração de durabilidade/desempenho é:

appendfsync everysec

everysec é a escolha equilibrada usual. always sincroniza toda gravação e pode ser muito lento. no deixa a sincronização para o sistema operacional e aceita mais risco de perda de dados em caso de falha.

Para RDB, evite regras de snapshot que disparam constantemente em uma carga de trabalho de gravação intensa, a menos que isso seja intencional:

save 900 1
save 300 10
save 60 10000

Esses padrões de exemplo não estão automaticamente corretos para toda carga de trabalho. Um Redis de alta gravação usado como cache descartável pode não precisar de persistência. Uma instância Redis usada como fila de trabalho ou armazenamento de sessão provavelmente precisa, mas a janela de perda aceitável deve ser clara.

Se a persistência competir com o tráfego do aplicativo, considere:

• Armazenamento SSD local mais rápido.
• Separar a persistência do Redis de outros serviços pesados de disco.
• Executar a persistência em uma réplica quando o primário puder tolerar esse design.
• Manter o tamanho do conjunto de dados abaixo do que o host pode bifurcar confortavelmente.
• Definir vm.overcommit_memory=1 do Linux onde o Redis recomenda para salvamentos em segundo plano.

Não desabilite a persistência cegamente para "corrigir o desempenho" a menos que os dados sejam verdadeiramente descartáveis. Isso pode fazer o gráfico parecer melhor enquanto transforma uma reinicialização em perda de dados.

5. Saturação da CPU e execução de comando de thread única

A execução de comandos do Redis é amplamente de thread única, embora o Redis moderno use threads adicionais para algumas E/S e trabalho em segundo plano. Se um núcleo estiver ocupado pelo Redis, adicionar mais núcleos ociosos na mesma instância pode não ajudar o caminho de comando quente.

Verifique o host e a mistura de comandos Redis:

top -H -p $(pgrep redis-server)
redis-cli INFO commandstats
redis-cli SLOWLOG GET 20
redis-cli INFO clients

Causas comuns de CPU:

• Operações grandes de conjunto, conjunto ordenado, lista ou hash.
• Scripts Lua pesados.
• Sobrecarga de compressão ou serialização no aplicativo causando valores maiores do que o esperado.
• Fan-out Pub/Sub muito alto.
• Despejo caro sob pressão de memória.
• Muitas conexões constantemente reconectando ou emitindo comandos pequenos.

Corrija a CPU reduzindo o trabalho, dividindo o trabalho ou distribuindo o trabalho.

Reduza o trabalho alterando comandos e formas de dados. Se você precisa apenas de 50 itens, não busque 5.000. Se toda solicitação analisa um blob JSON de 500 KB para ler um sinalizador, divida esse sinalizador em uma chave ou campo menor.

Divida o trabalho movendo loops longos para clientes usando varreduras incrementais:

HSCAN big:hash 0 COUNT 100

Distribua o trabalho com réplicas para leituras ou Redis Cluster para fragmentação. As réplicas ajudam o tráfego pesado de leitura, mas não tornam as gravações mais baratas no primário. O Redis Cluster distribui chaves entre primários, o que pode aumentar a capacidade total de CPU e memória, mas também adiciona complexidade operacional e restrições de slot de chave.

Para Pub/Sub, observe os buffers de saída e o fan-out:

redis-cli PUBSUB NUMSUB events:updates
redis-cli CLIENT LIST

Um assinante lento pode se transformar em pressão de memória. Milhares de assinantes podem transformar uma publicação em uma grande quantidade de saída de rede. Se o Pub/Sub for pesado, considere isolá-lo em uma instância Redis separada.

Um fluxo de trabalho de triagem rápido

Quando a latência do Redis aumenta, execute estas verificações em ordem:

redis-cli --latency
redis-cli SLOWLOG GET 10
redis-cli LATENCY DOCTOR
redis-cli INFO memory
redis-cli INFO clients
redis-cli INFO persistence
redis-cli INFO commandstats

Em seguida, pergunte:

• Um comando lento apareceu?
• A memória atingiu maxmemory ou começou a despejar?
• A persistência iniciou um salvamento ou reescrita?
• Os clientes conectados ou bloqueados aumentaram?
• A contagem de chamadas ou o tempo de um comando explodiu?
• As implantações do aplicativo alteraram os padrões de acesso ao Redis?

A maioria dos gargalos do Redis não é resolvida por uma configuração mágica. Eles são resolvidos tornando a carga de trabalho menor, mais incremental, mais em lote ou melhor isolada. As melhores implantações Redis são chatas: as chaves expiram quando deveriam, as operações grandes são paginadas, os clientes usam pipelining com sabedoria, as configurações de persistência correspondem ao valor dos dados e o monitoramento captura a tendência antes que os usuários a sintam.

O que medir antes e depois de uma correção

Uma correção de desempenho só é real se o gráfico mudar para a carga de trabalho que importa. Antes de alterar o código ou a configuração, capture uma pequena linha de base:

redis-cli INFO stats
redis-cli INFO commandstats
redis-cli INFO memory
redis-cli INFO persistence
redis-cli SLOWLOG GET 20

No nível do sistema, capture CPU, disco, memória, troca e throughput de rede. Se o Redis for executado em um contêiner, verifique os limites do contêiner e a pressão do host. Um processo Redis pode parecer bom dentro de sua própria visão de memória enquanto o host está sob pressão de disco ou CPU de outro serviço.

Após a alteração, compare:

• Latência do aplicativo p50, p95 e p99 para solicitações apoiadas pelo Redis.
• Latência do comando Redis, não apenas latência da solicitação.
• Entradas de slowlog por comando.
• Taxa de despejo e margem de memória.
• Clientes conectados e conexões rejeitadas.
• Tempo de fork de persistência e status AOF/RDB.
• Atraso da réplica se as réplicas servirem leituras ou protegerem a durabilidade.

Desconfie de correções que apenas movem a dor. Por exemplo, um pipeline grande pode reduzir a latência da solicitação, mas aumentar os picos de memória. Desabilitar o AOF pode remover a latência do disco, mas enfraquecer a recuperação. Aumentar maxmemory pode atrasar os despejos, mas privar o host se a máquina já estava compartilhada.

Uma prática útil é escrever um pequeno teste de carga em torno do padrão Redis exato que você alterou. Se o código antigo fazia 40 GETs sequenciais, teste GETs sequenciais versus MGET ou pipelining com tamanhos de payload realistas. Se o código antigo usava HGETALL, teste HGET para os campos realmente necessários pela solicitação. O ajuste do Redis é muito mais fácil quando você compara a forma que realmente executa, não um número genérico de "operações Redis por segundo".

Finalmente, mantenha o rollback simples. Uma alteração de desempenho do Redis geralmente reside no código do aplicativo, nas configurações do cliente e na configuração do servidor ao mesmo tempo. Altere uma coisa quando puder. Se precisar alterar várias coisas, anote qual sintoma cada alteração deve melhorar. Isso impede que o próximo engenheiro herde uma pilha de configurações misteriosas que ninguém quer remover.