Les offres Redis de HCL Commerce améliorent le paysage commercial

La version 9 de HCL Commerce offre de nombreux avantages aux entreprises de commerce électronique. L'un des avantages est son architecture cloud native, qui permet une évolutivité dynamique et améliore la vitesse et l'agilité des déploiements. Il n'est pas surprenant que les clients qui utilisent encore d'anciennes versions du produit se précipitent pour mettre à niveau. Ce passage à la dernière version ne va pas sans défis. En raison de la conteneurisation et du modèle sans état des serveurs Commerce, certains clients ont dû refactoriser leur code sans utiliser les objets de session HTTP. Afin de prendre en charge ce changement, HCL a introduit Redis, un service open source qui permet aux conteneurs de partager le cache et d'autres objets de session dans le cache Redis.

Problème de session HTTP dans V9

Dans HCL Commerce V7 et V8, les applications avait la possibilité d'enregistrer les données liées à la session utilisateur dans l'objet de session HTTP, en utilisant l'affinité de session ou en activant la réplication de session sur les nœuds du cluster.

Problème V9 avec la session HTTP

En raison des conteneurs sans état qui sont utilisés dans HCL Commerce V9, l'application ne prend plus en charge l'affinité de session ou la réplication. Par exemple, si vous stockiez un objet dans la session HTTP sur le conteneur1 et que votre prochaine requête touche le conteneur2, ces informations de session ne seraient pas disponibles pour le conteneur2 dans la version 9.

La solution Redis

HCL avait reconnu ce défi et introduit Redis, qui est une base de données centralisée en mémoire qui a été introduite dans HCL Commerce V9. En utilisant Redis en combinaison avec HCL Cache, Perficient a pu refactoriser les solutions existantes pour utiliser le cache de données qui pourrait ensuite être stocké à distance dans Redis et partagé entre tous les pods du cluster Kubernates. Le cache HCL gère ensuite à la fois la mise en cache et les invalidations pour permettre à la logique métier de l'application de rester la même et de modifier uniquement le mécanisme de stockage des informations de session.

Étapes de haut niveau pour résoudre le problème de session HTTP dans la version 9.1[19659009]Créez le cache d'objets personnalisé : la commande Exécuter le moteur peut être utilisée pour créer un cache personnalisé.

En fonction des besoins de l'entreprise, vous pouvez également configurer le cache de données comme local, distant ou les deux. Dans la configuration « les deux », lorsqu'une entrée doit être mise en cache, HCL Cache vérifie d'abord si elle a déjà été mise en cache dans la JVM locale du nœud actuel. S'il trouve l'entrée, il renvoie l'entrée en cache à la demande, sinon, il vérifiera alors le cache distant dans Redis pour l'entrée. Lorsqu'une entrée de cache doit être invalidée, HCL Commerce envoie un message d'invalidation à Redis, qui gère le message. Le cache HCL de l'entrée serait d'abord effacé du cache local, puis du cache distant.

Il est important de prendre en compte les facteurs commerciaux pour déterminer comment configurer le cache. Vous voulez savoir à quelle fréquence les données changeront et si les données doivent être partagées entre les nœuds d'application. Vous ne voulez pas souvent accéder au cache distant en raison de la latence, mais il y a aussi une surcharge pour la configuration et l'invalidation du cache, il est donc essentiel de comprendre l'utilisation commerciale. La mise en cache locale est la plus rapide car elle réside dans la JVM, mais est limitée au nœud. La mise en cache à distance est plus lente, mais elle est disponible pour tous les nœuds. En général, si les données changent souvent, elles doivent être chargées dans le cache distant pour une utilisation partagée. S'il s'agit de données assez statiques, alors local peut avoir plus de sens et être traité comme un registre. Le paramètre « both » offre le meilleur des deux mondes, mais a la surcharge lors de l'invalidation des informations de cache. La bonne nouvelle est que la configuration est assez facile à modifier en cas de modification de la situation commerciale.

Redis Limitations

L'une des limitations de Redis est qu'il ne prend pas en charge une fonction d'inactivité, qui correspond au montant de temps pour conserver l'entrée de cache dans le cache après le dernier accès au cache. Une solution de contournement à ce problème consiste à configurer un délai d'expiration statique pour le cache de sorte qu'après le délai d'expiration, l'entrée de cache soit automatiquement supprimée. Le défi consiste à choisir une valeur de délai d'expiration raisonnable et suffisamment longue pour que l'utilisateur sur le site termine son activité.

Redis n'a pas non plus d'algorithme de cache le moins utilisé récemment (LRU) pour décider quelles entrées supprimer. du cache si le cache manque d'espace de stockage. Une solution de contournement consiste à définir la mémoire suffisamment grande et la configuration du délai d'expiration de manière à ce que vous soyez moins susceptible de manquer de mémoire. Lorsque le cache expire, Redis nettoie les entrées de cache réelles de la mémoire, puis HCL Cache exécute une tâche en arrière-plan qui nettoie toutes les dépendances pointées vers les entrées expirées.

À propos de l'auteur

Vijay Ciliveru est architecte technique chez Perficient Inc. Il a plus de 15 ans d'expérience avec une expertise éprouvée dans la conception d'architecture, le développement et la migration d'applications commerciales HCL à partir d'anciennes plates-formes vers des applications conteneurisées. architecture cloud native de la version 9.1.

En savoir plus sur cet auteur