Nous pouvons mettre un serveur de cache entre notre application et notre base de données pour rendre nos applications plus rapides. Mais cela ne suffit pas lorsque nous devons faire évoluer nos applications. Voyons deux modèles de mise en cache pour de meilleures performances et comment NCache les met en œuvre.
Évolutivité grâce au partitionnement des données
Avec le partitionnement des données, nous divisons de grands ensembles de données en plus petits et les distribuons entre les nœuds. De cette façon, nous répartissons les lectures et les écritures entre les nœuds, améliorant ainsi les performances globales de nos applications. NCache prend en charge différents topologies de mise en cache. Dans ce contexte, une topologie est une stratégie de stockage de données, de réplication et de connectivité client. Deux topologies implémentent le partitionnement des données : la Topologies partitionnées et partition-réplica. Dans ces deux topologies, NCache divise les données en compartiments et place ces compartiments dans les nœuds de notre cluster.
NCache utilise 1000 XNUMX compartiments et les répartit équitablement entre les nœuds d'un cluster. Par exemple, si nous démarrons un cluster de cache avec un seul nœud, NCache attribue tous les compartiments à notre nœud unique. Si nous ajoutons un autre nœud, NCache divise ces 1000 500 compartiments en deux nœuds de XNUMX compartiments. De plus, si nous supprimons un nœud, NCache distribue ses compartiments dans les nœuds restants.
Depuis que NCache divise nos données en compartiments et en nœuds, un client de cache se connecte à tous les nœuds mais effectue des opérations de lecture et d'écriture directement sur le nœud qui contient un élément. Même si un nœud n'est pas disponible, un client de cache redirige nos requêtes en utilisant les nœuds actifs pour terminer nos opérations. NCache distribue des compartiments entre les nœuds en gardant la taille des données dans chaque nœud presque la même. De cette façon, non seulement nous divisons les lectures et les écritures entre les nœuds, mais nous augmentons également la capacité de stockage de notre cluster avec chaque nœud que nous ajoutons.
Grâce au partitionnement des données, les topologies Partition et Partition-Replica permettent d'adapter la charge de transaction et la capacité de stockage. Bien sûr, Partition et Partition-Replica ne sont que deux des topologies prises en charge. NCache a plus topologies avec différentes stratégies de stockage et de réplication des données. Par exemple, certains d'entre eux sont adaptés aux applications avec plus de lectures ou d'écritures.
Stratégies de mise en cache
Avec le partitionnement des données, nous améliorons la disponibilité et les performances de nos applications puisque nous pouvons mettre en cache plus d'éléments dans notre cluster que dans un seul serveur. De plus, nous pouvons améliorer les performances de notre application en choisissant la manière dont nous remplissons notre cache. Il existe deux stratégies pour remplir notre cache : cache-aside et Read-Through/Write-Through.
Avec la stratégie de mise en cache, notre serveur de cache se trouve à côté de notre base de données. Si notre cache ne contient pas d'élément, notre application le lit à partir de notre base de données et le stocke dans le cache. Avec cette stratégie, le serveur de cache n'interagit pas directement avec notre base de données. Probablement, la stratégie de mise en cache est ce qui nous vient à l'esprit en premier lorsque nous pensons à la mise en cache.
Contrairement à la stratégie cache-side, avec les stratégies Read-Through/Write-Through, notre cache fonctionne comme la principale source de données. Ici, notre cache lit et écrit des données dans la base de données. Par conséquent, ces stratégies fonctionnent mieux avec les données de référence que nous lisons fréquemment et que nous modifions périodiquement, et avec les lignes de la base de données, nous pouvons facilement mapper les éléments du cache.
Avec Read-Through/Write-Through, nous déplaçons une partie du code d'accès aux données de notre application vers le cache, ce qui rend notre code d'application plus simple et plus petit. NCache prend en charge les stratégies de mise en cache Read-Through et Write-Through.
Mise en cache de lecture
NCache utilise un fournisseur de lecture personnalisé pour appeler la base de données sous-jacente en cas d'échec du cache. Aussi, on peut forcer NCache pour toujours lire la base de données même si nous n'avons pas de manque de cache. Notre fournisseur de lecture doit implémenter le Interface IReadThruProviderIReadThruProvider interface. Il contient des méthodes comme ChargerDepuisSource ainsi que LoadDataTypeFromSource.
Une fois que nous avons un Fournisseur de lecture déployé sur notre serveur de cache, soit via le NCache Manager ou scripts PowerShell, nous pouvons l'utiliser depuis nos applications clientes en passant l'objet ReadThruOptions en paramètre à la méthode Get, comme ceci,
1 2 3 4 5 6 7 8 9 10 11 |
// After having NCache up and running... var key = $"Product:123456"; var readThruOptions = new ReadThruOptions { Mode = ReadMode.ReadThru }; // Retrieve a cached item with Read-Thru enabled var data = cache.Get<Product>(key, readThruOptions); // Do something with the cached product here... |
Mise en cache d'écriture immédiate
En revanche, avec la stratégie Write-Through, NCache met d'abord à jour notre cache et, ensuite seulement, notre base de données. NCache peut mettre à jour notre base de données de manière synchrone ou asynchrone. NCache appelle les mises à jour Write-Through asynchrones : Write-Behind.
Notre fournisseur Write-Through doit implémenter le Interface IWriteThruProvider. Il contient la méthode WriteToDataSource avec des surcharges pour les éléments uniques et multiples, et structures de données. Notre fournisseur Write-Through doit prendre en charge les opérations d'écriture pour ajouter, supprimer et mettre à jour des éléments.
Semblable au déploiement d'un fournisseur de lecture directe, nous devons déployer notre Fournisseur d'écriture directe à notre cache. Une fois que nous déployons notre fournisseur, dans nos applications clientes, nous devrions passer le Options d'écriture objet lors de l'insertion d'éléments dans le cache, comme ceci,
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// After having NCache up and running... var product = BuildProduct(); var key = $"Product:{product.ProductId}"; var cacheItem = new CacheItem(product); var writeThruOptions = new WriteThruOptions { Mode = WriteMode.WriteThru; } // Add an item with Write-Thru enabled cache.Insert(key, cacheItem, writeThruOptions); |
La lecture et l'écriture nous aident à améliorer l'évolutivité et les performances de nos applications. Avec Read-Through, nos éléments mis en cache sont toujours disponibles depuis NCache peut lire automatiquement les éléments expirés. Et, avec Write-through, notre application n'a pas à attendre les écritures de la base de données puisque NCache peut mettre à jour notre base de données de manière asynchrone et, même avec un mécanisme de limitation, réduire la pression sur notre base de données.
Conclusion
Ce sont deux modèles de mise en cache pour de meilleures performances et une meilleure évolutivité : les stratégies de partitionnement et de mise en cache des données. On peut utiliser NCache pour les implémenter dans nos applications. Avec le partitionnement des données, nous divisons les lectures et les écritures entre les nœuds et augmentons la capacité de stockage de notre cache. Nous avons NCache Topologies de partition et de partition-réplica pour cela. Et avec Read-Through/Write-Through, nous faisons de notre serveur de cache la source de données, ce qui soulage une certaine pression de notre base de données.
Pour en savoir plus sur le partitionnement des données et la lecture/écriture directe, consultez ces deux guides : Topologies partitionnées et partition-réplica ainsi que Fournisseurs de sources de données pour le cache. Si vous souhaitez bénéficier de ces deux modèles de mise en cache pour faire évoluer vos applications, donnez NCache un essai.