Armazenamento de sessões e padrões de classificação

As aplicações web tradicionais armazenam os dados da sessão na memória do servidor. Isso funciona com um único servidor, mas falha quando você faz o dimensionamento horizontal — se a solicitação seguinte de um usuário for direcionada para uma instância EC2 diferente, essa instância não terá conhecimento da sessão do usuário, que será desconectado. Sessões fixas (afinidade de sessão no balanceador de carga) resolvem parcialmente o problema, mas reduzem a eficácia do balanceamento de carga. A solução escalável é mover o estado da sessão para um armazenamento compartilhado e de baixa latência, acessível por todas as instâncias — exatamente o que o ElastiCache Redis oferece.

Armazenar sessões no Redis oferece: leituras de sessão em menos de um milissegundo em todos os servidores da aplicação, TTL integrado para expiração automática de sessões, atualizações atômicas de sessões para evitar condições de corrida e a possibilidade de invalidar imediatamente uma sessão excluindo a chave. A aplicação armazena o ID da sessão em um cookie; a cada solicitação, ela procura esse ID de sessão no Redis para recuperar os dados da sessão. Todos os servidores da aplicação compartilham o mesmo Redis, portanto qualquer servidor pode processar a solicitação de qualquer usuário.

Um TTL fixo significa que a sessão expira N segundos após a criação, independentemente da atividade. Um TTL deslizante (que estende a expiração a cada acesso) é mais conveniente para o usuário — a sessão expira N segundos após o último acesso. No Redis, implemente um TTL deslizante chamando EXPIRE (ou EXPIREAT) na chave da sessão a cada leitura bem-sucedida da sessão, para redefinir a contagem regressiva da expiração. Isso garante que usuários ativos nunca sejam desconectados inesperadamente, enquanto sessões inativas expiram automaticamente, liberando memória.

Um carrinho de compras de comércio eletrônico é naturalmente adequado ao Redis. Cada carrinho é armazenado como um Hash do Redis, no qual o campo é o SKU do produto e o valor é a quantidade. Operações de hash como HINCRBY e HDEL permitem atualizações atômicas sem recuperar e regravar o carrinho inteiro. Combinado com um TTL (para expirar carrinhos abandonados após 24 horas), o Redis fornece um armazenamento de carrinhos rápido e persistente, sem a sobrecarga de usar um banco de dados relacional para cada evento de adição ao carrinho.

Uma classificação em tempo real é um caso de uso clássico do Redis, possibilitado pelos conjuntos ordenados (ZSETs). Cada entrada de jogador tem uma pontuação; o conjunto ordenado mantém os membros sempre em ordem crescente de pontuação. As consultas da classificação (os N melhores jogadores, a posição de um jogador e os jogadores em um intervalo de pontuação) têm complexidade O(log n) ou O(log n + m) — são extremamente rápidas mesmo com milhões de jogadores. Os conjuntos ordenados do Redis são a base de muitos recursos de classificação em jogos, aplicativos de condicionamento físico e redes sociais, sem a necessidade de uma consulta complexa ao banco de dados ou de recalcular a posição a cada carregamento de página.

Dois recursos comuns de classificações, além de “mostrar os 10 melhores”, são mostrar a posição de um jogador e mostrar os jogadores próximos de um determinado jogador. Ambos são triviais com conjuntos ordenados do Redis. ZREVRANK retorna a posição, indexada a partir de 0, de um jogador na ordem decrescente de pontuação. Para mostrar 5 jogadores acima e abaixo de um jogador, obtenha a posição dele e use ZREVRANGE do intervalo rank-5 a rank+5. Isso fornece uma visualização personalizada da classificação usando dois comandos do Redis — sem a necessidade de funções complexas de janela do SQL.

A limitação de taxa (restringir quantas solicitações um cliente pode fazer em uma janela de tempo) é outro caso de uso de alto valor do Redis. O algoritmo de janela deslizante usa um conjunto ordenado no qual cada membro é o registro de data e hora de uma solicitação. A cada solicitação: remova os membros mais antigos que a janela, conte os membros restantes, rejeite a solicitação se a contagem exceder o limite e adicione o novo registro de data e hora. Isso implementa uma limitação de taxa precisa por janela deslizante, com resolução de milissegundos — muito mais precisa que os contadores de janela fixa e sem a sobrecarga de um banco de dados.

Os bloqueios distribuídos coordenam o acesso exclusivo a um recurso compartilhado entre vários servidores de aplicativos. O comando SET key value NX EX ttl do Redis fornece aquisição atômica do bloqueio: ele define a chave somente se ela não existir (NX = Not eXists) e define um TTL para evitar bloqueios permanentes caso o detentor falhe. Quando a operação é concluída, o detentor exclui a chave. O algoritmo Redlock (que usa vários nós do Redis para formar um quórum) fornece um bloqueio distribuído mais robusto, embora acrescente complexidade. Para a maioria dos casos de uso, um bloqueio em um único nó do Redis é suficiente.

Tanto o ElastiCache Redis quanto o DynamoDB podem armazenar dados de sessão, mas apresentam diferentes compromissos. ElastiCache Redis: latência de microssegundos, armazenamento em memória (volátil, a menos que a persistência esteja habilitada), modelo de dados mais simples e exige uma VPC. DynamoDB: latência de milissegundos de um único dígito (DAX pode igualar o Redis), totalmente gerenciado, sem cluster para manter, durável por padrão, acessível globalmente com Global Tables e sem servidor, com capacidade sob demanda. Para a prova SAA-C03: se a questão enfatizar latência de microssegundos ou operações complexas em memória, escolha o Redis. Se enfatizar durabilidade, sem servidor ou escala global, considere o DynamoDB.

O Redis tem um tipo de dados geoespaciais integrado (comandos GEO) que armazena coordenadas de latitude e longitude e permite consultas de proximidade. Com GEOADD, GEODIST e GEORADIUS (agora GEOSEARCH no Redis 6.2), você pode encontrar todos os locais dentro de um determinado raio de um ponto em O(n + log n). Casos de uso: encontrar motoristas próximos (transporte por aplicativo), encontrar restaurantes em um raio de 5 km e ordenar resultados de pesquisa por distância. Isso elimina a necessidade de um banco de dados geoespacial separado e mantém as consultas de localização em velocidades de memória.

Um HyperLogLog é uma estrutura de dados probabilística que estima a contagem de elementos únicos em um conjunto usando uma quantidade fixa de memória (12 KB no Redis), independentemente de quantos itens únicos sejam adicionados. Ele oferece um erro padrão aproximado de 0,81%. Use PFADD para adicionar elementos e PFCOUNT para obter a estimativa. Isso é perfeito para contar usuários ativos únicos por dia, visualizações únicas de páginas ou endereços IP únicos quando não são necessárias contagens exatas e a eficiência de memória é importante. Armazenar milhões de IDs de usuários únicos como um Set do Redis consumiria GBs; o HyperLogLog usa 12 KB.

Nesta lição, você aprendeu que: o armazenamento de sessões no Redis permite a escalabilidade horizontal sem estado, dando a todas as instâncias acesso ao estado compartilhado da sessão com latência inferior a um milissegundo; os conjuntos ordenados do Redis viabilizam classificações em tempo real com consultas de posição O(log n); e os tipos de dados especializados do Redis (HyperLogLog para contagens únicas, GEO para proximidade e bloqueios distribuídos) resolvem problemas comuns de arquitetura com eficiência. Com isso, concluímos o curso de Caching com ElastiCache — a seguir, exploraremos Alta Disponibilidade e Arquiteturas Tolerantes a Falhas.