Redis versus Memcached: Escolha do mecanismo adequado

O Amazon ElastiCache é um serviço de armazenamento em cache em memória totalmente gerenciado que facilita a implantação, o gerenciamento e a expansão de armazenamentos de dados em memória de código aberto populares na nuvem. Ele é compatível com dois mecanismos: Redis e Memcached. Ao fornecer dados solicitados com frequência diretamente da memória, em vez de buscá-los em um banco de dados, o ElastiCache pode reduzir a carga do banco de dados em várias ordens de grandeza e diminuir a latência de resposta de milissegundos para microssegundos. Escolher entre Redis e Memcached é uma pergunta comum no exame SAA-C03.

O Memcached é um armazenamento distribuído de chave-valor em memória, voltado para a simplicidade e a escalabilidade horizontal. Características principais: multithread (pode usar todos os núcleos de CPU em um único nó), armazenamento simples de chave-valor (somente strings, sem estruturas de dados complexas), sem persistência (os dados são perdidos quando um nó é reiniciado), sem replicação (sem nó de espera ou réplicas) e fragmentação horizontal por meio de hashing consistente no lado do cliente. O Memcached é a escolha certa quando você precisa de um cache simples e de grande escala e não precisa de persistência, tipos de dados complexos ou alta disponibilidade.

O Redis (Remote Dictionary Server) é um armazenamento de estruturas de dados em memória, rico em recursos e de thread único (por instância), compatível com strings, hashes, listas, conjuntos, conjuntos ordenados, bitmaps, HyperLogLogs, fluxos e índices geoespaciais. Vantagens principais em relação ao Memcached: persistência opcional (instantâneos AOF e RDB), replicação (réplicas de leitura e failover automático), mensagens pub/sub, scripts Lua, transações (MULTI/EXEC) e modo de cluster para fragmentação horizontal. O Redis é a escolha certa para a maioria dos cenários reais de armazenamento em cache.

O Redis é compatível com dois mecanismos de persistência: RDB (Redis Database) — instantâneos periódicos de um ponto no tempo, salvos em disco em intervalos configuráveis (reinicializações rápidas, mas os dados entre os instantâneos podem ser perdidos). AOF (Append-Only File) — registra todas as operações de gravação; durante a reinicialização, o Redis reproduz o registro para reconstruir o estado (durabilidade ao custo de arquivos maiores e reinicializações mais lentas). No ElastiCache, você pode ativar o AOF para manter os dados entre reinicializações de nós. Isso é fundamental quando o ElastiCache é usado não apenas como cache, mas também como armazenamento de dados principal, por exemplo, para dados de sessão.

O Redis é compatível com grupos de replicação com um nó primário que processa todas as gravações e até 5 réplicas de leitura que processam as leituras. Com Multi-AZ e failover automático ativados, o ElastiCache promove automaticamente uma réplica de leitura a primária quando a primária falha — normalmente concluindo o failover em menos de 60 segundos. Isso proporciona alta disponibilidade às aplicações baseadas em Redis, algo que o Memcached não consegue igualar (o Memcached não tem replicação). Para aplicações de Production que exigem armazenamento em cache com HA, use sempre o Redis com failover automático.

Os conjuntos ordenados são uma das estruturas de dados mais poderosas do Redis. Cada membro tem uma pontuação de ponto flutuante associada, e os membros são sempre mantidos em ordem. Isso torna os conjuntos ordenados ideais para Leaderboards (classificação por pontuação), filas de prioridade (processamento primeiro das tarefas de maior prioridade) e limitação de taxa (janela deslizante com marcações de tempo como pontuações). As operações ZADD, ZRANGE, ZREVRANGE, ZRANK e ZRANGEBYSCORE são todas O(log n) — extremamente eficientes até mesmo para milhões de entradas.

O pub/sub do Redis permite que os publicadores transmitam mensagens para canais sem saber quem está inscrito. Os assinantes recebem, em tempo real, todas as mensagens publicadas nos canais aos quais se inscreveram. As mensagens de pub/sub não são persistentes — se um assinante estiver offline, ele perderá a mensagem. Para mensagens persistentes com entrega garantida, use os fluxos do Redis (uma estrutura de dados mais robusta adicionada no Redis 5) ou um serviço de mensagens específico, como SQS ou SNS. No exame SAA-C03, o pub/sub do Redis é uma opção para notificações leves em tempo real entre serviços.

Use esta estrutura para escolher no exame SAA-C03: escolha o Memcached quando precisar de: cache simples sem requisito de HA, desempenho multithread e escalabilidade horizontal por meio da adição de nós (cache puro). Escolha o Redis quando precisar de: persistência (armazenamento de sessões), replicação e failover (HA), tipos de dados complexos (conjuntos ordenados para Leaderboards, conjuntos e listas), pub/sub, transações Lua ou Cluster Mode para escalabilidade horizontal com vários fragmentos. Se a pergunta do exame mencionar qualquer recurso além do armazenamento em cache simples de chave-valor, quase sempre a resposta será Redis.

O ElastiCache oferece várias famílias de tipos de nós: r7g (Graviton 3, otimizado para memória — melhor relação entre preço e desempenho, recomendado para a maioria dos caches), m7g (computação e memória equilibradas) e t4g (expansão temporária, baixo custo para desenvolvimento e testes). Os tamanhos dos nós variam de cache.t4g.micro (500 MB) a cache.r7g.16xlarge (425 GB). Para Production, escolha um tamanho de nó que mantenha seu conjunto de dados na memória com uma margem de 20% a 25%. Ficar sem memória causa remoções (Memcached) ou erros de OOM (Redis).

O ElastiCache é implantado dentro da sua VPC, com grupos de segurança controlando o acesso — por padrão, não há acesso à Internet pública. Para o Redis, ative tokens AUTH (uma senha que os clientes devem fornecer) e criptografia em trânsito (TLS) para as conexões, além da criptografia em repouso usando KMS. Para o Memcached, somente TLS em trânsito está disponível (sem criptografia em repouso ou AUTH). Ao migrar de um Redis não criptografado para um criptografado, não há migração no local — você deve criar um novo cluster criptografado e aquecê-lo.

Quando um cache Redis ou Memcached está cheio, a política de remoção determina quais chaves serão removidas para liberar espaço. Políticas comuns de remoção do Redis: noeviction (retorna um erro de OOM — adequado quando o cache é o armazenamento principal), allkeys-lru (remove as chaves usadas menos recentemente entre todas as chaves — adequado para um cache geral), volatile-lru (aplica LRU às chaves com TTL definido — preserva as chaves sem expiração), allkeys-random (remoção aleatória) e allkeys-lfu (remove as chaves usadas com menor frequência). Para casos de uso comuns de armazenamento em cache, recomenda-se allkeys-lru ou allkeys-lfu.

Nesta lição, você aprendeu que o Memcached é simples, multithread e não tem HA — ideal para a escalabilidade horizontal pura de caches simples; o Redis é compatível com estruturas de dados complexas, persistência, pub/sub e failover Multi-AZ — ideal para a maioria dos cenários de armazenamento em cache de Production; e os conjuntos ordenados tornam o Redis a escolha natural para Leaderboards e filas de prioridade. A seguir, exploraremos os grupos de replicação do Redis e o Cluster Mode para a fragmentação horizontal.