Prise en charge d'invalidation

Dans IBM Websphere Commerce Version 8, IBM Data Replication Service (DRS) est intégré à WebSphere DynaCache et effectue le travail de réplication des messages d'invalidation. Dans HCL Commerce Version 9.0, Kafka est utilisé pour envoyer des messages d'invalidation. Dans le cas de HCL Cache avec Redis dans HCL Commerce Version 9.1, la réplication des messages d'invalidation est gérée dans DynaCache par le fournisseur HCL Cache. HCL Cache émet automatiquement des messages d'invalidation lorsque des opérations clear et invalidate sont émises pour un cache qui permet la mise en cache locale. Le même cache sur d'autres conteneurs implémente un programme d'écoute, et lorsque les messages d'invalidation sont reçus, les opérations d'invalidation et d'effacement indiquées sont effectuées sur le cache local.

HCL Cache s'appuie sur la technologie Redis PUBSUB (la solution de recherche basée sur Elasticsearch utilise Redis PUBSUB pour les mises à jour en quasi-temps réel (NRT)) afin de répliquer les messages d'invalidation. Pour plus d'informations sur redis PUBSUB pour les mises à jour NRT, voir Cycle de vie de l'index Elasticsearch. Chaque cache définit un sujet, au format {cache-namespace-cacheName}-invalidation dans lequel les messages d'invalidation sont émis et reçus.

La base de données Redis fournit des commandes qui vous permettent de répertorier les programmes d'écoute (PUBSUB CHANNELS), de publier (PUBLISH) et de vous abonner aux messages (SUBSCRIBE). Pour plus de détails, voir Invalidation dans Redis.

Considérations de délais

L'envoi et la réception de messages d'invalidation à l'aide de Redis sont rapides, mais pas instantanés. Prenez en compte une requête HCL Commerce qui s'exécute dans Transaction serverts-app et qui apporte une modification aux données de la base de données. Immédiatement après la validation de la transaction de base de données, le cache local est invalidé et les messages d'invalidation sont envoyés aux serveurs d'applications homologues. Pendant ce temps, l'application peut exécuter une requête ultérieure qui s'attend à utiliser les données mises à jour. Lorsque les messages sont reçus par les serveurs homologues, ils sont immédiatement traités et le cache local est invalidé en fonction des messages reçus. Mais entre le moment où les messages sont envoyés et le moment où les caches locaux sont invalidés, les données des caches locaux sont "périmées". Si la requête suivante est reçue sur un serveur homologue avant la fin de l'invalidation du cache, les données périmées s'afficheront, ce qui peut entraîner un traitement incorrect.

Pour éviter d'accéder aux données périmées en raison de cette situation, le cache de données HCL Commerce fournit des configurations facultatives pour introduire un court délai dans la requête d'origine Transaction server, juste après l'envoi des messages d'invalidation et avant le retour de la requête. Si le délai est suffisamment long pour permettre le traitement complet des messages d'invalidation sur les serveurs d'applications homologues, le problème de délai peut être évité.

La configuration du cache de données delayAfterInvalidationMilliseconds peut être utilisée pour spécifier la durée d'introduction d'un délai. Mais il peut être difficile d'estimer le délai à introduire. La configuration supplémentaire delayAfterInvalidationPercentBuffer peut être utilisée pour ajouter un délai supplémentaire en fonction du temps qu'il faut généralement pour envoyer et recevoir un message d'invalidation. Ce paramètre n'a d'effet que lorsque delayAfterInvalidationMilliseconds est supérieur à zéro. Ces paramètres peuvent être spécifiés au niveau global ou uniquement pour certains caches logiques. Pour plus d'informations sur ces paramètres, voir Complément de configuration du cache de données de HCL Commerce.

Par exemple, si l'accès occasionnel à des données périmées est inacceptable, la spécification de delayAfterInvalidationMilliseconds=1 et de delayAfterInvalidationPercentBuffer=100 insère un délai de 1 milliseconde plus le double du temps qu'il faut généralement pour envoyer et recevoir un message. Cela devrait être plus que suffisant pour éviter la possibilité d'accéder à des données périmées.