Soporte de invalidación

En IBM Websphere Commerce Version 8, IBM Data Replication Service (DRS) está integrado con WebSphere DynaCache y realiza el trabajo de replicar mensajes de invalidación. En HCL Commerce Version 9.0, Kafka se utiliza para enviar mensajes de invalidación. Con HCL Cache con Redis en HCL Commerce Version 9.1, el proveedor maneja la réplica de mensajes de invalidación dentro de DynaCache mediante el proveedor HCL Cache. HCL Cache emite automáticamente mensajes de invalidación cuando se emiten operaciones clear y invalidate para una memoria caché que habilita el almacenamiento en memoria caché local. La misma memoria caché en otros contenedores implementa un escucha y, cuando se reciben los mensajes de invalidación, las operaciones de invalidación y borrado indicadas se realizan en la memoria caché local.

HCL Cache se basa en la tecnología PUBSUB de Redis (la solución de búsqueda basada en Elasticsearch utiliza Redis PUBSUB para actualizaciones en tiempo casi real (NRT) para replicar mensajes de invalidación. Para obtener más información sobre Redis PUBSUB para actualizaciones de NRT, consulte El ciclo de vida del índice de Elasticsearch. Cada memoria caché define un tema, con un formato {cache-namespace-cacheName}-invalidation en el que se emiten y reciben mensajes de invalidación.

La base de datos de Redis proporciona mandatos que le permiten listar escuchas (PUBSUB CHANNELS), publicar (PUBLISH) y suscribirse a mensajes (SUBSCRIBE). Consulte Invalidación en Redis para obtener más detalles.

Consideraciones de temporización

El envío y la recepción de mensajes de invalidación utilizando Redis es rápido, pero no instantáneo. Considere una HCL Commerce solicitud que se ejecuta en Transaction serverts-app y realiza un cambio en los datos de la base de datos. Inmediatamente después de que se comprometa la transacción de base de datos, la memoria caché local se invalida y se envían mensajes de invalidación a los servidores de aplicaciones iguales. Mientras tanto, la aplicación puede ejecutar una solicitud posterior que espera utilizar los datos actualizados. Cuando los servidores reciben los mensajes, se procesan inmediatamente y la memoria caché local se invalida de acuerdo con los mensajes recibidos. Pero entre la hora en que se envían los mensajes y la hora en que se invalidan las memorias caché locales, los datos de las memorias caché locales quedan "obsoletos". Si se recibe la solicitud posterior en un servidor antes de que se complete la invalidación de memoria caché, verá los datos obsoletos, lo que puede provocar que se produzca un proceso incorrecto.

Para evitar acceder a datos obsoletos debido a esta situación, la HCL Commerce memoria caché de datos proporciona configuraciones opcionales para introducir un breve retardo en la solicitud original Transaction server , justo después de enviar los mensajes de invalidación y antes de que se devuelva la solicitud. Si el retardo es lo suficientemente largo como para permitir que los mensajes de invalidación se procesen completamente en servidores de aplicaciones iguales, se puede evitar el problema de temporización.

La configuración de memoria caché de datos delayAfterInvalidationMilliseconds se puede utilizar para especificar cuánto tiempo debe introducirse un retardo. Sin embargo, puede ser difícil calcular cuánto retraso debe introducirse. La configuración adicional delayAfterInvalidationPercentBuffer se puede utilizar para añadir un retardo adicional que se basa en el tiempo que normalmente se tarda en enviar y recibir un mensaje de invalidación. Este valor solo tiene un efecto cuando delayAfterInvalidationMilliseconds es mayor que cero. Estos valores se pueden especificar a nivel global o se pueden especificar solo para determinadas memorias caché lógicas. Para obtener más información sobre estos valores, consulte Configuración adicional de la memoria caché de datos de HCL Commerce.

Por ejemplo, si el acceso ocasional a datos obsoletos es inaceptable, especificar delayAfterInvalidationMilliseconds=1 y delayAfterInvalidationPercentBuffer=100 inserta un retardo de 1 milisegundos más el doble del tiempo que normalmente se tarda en enviar y recibir un mensaje. Debe ser más que suficiente tiempo para evitar la posibilidad de acceder a datos obsoletos.