HCL Cachecon Redis

Cuando el almacenamiento en memoria caché remota está habilitado, HCL Cache utiliza un servidor Redis para almacenar datos de memoria caché y los metadatos necesarios, como los ID de dependencia. Si utiliza Redis, Kafka no es necesario para la invalidación de memoria caché.

En este tema se describe la implementación general de Redis en HCL Commerce y se incluyen algunas recomendaciones cuando se utiliza HCL Cache en un entorno de Kubernetes de producción.

Visión general de Redis

Las memorias caché individuales están enlazadas a un solo nodo Redis. Esto permite realizar muchas operaciones de memoria caché con una sola llamada de red utilizando scripts de LUA. Los datos y metadatos de una memoria caché están prefijados con el nombre de la memoria caché, que es una etiqueta hash. Por ejemplo: {cache-services/cache/WCStoreDistributedMapCache}-.

HCL Cache las entradas se implementan como HashMaps de Redis y contienen el valor de clave y la información de metadatos como, por ejemplo, dependencias, tiempo de caducidad, tiempo de creación de entrada y el pod desde el que se originó la entrada. Se establece un valor de tiempo de vida (TTL) de Redis para que coincida con las configuraciones de tiempos de espera. Los tiempos de espera de inactividad no están soportados por la memoria caché remota.

La información de dependencia se almacena en conjuntos de Redis que se actualizan a medida que se crean o invalidan entradas. Si las claves de memoria caché se eliminan debido al TTL o a la expulsión utilizada menos recientemente, el conjunto no se actualiza y puede hacer referencia durante un tiempo a entradas invalidadas. Este es el comportamiento normal.

Una invalidación mediante ID de dependencia o una operación de borrado de memoria caché restablece las listas de dependencia.

Si Redis necesita expulsar las claves utilizadas menos recientemente debido a la falta de espacio, los conjuntos de dependencia no se deben expulsar nunca cuando haya entradas en la memoria caché. Esto se logra asegurándose de que todas las entradas de memoria caché tienen un tiempo de espera establecido, mientras que los conjuntos de dependencia no lo tienen. Redis debe configurarse con un valor de LRU volatile-*. Consulte Utilización de Redis como memoria caché de LRU en la documentación de Redis para obtener más información.

Cuando una memoria caché habilita el almacenamiento en memoria caché local, las operaciones remotas publican mensajes de invalidación para reflejar los cambios que son necesarios en las memorias caché locales. Los mensajes de invalidación se propagan utilizando canales Redis, con nombres que incluyen los nombres de memoria caché. Por ejemplo, {cache-baseCache}-invalidation.

Consideraciones de alta disponibilidad

Los entornos de producción deben utilizar configuraciones de alta disponibilidad de la base de datos de Redis. Utilice topologías que ofrezcan redundancia como clúster, o maestro/minion con réplicas. El cliente de Redis de Redisson que utiliza HCL Cache da soporte a las topologías más populares.

Cuando una HCL Cache está habilitada con las interfaces locales y remotas, la memoria caché local puede proporcionar disponibilidad si la memoria caché de Redis remota deja de estar disponible. La memoria caché de HCL incluye una configuración de interruptor de circuito que se puede utilizar para configurar cómo se comportará la memoria caché cuando se produzcan errores de Redis.

Con la configuración predeterminada, una memoria caché se establece en modalidad de interrupción después de experimentar 20 o más errores consecutivos (minimumConsecutiveFailures) durante un periodo de tiempo igual o mayor que 10 segundos (minimumFailureTimeMs). Cuando se cumplen ambas condiciones, el interruptor de circuito detiene el acceso al programa de fondo y no lo reintenta durante 30 segundos (retryWaitTimeMs).

Una vez que se ha alcanzado retryWaitTimeMs, el interruptor de circuito permitirá conexiones con el servidor de Redis. Durante este tiempo, si se registra una solicitud remota satisfactoria, el interruptor de circuito saldrá de la modalidad de interrupción. Si en su lugar se alcanza el número de errores configurados en minimumConsecutiveFailuresResumeOutage, el interruptor de circuito restaurará la modalidad de interrupción y evitará las solicitudes remotas. minimumConsecutiveFailuresResumeOutage permite realizar pruebas rápidas de la conexión remota sin tener que esperar a que se vuelva a alcanzar minimumFailureTimeMs y minimumConsecutiveFailures.

A medida que las invalidaciones no están disponibles durante una interrupción de Redis, se puede utilizar un nuevo tiempo de vida (TTL) breve en la memoria caché local durante la interrupción. El TTL está controlado por el valor maxTimeToLiveWithRemoteOutage, que tiene el valor predeterminado de 60 segundos. Cuando una conexión sale de la modalidad de interrupción, se siguen utilizando los tiempos de espera regulares.

Todos estos valores de interrupción de circuito se pueden sustituir en el archivo de configuración personalizada.