Redis del lado del cliente almacenado en caché

Redis del lado del cliente almacenado en caché
Las aplicaciones web modernas funcionan con grandes cantidades de datos que se almacenan en bases de datos de back-end. Entonces, esas aplicaciones web que funcionan con datos deben optimizarse cuidadosamente para el rendimiento. Cada solicitud realizada sobre una red a una base de datos es costosa. Por otro lado, afecta directamente el rendimiento de una aplicación web.

El almacenamiento en caché del lado del cliente permite el almacenamiento de datos a los que se accede con frecuencia al final del navegador o en la memoria del servidor de aplicaciones. Consume almacenamiento del lado del cliente hasta cierto punto, pero la ganancia de rendimiento es alta. Por lo general, cuando se requieren los datos, el cliente envía una solicitud al extremo posterior a los datos de consulta. La mayoría de las veces, los clientes web recuperan el mismo conjunto de datos una y otra vez de la base de datos. Con el almacenamiento en caché del lado del cliente habilitado, los datos recuperados a través de consultas populares se almacenan en el lado del cliente.

El almacenamiento en caché del lado del cliente tiene dos beneficios principales:

  • Mejora el rendimiento por una cantidad considerable.
  • Reduce la base de datos y las cargas de red.

Al mismo tiempo, el almacenamiento en caché del lado del cliente enfrenta el desafío de mantener los datos al día. Si los datos se cambian en el extremo de la base de datos, esa pieza de datos en el caché del cliente se vuelve desactualizado y el cliente debe notificarse de inmediato para obtener la pieza actualizada. Redis ha implementado su modelo de almacenamiento en caché abordando estos problemas.

Configure el almacenamiento en caché del lado del cliente con Redis

En Redis, se nombra el almacenamiento en caché del lado del cliente seguimiento. Hay dos modos de seguimiento compatibles con Redis. El modo predeterminado se llama seguimiento asistido por servidor, donde el servidor envía notificaciones de invalidación que están relacionadas solo con las claves que están en el caché del cliente. Por otro lado, el modo de transmisión proporciona libertad a los clientes para suscribirse a los prefijos de clave preferidos y recibir notificaciones cada vez que se modifica una clave con el prefijo suscrito.

Seguimiento asistido por servidor para clientes Redis

Como su nombre indica, en el modo asistido por servidor, el servidor realiza un seguimiento de las claves a las que está accediendo un cliente específico. Cada vez que se altere una clave rastreada en la base de datos, el cliente será notificado inmediatamente. Lo más importante es que las notificaciones de invalidación se generan solo para las claves que están en un caché de cliente determinado. El único inconveniente de este modo es que explota la memoria del servidor para recordar las claves accedidas por cada cliente.

Cliente dedicado para notificaciones de invalidación

Por lo general, el almacenamiento en caché del lado del cliente asistido por servidor se implementa utilizando un cliente dedicado que recibe notificaciones de invalidación. Este cliente es el punto central que recibe todos los mensajes de invalidación para todos los clientes conectados a una base de datos dada.

Configurar un cliente dedicado para recibir mensajes de invalidación. Primero, debemos conectarnos a nuestro servidor Redis como cliente autorizado y obtener la ID del cliente de la siguiente manera.

Identificación del cliente

El comando anterior devuelve la ID de la conexión del cliente actual, que es 3. Esta identificación es necesaria en los próximos pasos para identificarlo como el cliente central para recibir los mensajes de invalidación. A continuación, nos suscribimos al canal de notificación de invalidación de la siguiente manera. El comando de suscripción se puede usar.

Suscribir canal [canal ...]

En este ejemplo, el canal es __redis __: invalidar.

Suscríbete __redis __: invalidar

Ahora hemos configurado la conexión del cliente para recibir las notificaciones de invalidación. Iniciemos otra conexión del cliente y encendamos el seguimiento del cliente. Además, redirigimos todos los mensajes de invalidación asociados con el nuevo cliente al cliente central creado en el paso anterior. Podemos usar el comando de seguimiento del cliente para lograr esto. La siguiente es la sintaxis del comando de seguimiento del cliente.

Seguimiento del cliente [Redirect Client-ID] [prefijo prefijo [prefijo prefijo ...]] [bcast] [optin] [optout] [noloop]

En | APAGADO : Determinar si el seguimiento del cliente debe estar habilitado o no.

Redirección: Especifique la identificación del cliente que recibe mensajes de invalidación.

Habilitemos el seguimiento del cliente para un nuevo cliente autorizado y usemos la opción de redirección para especificar la conexión que recibe la invalidación, mensajes que es 3.

Seguimiento del cliente en Redirect 3

Ahora estamos listos para probar nuestro seguimiento de clientes de Redis. Primero, establecemos un par de valores clave de la siguiente manera.

Establecer el nombre de usuario "User_01"

A continuación, accedemos al nombre de usuario desde el mismo cliente, que almacenará en caché esa información en el lado del cliente, ya que hemos habilitado el seguimiento del cliente.

Obtener nombre de usuario

Abra un nuevo cliente y cambiemos el valor almacenado en la clave nombre de usuario como sigue.

Establecer el nombre de usuario "user_2"

Inmediatamente, el cliente que se ha suscrito al canal Invalidate recibe notificación que el valor almacenado en la clave nombre de usuario ha sido modificado y ya no es válido.

Este modelo se basa en el protocolo Resp2, que es el protocolo predeterminado que usan los clientes Redis.

Protocolo Resp3 para recibir notificaciones al cliente de seguimiento

De la versión 6.0, Redis presenta el protocolo Resp3, que permite a un cliente activo recibir mensajes de invalidación. Esta es una gran ventaja en la que un cliente de Redis puede escuchar un canal dado mientras se emite comandos.

Vamos a ver primero la versión de Redis. Debe ser la versión 6.0 o el último en usar el protocolo Res3. El siguiente comando se puede emitir para verificar la versión Redis.

Redis-Cli-Versión

Ya que es la versión 7.0, todos somos buenos para usar el protocolo Resp3. Los clientes de Redis usan Resp2 por defecto. Entonces, necesitamos cambiar al protocolo Resp3.

hola 3

Esto cambiaría el protocolo a Resp3 con la siguiente salida.

Habilitemos el seguimiento del cliente como en el ejemplo anterior utilizando el comando de seguimiento del cliente. En este caso, no necesitamos especificar la opción de redirección.

seguimiento del cliente en

Ahora las claves que este cliente obtendrá el servidor rastrear. Además, cuando cambia el valor de una clave rastreada, se enviará un mensaje de invalidación a los clientes que almacenaron en caché esa clave en particular.

Vamos a buscar la llave nombre de usuario.

Obtener nombre de usuario

El cliente almacena en caché el nombre de usuario clave y su valor asociado. Ahora, iniciamos otra conexión del cliente y cambiamos el valor almacenado en la clave nombre de usuario.

Si verifica la conexión del cliente anterior, aún no se recibe un mensaje de invalidación. Si emite otro comando, la notificación de invalidación se mostrará inmediatamente de la siguiente manera.

2. Modo de transmisión para el seguimiento del cliente

En el modo predeterminado, los clientes reciben notificaciones de invalidación solo para las claves que han obtenido en llamadas de comando anteriores. Con el modo de transmisión habilitado, los clientes se suscriben a un prefijo de clave específico y el cliente recibe notificaciones de invalidación para cada clave que se cambia cuya clave comienza con el prefijo suscrito.

Usemos una nueva conexión de cliente para recibir los mensajes de invalidación suscribiéndose al canal Invalidate de la siguiente manera.

En este ejemplo, la ID de conexión del cliente es 10, que se utilizará con la opción de redirección para un nuevo cliente. Vamos a especificar la opción Bcast en el comando de seguimiento del cliente de la siguiente manera.

Seguimiento del cliente en Bcast Prefijo Usuario: Redirección 10

Suponga que tenemos una clave llamada Usuario: ID: 1 en la instancia de Redis. Obtenámoslo de este cliente.

Ahora el usuario: ID: 1 La tecla se almacena en caché en el lado del cliente.

Creemos una nueva conexión de cliente y establezcamos una nueva clave de la siguiente manera: Usuario: ID: 3.

En este momento, el cliente que habilitó el seguimiento recibe un mensaje de invalidación, y será redirigido al cliente que está identificado por la ID 10. Esto sucede porque la nueva clave contiene el prefijo usuario: que es el prefijo suscrito por el cliente habilitado para el seguimiento. Como puede ver, el servidor no realiza un seguimiento de ninguna de las claves que cada cliente obtiene, pero transmite mensajes de invalidación si el prefijo de clave cambiado coincide con el prefijo suscrito por cada cliente.

Opciones optinas y optadas

Las opciones Optin y Optout se pueden usar para filtrar qué teclas el servidor debe rastrear exactamente o no. Con estas opciones habilitadas en el comando de seguimiento del cliente, Redis solo realiza un seguimiento de las teclas que son consultas justo después del comando de caché del cliente sí. Esto minimiza el uso de la memoria del lado del servidor y se carga drásticamente.

Conclusión

En resumen, el almacenamiento en caché del lado del cliente es una de las técnicas ampliamente utilizadas para mejorar el rendimiento de las aplicaciones web que frecuentemente solicitan datos de bases de datos de fondo. Como se discutió, el navegador o el servidor de aplicaciones del lado del cliente pueden contener los datos relacionados con consultas populares emitidas por el cliente. Como se menciona en la introducción, en Redis, el almacenamiento en caché del lado del cliente se llama seguimiento. Además, los dos modos de seguimiento están disponibles en Redis. Tanto el cliente dedicado como los modos de transmisión tienen sus propios casos de uso.