Cache Client
NCache Les topologies de cluster sont conçues pour fournir les meilleures performances et évolutivité pour vos applications. Avec des besoins commerciaux croissants, les applications doivent traiter davantage de demandes et de données des clients. L'ajout de nœuds supplémentaires au cache distribué de manière transparente offre une évolutivité linéaire. Comme un cache de processeur matériel, le cache client élève les performances de vos applications à un niveau supérieur en rapprochant l'ensemble de données chaudes de votre application, même à l'intérieur du processus de l'application avec le Mode InProc.
Prenons l'exemple d'une application de commerce électronique. L'application accède fréquemment au catalogue de produits et aux données des utilisateurs actuellement actifs. Ces données peuvent être conservées dans le cache client exécuté sur le boîtier client. D'un côté, conserver ces données dans le cache client améliore les performances de l'application en évitant les déplacements vers la base de données et le cache cluster. D'un autre côté, il décharge de nombreuses opérations de lecture/écriture du cache du cluster en permettant au cache du cluster de prendre plus de requêtes. Et ce gain de performances ne compromet pas la cohérence des données. Le cache client maintient ses données synchronisées avec le cache du cluster. La façon dont le cache client se synchronise avec le cache du cluster est expliquée dans les sections suivantes.
Branchez & jouez: L'utilisation du cache client est assez simple. Aucune modification de code n'est requise à la fin de l'application. Il s'agit d'une option de configuration simple. Vous pouvez créer un cache client via le NCache Centre de gestion au sein de l’ NCache applets de commande Powershell pris en charge. Une fois le client configuré, les applications client commenceront automatiquement à l'utiliser. Pour les applications déjà en cours d'exécution, un redémarrage de l'application est requis.
Tous Opérations CRUD qui acceptent les clés de cache en entrée, telles que Ajouter, Obtenez, inséreret Effacer, sont acheminés via le cache client. Les opérations de lecture recherchent d’abord les données dans le cache client. Le cache client renvoie les données (si trouvées). Sinon, l'opération de lecture est exécutée sur le cache du cluster. Les données renvoyées par le cache du cluster sont renvoyées à l'application après avoir été ajoutées au cache client. Ainsi, le prochain appel Read pour les mêmes données sera servi à partir du cache client. Pour les opérations de lecture en masse, seules les données manquantes dans le cache client sont extraites du cache du cluster.
Opérations d'écriture basées sur des clés telles que : Ajouter ainsi que insérer, sont d'abord effectués sur le cache du cluster. Une fois l'opération réussie, les données sont ajoutées au cache client, puis transmises à l'application. Les autres instances de cache client sont mises à jour via un mécanisme de synchronisation des données en arrière-plan, qui est expliqué plus tard.
Le cache client ne contient qu'un sous-ensemble des données du cache du cluster. Par conséquent, toutes les autres opérations non basées sur des clés comme ObtenirGroupe, requêtes SQLet ObtenirByTags, etc., sont directement effectués sur le cache du cluster.
Modes d'isolement
Le cache client s'exécute sur le nœud client sur lequel vos applications s'exécutent. En fonction de vos besoins en performances et de l'architecture de l'application, vous pouvez choisir l'un des modes d'isolation au niveau du processus suivants pris en charge par le cache client.
En cours
Comme son nom l'indique, le cache client s'exécute au sein du processus d'application, éliminant ainsi la communication entre les processus. Les données utilisateur sont conservées sous forme d'objet pour éviter le coût de désérialisation. Ce mode offre des performances maximales à l'application. Étant donné que le cache client est hébergé dans le processus d'application, les données contenues dans le cache client ne sont pas partagées entre d'autres instances d'application. Chaque instance de l'application héberge une instance de cache client dédiée. Bien que le mode InProc fournisse un processus maximal, il ne convient que si :
L'ensemble de données chaudes de l'application n'est pas trop volumineux.
L'application ne dispose que de quelques instances sur chaque nœud client avec suffisamment de mémoire physique. N'oubliez pas que chaque instance de cache client contient sa copie de données.
Le cycle de vie de l'application est suffisamment long pour bénéficier des avantages du cache client. N'oubliez pas que le cycle de vie du cache client dépend du cycle de vie de l'application. Lorsque l'application s'arrête, toutes les données du cache client sont également perdues. Les applications avec des cycles de vie courts s'arrêteraient ou redémarreraient avant que le cache client ne soit entièrement rempli.
Chaque application possède son propre ensemble de données chaudes, différent des autres applications.
SortieProc
Ce mode fournit une isolation au niveau du processus pour le cache client. Le cache client s'exécute dans son processus dédié sur le nœud client. Les applications communiquent avec le cache client via des sockets TCP. Plusieurs instances d'application peuvent communiquer avec le même cache client, partageant ainsi des données. Bien qu'InProc surpasse le mode OutProc en termes de performances, le mode OutProc présente ses propres avantages.
Plusieurs applications s'exécutant sur le même ordinateur client communiquent avec le même cache client. Plusieurs applications partagent des données. Les données chargées ou mises à jour par une application deviennent disponibles pour d'autres applications.
Le redémarrage de l'application n'entraîne pas de perte de données du cache client.
Moins de ressources physiques telles que la RAM et le processeur sont nécessaires pour exécuter le cache client en mode OutProc par rapport au mode InProc lorsque chaque processus d'application détient sa copie du cache client.
La synchronisation des données du cache client (expliquée plus loin) avec le cache du cluster réduit la charge sur le cache du cluster puisque vous exécutez une seule instance de cache client par machine cliente.
Notes
Si le cache client OutProc est en panne, l'application effectuera directement des opérations sur le cache du cluster. Lorsque le cache client redémarre, il se connectera automatiquement au cache client. Vous pouvez modifier ce comportement en définissant le skip-client-cache-if-unavailable
drapeau dans client.ncconf. Si le drapeau est défini sur false
, les opérations de cache échoueront si le cache client est inactif.
Synchronisation des données avec le cache du cluster
Malgré une configuration Plug & Play simple, nous ne pouvons ignorer le fait que le cache client contient une copie des données du cache du cluster. Les modifications apportées aux données dans un cache de cluster doivent être propagées au cache client. Plusieurs caches clients exécutés en mode InProc ou OutProc peuvent exister pour un cache de cluster donné. Les modifications de données apportées par l'application client sont effectuées sur l'instance de cache client à laquelle l'application est connectée. Par conséquent, cette instance du cache client est automatiquement synchronisée. Cependant, les autres instances du cache client ignorent ces modifications. Les modifications apportées aux données du cache du cluster sont synchronisées avec ces instances de cache client via un mécanisme de synchronisation des données en arrière-plan expliqué ci-dessous :
Lorsque des données sont ajoutées au cache du client, il enregistre la notification de modification des données avec le cache du cluster pour les données données.
Le cache du cluster garde une trace de chaque
CacheItem
qu'un cache client contient et surveille les modifications apportées aux données.Lorsque les données sont a actualisé/enlevé à partir du cache de cluster, le cache de cluster enregistre ces modifications.
Un thread de travail en arrière-plan dédié inspecte les modifications de données chaque seconde et détermine quels caches clients doivent être informés des modifications. Il envoie une notification aux caches clients concernés indiquant que les données ont été modifiées.
Un autre thread de travail en arrière-plan dédié s'exécutant dans le cache client est chargé de synchroniser les modifications de données avec le cache du cluster lors de la réception de la notification de modification de données. Dès qu'il reçoit la notification, il demande le cache du cluster et demande des mises à jour des données. Nous appelons ce mécanisme de synchronisation Polling du cache client.
Ce thread de travail exécuté dans le cache client interroge les modifications de données toutes les 10 secondes s'il n'a reçu aucune notification du cache du cluster pour gérer les cas où il aurait pu manquer une notification en raison d'une perte de connectivité entre le cache client et le cache du cluster.
Ce puissant mécanisme de synchronisation garantit que les applications clientes reçoivent toujours les dernières données du cache client avec des performances et une évolutivité accrues.
Modes de synchronisation
Outre le mécanisme de synchronisation des données en arrière-plan, le cache client prend en charge les deux modes de synchronisation suivants.
Synchronisation optimiste
Il s'agit du mode de synchronisation par défaut du cache client. Lorsqu'une application extrait des données du cache client et que le cache client contient ces données, les données sont simplement renvoyées à l'application. La synchronisation est effectuée en arrière-plan, comme expliqué ci-dessus.
Synchronisation pessimiste
Le mécanisme de synchronisation en arrière-plan convient à la plupart des applications et offre des performances et une évolutivité optimales à l'application. Cependant, pour les applications plus sensibles et souhaitant s'assurer qu'elles disposent toujours des données les plus récentes, le mode pessimiste est conçu pour elles. Avec ce mode, lorsqu'une application récupère des données du cache client et que le cache client contient ces données, le cache client vérifie la version de l'élément avec le cache du cluster. Si une version mise à jour des données est trouvée dans le cache du cluster, elle est récupérée et mise à jour dans le cache client. Ainsi, l'application est garantie d'obtenir la dernière version du CacheItem
.
Voir aussi
Topologies de cache
Clustering Dynamique
Cache local
Client cache
Pont pour la réplication WAN