Une couche de mise en cache rapide, avec un taux élevé de disponibilité et échelonnable qui englobe plusieurs nuages
La mise en cache améliore le temps de réponse de l’application en mettant en mémoire les données les plus fréquemment utilisées sur des stockages éphémères mais très rapides. Les solutions de caching en mémoire maintiennent les données dans la DRAM, plus rapide que les disques, peut s’avérer extrêmement efficace pour atteindre ces objectifs. Alors que la mise en cache est généralement utilisée pour améliorer la latence, un cache hautement disponible et résistant peut également aider à la mise à l’échelle des applications. Le transfert des responsabilités de la logique principale de l’application vers la couche de mise en cache libère des ressources permettant le traitement des demandes entrantes.
La plupart des bases de données traditionnelles sont conçues pour fournir la fonctionnalité plutôt que la vitesse lors de la mise à l’échelle. Le cache de la base de données est souvent utilisé pour stocker des copies des tables de lookup et les réponses aux coûteuses requêtes de la SGDB, afin d’améliorer les performances de l’application et de réduire la charge sur la source de données.
La mise en cache des données de session de l’utilisateur fait partie intégrante de la mise en place d’applications scalables. Comme chaque interaction des utilisateurs implique l’accès aux données de la session, le fait de conserver les données dans le cache réduit le temps de réponse à l’utilisateur de l’application. Le fait de conserver les données de session dans un cache est plus efficace que de garder les sessions «sticky» au niveau du load-balancer, car la mise en cache permet le traitement des requêtes par tous les serveurs de données sans perdre les états des utilisateurs. Une approche avec load-balancer force le traitement de toutes les requêtes d’une session par un seul serveur d’application.
Les applications modernes sont structurées à l’aide de composants couplés de manière non restrictive et communiquant via des API. Les composants de l’application utilisent les API pour faire des requêtes pour un service provenant d’autres composants, que ce soit au sein (architecture de microservices) ou à l’extérieur (dans le cas d’utilisation de logiciel agissant en tant que service) de l’application. Le stockage de la réponse de l’API dans le cache, même s’il est de courte durée, améliore la performance de l’application en évitant ce processus de communication entre les deux composants.
La première exigence que doit remplir une couche de mise en cache est une haute performance quelle que soit la charge. Les recherches indiquent que pour que les utilisateurs perçoivent l’expérience comme “instantanée”, la réponse de bout en bout doit prendre moins de 100 millisecondes. Pour résumer, une couche de cache haute performance doit fournir en permanence un haut débit avec un faible temps de latence afin de ne pas se transformer en goulot d’étranglement.
Une couche haute performance de mise en cache doit pouvoir évoluer et répondre à la demande en cas de croissance commerciale ou de pics d’activité (comme à la Saint-Valentin, à Noël, en cas de catastrophes naturelles ou de pandémies). La capacité d’adaptation doit également être dynamique sans causer un arrêt ou des migrations hors ligne, sans augmenter le temps de réponse.
De plus en plus d’organisations adoptent les stratégies multi-Cloud, que ce soit pour éviter le verrouillage par un fournisseur ou pour profiter d’un des meilleurs outils de plusieurs fournisseurs. Il est toutefois plus compliqué de gérer un système de mise en cache réparti sur différents sites géographiques garantissant un temps de latence inférieur au millième de seconde et résolvant simultanément les conflits de jeux de données sur plusieurs nuages.
Ceci est la façon la plus habituelle d’utiliser Redis en cache. Avec cette stratégie, l’application cherche tout d’abord dans le cache pour récupérer les données. Si des données ne sont pas trouvées (cache miss), l’application récupère alors directement les données du stockage de données en fonctionnement. Les données sont chargées dans le cache uniquement lorsque cela est nécessaire (ceci est la raison pour laquelle la méthode est également appelé lazy-loading). Les applications utilisant beaucoup la lecture peuvent largement profiter de l’utilisation de ce type d’approche.
Dans cette stratégie, les données sont toujours écrites tout d’abord dans le cache (par exemple, Redis) avant d’être mises à jour de manière asynchrone dans le stockage de données opérationnel utilisé. Cette approche améliore la performance d’écriture et facilite le développement de l’application car le développeur n’écrit que sur un site (Redis). RedisGears fournit à la fois les capacités de write-through et write-behind.
Voir la démo GitHub
Cette stratégie est similaire à l’approche write-behind, le cache se trouve entre l’application et le stockage de données utilisé, mais les mises à jour sont réalisées de manière synchrone. Le système d’écriture immédiate favorise la cohérence des données entre le cache et le stockage de données, car l’écriture a lieu sur le fil principal du serveur. RedisGears fournit à la fois les capacités de write-through et write-behind.
Voir la démo GitHub
Dans un environnement contenant une grande quantité de données historiques (par exemple, mainframe), ou si vous exigez que chaque écriture soit enregistrée sur un stockage de données en fonctionnement, les connecteurs de capture de données (CDC) de Redis Enterprise peuvent capturer des changements individuels de données et propager des copies exactes sans affecter les opérations en cours tout en conservant leur consistance en quasi temps réel. Couplé à la capacité de Redis Enterprise d’utiliser plusieurs modèles de données, CDC peut vous fournir une vision appréciable des données précédemment verrouillées.
Capacités de modèle de données multiples dans RedisLa performance de l’application s’appuie sur la couche de mise en cache. Comme votre cache peut traiter des millions d’opérations par seconde, une seule seconde de non-fonctionnement peut avoir un effet extrême sur la performance et la capacité de respecter votre accord de niveau de service (SLA). Les sauvegardes automatiques, la détection instantanée de panne, la récupération rapide sur plusieurs racks/zones/régions de Redis Enterprise tout comme plusieurs options de persistance des données sont des facteurs clés pour assurer une couche hautement disponible de mise en cache et pour garantir une expérience d’utilisateur constante.
Une couche de mise en cache d’application haute performance doit être facilement et rapidement adaptable en taille pour répondre aux exigences de croissance et de pic. Le haut débit de Redis Enterprise qui est doté d’une latence inférieure au millième de seconde, l’architecture qui ne partage vraiment aucun élément permettant l’adaptation linéaire de la taille, la prise en charge de plusieurs locataires ainsi que l’architecture à plusieurs noyaux sont autant d’éléments qui garantissent que les ressources de calcul sont pleinement utilisées avec une performance de niveau supérieur.
Quels que soient vos environnements de déploiement, la couche de mise en cache doit avoir une grande disponibilité et une faible latence indépendamment du site physique. En outre, la technologie Active-Active basée sur les CRDT fournit une latence locale pour les opérations de lecture et d’écriture, une résolution de conflit sans heurt à la fois pour les types de données simples et complexes et garantit la continuité des opérations commerciales même si un grand nombre de répliques est hors service. Résultats : moins de problèmes de développement et réduction de la charge opérationnelle.
Bon nombre des solutions disponibles étant basées sur des technologies de créneau ou élaborées pour des cas d’utilisations spécifiques, elles ne sont pas largement utilisées. Le code source libre de Redis prend en charge plus de 50 langages de programmation, plus de 150 bibliothèques clientes et demeure la couche de mise en cache par défaut de la plupart des environnements de déploiement. Redis abrite Redis Open-Source. Cette base de données la plus plébiscitée pour la 4ème année de suite introduit des capacités pour l’entreprise dans votre couche de mise en cache.
Le développement d’une couche de mise en cache devrait être facile et rapide, sans augmenter la charge de travail de votre équipe. Redis Enterprise peut être déployé en tant que service totalement géré dans le Cloud public ce qui vous évite le provisionnement, la conception de patches, la surveillance et autres tâches de gestion. Il peut également être déployé comme logiciel sur votre propre infrastructure pour vous fournir le contrôle total de la gestion et de la configuration. De plus, le modèle hybride est pris en charge pour préserver la polyvalence opérationnelle.
Redis is designed around tRedis est conçu autour du concept des structures de données et peut stocker votre jeu de données au travers de Strings, Hashes, Sorted Sets, Lists, Streams et autres structures de données ou sur les modules Redis.
À l’aide de Node.js, vous pouvez récupérer et enregistrer des couples de valeurs clés avec de simples chaînes à l’aide des commandes GET et SET de l’objet client, comme vous pouvez le voir ici:
// connecting redis client to local instance.
const client = redis.createClient(6379) // Retrieving a string value from Redis if it already exists for this key return client.get(‘myStringKey’, (err, value) => { if (value) { console.log(‘The value associated with this key is: ‘ + value) } else { //key not found // Storing a simple string in the Redis store client.set(‘myStringKey’, ‘Redis Enterprise Tutorial’); } } });
Cet extrait de code essaie de récupérer la valeur de la chaîne associée à la clé myStringKey key à l’aide de la commande GET. Si la clé n’est pas trouvée, la commande SET enregistre la valeur du didacticiel de Redis Enterprise pour MyStringKey.
Vous pouvez écrire le même code dans Python, comme indiqué ici :
# connecting redis client to local instance.
r = redis.Redis(host='localhost', port=6379, db=0) # Retrieving a string value from Redis if it already exists for this key value = r.get(‘myStringKey’) if value == None: # key not found # Storing a simple string in the Redis store r.set(‘myStringKey’, ‘Redis Enterprise Tutorial’) else: print ‘The value associated with this key is: ‘, value
