Mise en cache locale et distante dans HCL Cache

HCL Cache étend les capacités de DynaCache en permettant l'utilisation de la mise en cache distante prise en charge par Redis.

Mise en cache locale

Le comportement de la mise en cache locale est similaire à celui des caches DynaCache traditionnels, avec quelques différences importantes :

Réplication des messages d'invalidation: L'utilisation de la mise en cache locale nécessite la réplication des messages d'effacement et d'invalidation du cache pour s'assurer que le contenu périmé ou obsolète est supprimé des caches sur d'autres conteneurs. Dans HCL Commerce Version 9.0, cela a été réalisé avec l'utilisation de Kafka. Lorsque HCL Cache est activé avec Redis, les invalidations sont gérées automatiquement par la structure. Pour plus de détails, voir Invalidations.

Réglage automatique de l'encombrement de la mémoire: La structure HCL Cache simplifie le réglage des tailles du cache local avec le réglage automatique de l'encombrement de la mémoire qui peut redimensionner automatiquement les caches locaux en fonction de la quantité de mémoire libre.

Fonctions de surveillance: HCL Cache implémente un ensemble complet de métriques pour les caches locaux afin de prendre en charge la surveillance, le débogage et le réglage. Les métriques permettent le suivi des tailles de cache (par nombre d'entrées et encombrement de mémoire en Mo), des ratios d'accès, des opérations de cache et des suppressions internes par seconde (expiration, inactivité, suppression explicite et expulsion de LRU). Les métriques de cache locales peuvent être suivies à l'aide des tableaux de bord "HCL Cache - Détails du cache local" et "HCL Cache - Récapitulatif du cache local". Pour plus de détails, voir Surveillance.
HCL Cache : Détails du cache local - tableau de bord :

Utilisation du déchargement du disque: Les caches HCL Cache ne prennent pas en charge le déchargement du disque. Les configurations de déchargement du disque dans WebSphere DynaCache sont ignorées. Pour dépasser les limites de mémoire JVM locales, les caches locaux sont conçus pour être utilisés conjointement avec des caches Redis distants.

Moniteur de cache étendu WebSphere: Pour plus d'informations sur le moniteur de cache étendu WebSphere, voir Moniteur de cache WebSphere.

Mise en cache distante

L'extension de la structure de mise en cache avec l'utilisation d'un cache distant dans Redis peut améliorer les performances et l'évolutivité :

Les caches distants ne sont pas liés par les limites JVM locales : Les caches distants peuvent être mis à l'échelle vers des centaines de gigaoctets. Les caches volumineux peuvent afficher des taux d'accès plus élevés, améliorant ainsi les performances et réduisant la nécessité de régénérer le contenu, ce qui réduit la surcharge dans d'autres services et bases de données.
Amélioration de l'évolutivité : Avec l'utilisation de caches locaux, chaque serveur doit gérer son propre cache. Les entrées de cache peuvent avoir besoin d'être générées une fois par pod. Par exemple, chaque pod doit générer et gérer sa propre copie de la page d'accueil. Lorsque seule la mise en cache locale est utilisée, l'augmentation du nombre de conteneurs augmente le nombre global d'échecs de cache, ce qui augmente la charge sur les services dorsaux, tels que la base de données principale pour HCL Commerce ou la base de données de recherche (Solr ou Elasticsearch). Toutefois, lorsque la mise en cache à distance est utilisée, chaque entrée de cache distante n'a besoin d'être créée qu'une seule fois à partir des services dorsaux. Les serveurs utilisant à la fois la mise en cache locale et distante (QueryApp, TsApp, Search) peuvent être mis à l'échelle et consommer le cache existant à partir du cache distant au lieu de régénérer ses propres services dorsaux. Les conteneurs nouvellement démarrés ont un accès immédiat au cache existant et l'impact de la période d'initialisation est considérablement réduit. Cet avantage s'applique également aux scénarios d'effacement du cache.

Pour utiliser la mise en cache à distance, les entrées de cache doivent être sérialisables. Par défaut, les caches distants qui rencontrent des erreurs de sérialisation sont désactivés : La mise en cache à distance est désactivée pour ce cache en raison d'erreurs de sérialisation précédentes. Assurez-vous que toutes les entrées de cache sont sérialisables. Si les entrées ne peuvent pas être sérialisables, envisagez de désactiver la mise en cache à distance pour ce cache. La configuration stopRemoteCachingOnSerializationErrors:false peut être utilisée pour continuer à autoriser la mise en cache à distance après des erreurs de sérialisation.

Note: Utilisez cette configuration avec précaution, car elle peut entraîner des fuites de mémoire.

Choix d'une option de déploiement

Mise en cache locale et distante

Il s'agit de la configuration par défaut. Les caches locaux servent de quasi-cache pour les caches distants, en conservant des copies des entrées de cache les plus récemment consultées. Ces entrées de cache peuvent être servies directement à partir du conteneur local, sans effectuer d'appels à distance vers les serveurs Redis, ce qui améliore les performances et réduit la surcharge sur les serveurs distants.

Flux de mise en cache locale et distante :

Lorsque des caches locaux et distants sont utilisés ensemble, le flux de mise en cache est le suivant :


Echec en mémoire cache	Existant dans Local	Existant dans Distant
1- Echec local	1- Accès local	1- Echec local
2- Echec distant		2- Accès distant
3- PUT local		3- PUT local (interne)
4- PUT distant

Mise en cache locale uniquement: La raison principale de la désactivation de la mise en cache distante est l'éventualité où les objets stockés dans le cache ne sont pas sérialisables. Si des caches personnalisés stockent des objets qui ne sont pas sérialisables, la mise en cache distante doit être désactivée pour le cache dans la configuration. Pour plus de détails, voir Mise en mémoire cache personnalisée. Les caches locaux uniquement doivent toujours utiliser Redis pour la réplication des invalidations.

Mise en cache distante uniquement: La mise en cache distante uniquement peut être souhaitable pour les caches qui stockent des objets fréquemment mis à jour, lorsque les modifications doivent être immédiatement disponibles pour tous les conteneurs. Par exemple, les modifications apportées aux données de session utilisateur doivent être immédiatement disponibles pour tous les conteneurs. La désactivation des caches locaux élimine le risque de lecture des données périmées en raison de problèmes de délais avec des invalidations. Des exemples de caches par défaut configurés en tant que caches à distance uniquement incluent les caches pour le marketing de précision et l'intégration de type validation.