HCL Cache avec Redis
Lorsque la mise en cache à distance est activée, HCL Cache utilise un serveur Redis pour stocker les données du cache et les métadonnées requises, telles que les ID de dépendance. Kafka n'est pas requis pour l'invalidation du cache si vous utilisez Redis.
Cette rubrique décrit la mise en œuvre générale de Redis dans HCL Commerce, et inclut quelques meilleures pratiques lors de l'utilisation de HCL Cache dans un environnement Kubernetes de production.
Vue d'ensemble de Redis
Les caches individuels sont liés à un seul nœud Redis. Cela permet d'effectuer de nombreuses opérations de cache avec un seul appel réseau à l'aide de scripts LUA. Les données et les métadonnées d'un cache sont pré-fixées avec le nom du cache qui est une balise de hachage. Par exemple : {cache-services/cache/WCStoreDistributedMapCache}-.
HCL Cache les entrées sont implémentées en tant que HashMaps Redis et contiennent des informations clés de valeur et de métadonnées telles que les dépendances, le délai d'expiration, le temps de création d'entrée et le pod d'où provient l'entrée. Une valeur de durée de vie (TTL) Redis est définie pour correspondre aux configurations de délai d'attente. Les délais d'attente d'inactivité ne sont pas pris en charge par le cache distant.
Les informations de dépendance sont stockées dans les ensembles Redis qui sont mis à jour à mesure que les entrées sont créées ou invalidées. Si des clés de cache sont supprimées en raison de la durée de vie ou de l'expulsion de la moins récemment utilisée, l'ensemble n'est pas mis à jour et peut référencer les entrées invalidées pendant un certain temps. Ce comportement est normal.
Une invalidation par ID de dépendance ou une opération de nettoyage de cache désactive les listes de dépendances.
Si Redis doit expulser les clés les moins récemment utilisées en raison du manque d'espace, les ensembles de dépendances ne doivent jamais être expulsés tant qu'il y a des entrées dans le cache. Pour ce faire, il faut s'assurer que toutes les entrées de cache ont un délai d'attente défini tandis que les ensembles de dépendances n'en ont pas. Redis doit être configuré avec un paramètre LRU volatile-*. Pour plus de détails, voir Utilisation de Redis en tant que cache LRU dans la documentation Redis.
Lorsqu'un cache permet la mise en cache locale, les opérations distantes publient des messages d'invalidation pour refléter les modifications requises dans les caches locaux. Les messages d'invalidation sont propagés à l'aide de canaux Redis, avec des noms qui incluent les noms de cache. Par exemple, {cache-baseCache}-invalidation.
Remarques sur la haute disponibilité
Les environnements de production doivent utiliser des configurations hautement disponibles de la base de données Redis. Utilisez des topologies qui offrent une redondance telle que regroupement ou maître/esclave avec des réplicas. Le client Redisson Redis, qui est utilisé par HCL Cache, prend en charge les topologies les plus populaires.
Lorsqu'un HCL Cache est activé avec des interfaces locales et distantes, le cache local peut fournir la disponibilité si le cache Redis distant devient indisponible. Le cache HCL inclut une configuration circuit breaker qui peut être utilisée pour configurer le comportement du cache en cas d'incident Redis.
Avec la configuration par défaut, un cache est défini en mode panne après avoir connu 20 échecs consécutifs ou plus (minimumConsecutiveFailures) pendant une période de temps égale ou supérieure à 10 secondes(minimumFailureTimeMs). Lorsque les deux conditions sont remplies, le circuit breaker arrête l'accès à l'arrière-plan et ne fait pas de nouvelle tentative pendant 30 secondes(retryWaitTimeMs).
Une fois retryWaitTimeMs atteint, le circuit breaker autorise les connexions au serveur Redis. Pendant ce temps, si une requête à distance réussie est enregistrée, le circuit breaker quitte le mode de panne. Si au contraire le nombre de défaillances configurées dans minimumConsecutiveFailuresResumeOutage est atteint, le circuit breaker restaure le mode de panne et empêche les requêtes distantes. minimumConsecutiveFailuresResumeOutage permet de tester rapidement la connexion à distance sans avoir à attendre d'atteindre à nouveau le minimumFailureTimeMs et les minimumConsecutiveFailures.
Comme les invalidations ne sont pas disponibles lors d'une panne de Redis, une nouveau courte durée de vie (TTL) peut être utilisée sur le cache local pendant la panne. La durée de vie est contrôlée par le paramètre maxTimeToLiveWithRemoteOutage, par défaut de 60 secondes. Lorsqu'une connexion quitte le mode de panne, les délais d'attente normaux continuent d'être utilisés.
Tous ces paramètres de circuit breaker peuvent être remplacés dans fichier de configuration personnalisé.