Almacenamiento de sesiones y patrones de tablas de clasificación

Las aplicaciones web tradicionales almacenan los datos de sesión en la memoria del servidor. Esto funciona con un solo servidor, pero deja de funcionar al escalar horizontalmente: si la siguiente solicitud de un usuario se enruta a otra instancia de EC2, esa instancia no conoce la sesión del usuario y este cierra su sesión. Las sesiones persistentes (afinidad de sesión en el balanceador de carga) resuelven el problema parcialmente, pero reducen la eficacia del balanceo de carga. La solución escalable consiste en trasladar el estado de sesión a un almacén compartido de baja latencia accesible para todas las instancias, que es precisamente lo que proporciona ElastiCache Redis.

Almacenar las sesiones en Redis ofrece: lecturas de sesión en menos de un milisegundo desde todos los servidores de aplicaciones, TTL integrado para la caducidad automática de las sesiones, actualizaciones atómicas de sesión para evitar condiciones de carrera y la posibilidad de invalidar inmediatamente una sesión eliminando la clave. La aplicación almacena el ID de sesión en una cookie; en cada solicitud, busca el ID de sesión en Redis para recuperar los datos de la sesión. Todos los servidores de aplicaciones comparten el mismo Redis, por lo que cualquier servidor puede gestionar la solicitud de cualquier usuario.

Un TTL fijo significa que la sesión caduca N segundos después de su creación, independientemente de la actividad. Un TTL deslizante (que amplía la caducidad con cada acceso) es más práctico para el usuario: la sesión caduca N segundos después del último acceso. En Redis, implemente un TTL deslizante llamando a EXPIRE (o EXPIREAT) sobre la clave de sesión después de cada lectura correcta de la sesión para reiniciar la cuenta atrás de caducidad. Así se asegura de que los usuarios activos no cierren su sesión inesperadamente, mientras que las sesiones inactivas caducan automáticamente y liberan memoria.

Un carrito de compra de comercio electrónico encaja perfectamente con Redis. Cada carrito se almacena como un Hash de Redis, donde el campo es el SKU del producto y el valor es la cantidad. Las operaciones de hash, como HINCRBY y HDEL, permiten realizar actualizaciones atómicas sin recuperar y volver a escribir todo el carrito. Combinado con un TTL (para hacer caducar los carritos abandonados después de 24 horas), Redis proporciona un almacén de carritos rápido y persistente sin la sobrecarga de utilizar una base de datos relacional para cada evento de adición al carrito.

Una tabla de posiciones en tiempo real es un caso de uso clásico de Redis habilitado por los conjuntos ordenados (ZSET). Cada entrada de jugador tiene una puntuación; el conjunto ordenado mantiene siempre los miembros en orden ascendente de puntuación. Las consultas de la tabla de posiciones (los N mejores jugadores, la posición de un jugador y los jugadores dentro de un rango de puntuaciones) tienen una complejidad de O(log n) u O(log n + m), por lo que son extremadamente rápidas incluso con millones de jugadores. Los conjuntos ordenados de Redis son la base de muchas funciones de clasificación en juegos, aplicaciones de fitness y redes sociales, sin necesidad de consultas complejas a la base de datos ni de recalcular la posición cada vez que se muestra una página.

Dos funciones habituales de las tablas de posiciones, además de «mostrar los 10 primeros», son mostrar la posición de un jugador y mostrar los jugadores cercanos a un jugador determinado. Ambas son triviales con los conjuntos ordenados de Redis. ZREVRANK devuelve la posición indexada desde 0 de un jugador en orden descendente de puntuación. Para mostrar 5 jugadores por encima y por debajo de un jugador, obtenga su posición y, a continuación, use ZREVRANGE desde la posición-5 hasta la posición+5. Esto proporciona una vista personalizada de la tabla de posiciones con solo dos comandos de Redis, sin necesidad de funciones de ventana SQL complejas.

La limitación de frecuencia (restringir cuántas solicitudes puede realizar un cliente en un intervalo de tiempo) es otro caso de uso de gran valor para Redis. El algoritmo de ventana deslizante utiliza un conjunto ordenado en el que cada miembro es la marca de tiempo de una solicitud. En cada solicitud: elimina los miembros anteriores al intervalo, cuenta los miembros restantes, rechaza la solicitud si el recuento supera el límite y añade la nueva marca de tiempo. Esto implementa una limitación de frecuencia precisa mediante una ventana deslizante con resolución de milisegundos, mucho más exacta que los contadores de ventana fija y sin la sobrecarga de una base de datos.

Los bloqueos distribuidos coordinan el acceso exclusivo a un recurso compartido entre varios servidores de aplicaciones. El comando SET key value NX EX ttl de Redis proporciona una adquisición atómica del bloqueo: establece la clave solo si no existe (NX = Not eXists) y configura un TTL para evitar interbloqueos si el proceso que posee el bloqueo se bloquea. Cuando finaliza la operación, el propietario elimina la clave. El algoritmo Redlock (que utiliza varios nodos de Redis para obtener un quórum) proporciona un bloqueo distribuido más sólido, aunque añade complejidad. Para la mayoría de los casos de uso, basta con un bloqueo en un único nodo de Redis.

Tanto ElastiCache Redis como DynamoDB pueden almacenar datos de sesión, pero presentan distintas ventajas y desventajas. ElastiCache Redis: latencia de microsegundos, almacenamiento en memoria (volátil si no se habilita la persistencia), modelo de datos más sencillo y requisito de VPC. DynamoDB: latencia de milisegundos de un solo dígito (DAX puede igualar a Redis), servicio completamente administrado sin clúster que mantener, durabilidad predeterminada, acceso global mediante Global Tables y arquitectura sin servidor con capacidad bajo demanda. Para el examen SAA-C03: si la pregunta hace hincapié en la latencia de microsegundos o en las operaciones complejas en memoria, elija Redis. Si hace hincapié en la durabilidad, la arquitectura sin servidor o la escala global, considere DynamoDB.

Redis tiene un tipo de datos geoespaciales integrado (comandos GEO) que almacena coordenadas de latitud y longitud y permite realizar consultas de proximidad. Mediante GEOADD, GEODIST y GEORADIUS (ahora GEOSEARCH en Redis 6.2), puede encontrar todas las ubicaciones dentro de un radio determinado desde un punto en un tiempo O(n + log n). Casos de uso: encontrar conductores cercanos (servicios de transporte compartido), encontrar restaurantes en un radio de 5 km y ordenar los resultados de búsqueda por distancia. Esto evita utilizar una base de datos geoespacial independiente y mantiene las consultas de ubicación a velocidades propias de la memoria.

Un HyperLogLog es una estructura de datos probabilística que estima el número de elementos únicos de un conjunto utilizando una cantidad fija de memoria (12 KB en Redis), independientemente del número de elementos únicos que se añadan. Proporciona un error estándar aproximado del 0,81 %. Use PFADD para añadir elementos y PFCOUNT para obtener la estimación. Es ideal para contar usuarios activos diarios únicos, visualizaciones de página únicas o direcciones IP únicas cuando no se necesitan recuentos exactos y la eficiencia de memoria es importante. Almacenar millones de identificadores de usuario únicos como un Set de Redis consumiría GB; HyperLogLog utiliza 12 KB.

En esta lección ha aprendido lo siguiente: el almacenamiento de sesiones en Redis permite el escalado horizontal sin estado al proporcionar a todas las instancias acceso al estado de sesión compartido con una latencia inferior a un milisegundo; los conjuntos ordenados de Redis permiten crear tablas de posiciones en tiempo real con consultas de posición O(log n); y los tipos de datos especializados de Redis (HyperLogLog para recuentos únicos, GEO para proximidad y bloqueos distribuidos) resuelven eficazmente problemas habituales de arquitectura. Con esto finaliza el curso de almacenamiento en caché con ElastiCache; a continuación exploraremos la alta disponibilidad y las arquitecturas tolerantes a fallos.