Mise à l'échelle des applications .NET Core pour des performances extrêmes
Introduction
.NET Core et ASP.NET Core gagnent en popularité grâce à leur conception simple, leur légèreté, leur caractère open source et leur compatibilité avec Windows et Linux. De ce fait, de nombreuses applications existantes migrent du .NET Framework vers .NET Core. La quasi-totalité des nouvelles applications sont désormais développées en .NET Core.
Bon nombre de ces applications .NET Core génèrent un trafic important, gérant des millions d'utilisateurs et de transactions. Par conséquent, elles ont un impact considérable sur votre activité et sont donc essentielles.
Qui a besoin d'évolutivité ?
Les applications .NET Core qui nécessitent généralement une grande scalabilité sont des applications serveur qui doivent traiter un grand nombre de transactions très rapidement, avec des temps de réponse extrêmement courts. Nombre de ces applications sont orientées client et traitent donc les requêtes des utilisateurs. Si elles ne répondent pas rapidement aux demandes des clients, le coût pour l'entreprise est important, en termes de pertes de revenus et de mécontentement des clients.
Les applications .NET Core nécessitent une capacité d'évolution :
- Applications Web (ASP.NET Core) : Il s'agit généralement d'applications destinées aux clients, mais il peut également s'agir d'applications internes pour les grandes entreprises.
- Services Web (ASP.NET Core) : Celles-ci peuvent soit fournir directement des API Web aux clients, soit faire partie d'une autre application à transactions élevées contenant une logique de niveau application dans ces services Web.
- Applications Web en temps réel (ASP.NET Core SignalR) : Il s'agit d'applications temps réel qui doivent fournir des mises à jour fréquentes à leurs utilisateurs grâce au framework SignalR d'ASP.NET Core. Elles doivent également être performantes car elles sont généralement destinées aux clients.
- Microservices (.NET Core) : Il s'agit d'une nouvelle architecture d'application pour les applications côté serveur. Et tout comme les services Web, ces microservices font généralement partie d'une application Web orientée client ou d'une application de services Web orientée client. Par conséquent, ils ont également des exigences de haute performance sous de lourdes charges de transactions.
- Autres applications serveur (.NET Core) : Il existe une grande variété d'autres applications serveur qui doivent traiter très rapidement un grand nombre de transactions. Il peut s'agir d'applications de traitement par lots gérant divers types de flux de travail backend ou d'applications de traitement de flux ingérant une grande quantité de données pour un traitement en temps quasi réel. La liste continue.
Le problème : les goulots d'étranglement de l'évolutivité
Fait intéressant, toutes les applications mentionnées ci-dessus ont des architectures de niveau application très évolutives. Chacun d'eux vous permet d'évoluer de manière linéaire à mesure que votre charge de transaction augmente en ajoutant plus de serveurs, de machines virtuelles ou d'instances de conteneurs avec un équilibreur de charge.
Malgré une architecture très évolutive au niveau applicatif, les applications serveur .NET Core sont aujourd'hui confrontées à d'importants problèmes de scalabilité. Ces problèmes se manifestent dans différents domaines, notamment :
- Bases de données d'application (bases de données relationnelles) : C'est le plus gros goulot d'étranglement de tous. Je l'explique plus en détail ci-dessous.
- Stockage de session ASP.NET Core : Si les sessions sont stockées dans SQL Server, votre application ASP.NET Core sera confrontée à d'énormes goulots d'étranglement.
- Traitement répétitif des pages avec ASP.NET Core : Si les mêmes pages sont exécutées à plusieurs reprises et que leur sortie ou leur réponse reste la même, il s'agit d'un gaspillage de ressources et d'un goulot d'étranglement des performances.
- Fournisseur de fond de panier SignalR pour ASP.NET Core : Si une application Web en direct utilisant SignalR doit évoluer, son fournisseur de fond de panier peut facilement devenir un goulot d'étranglement.
- Messagerie Pub/Sub (pas en mémoire) : Si votre application .NET Core utilise la messagerie Pub/Sub, il y a de fortes chances qu'elle ne soit pas en mémoire et qu'elle constitue donc un goulot d'étranglement.
Goulot d'étranglement de la base de données relationnelle
Le principal goulot d'étranglement pour toutes les applications .NET Core à fort trafic est leur base de données. La plupart des applications utilisent encore aujourd'hui une base de données relationnelle comme SQL Server ou Oracle. Ces bases de données deviennent rapidement des freins à la scalabilité lorsque la charge transactionnelle augmente. Cela reste vrai, que vous utilisiez SQL Server sur une machine virtuelle ou Azure SQL Database.
Cela s'explique par le fait qu'une base de données relationnelle ne peut pas être partitionnée logiquement comme une base de données NoSQL et reste physiquement localisée ; même un partitionnement au niveau des colonnes est très différent d'un véritable partitionnement de type NoSQL. Par conséquent, il est impossible d'augmenter la capacité transactionnelle de la base de données en ajoutant des serveurs, comme c'est le cas pour une base de données NoSQL.
Par exemple, alors que votre niveau d'application peut facilement avoir 10, 20, 30 serveurs d'applications ou plus à mesure que votre charge de transaction augmente, votre niveau de base de données ne peut pas du tout croître de la même manière.
À cause de tout cela, votre base de données relationnelle devient un goulot d'étranglement pour toutes les données que vous y stockez (données d'application ou autres données).
Les optimisations en mémoire du serveur de base de données ne suffisent pas
SQL Server a introduit des optimisations en mémoire pour augmenter le nombre de transactions par seconde. Oracle a également fourni sa propre version des tables en mémoire.
Bien que les optimisations en mémoire améliorent les performances, elles ne résolvent pas le problème central de l'évolutivité linéaire. Les tables en mémoire sont généralement utilisées pour les données en lecture seule et afin de mettre à l'échelle une capacité de transaction en lecture seule, vous devez ajouter plus d'instances de SQL Server sur des machines haut de gamme.
Les tables en mémoire ont également des limitations sur la taille des données ; vous ne pouvez pas mettre de grandes tables en mémoire puisque toute la table doit être mise en mémoire. Et leur réplication vers d'autres instances de SQL Server ne peut être effectuée que vers d'autres tables en mémoire et non vers une base de données appropriée.
En résumé, ces optimisations en mémoire dans les bases de données SQL Server et Oracle ne permettent pas de répondre pleinement aux besoins d'évolutivité de votre application .NET Core.
Les bases de données NoSQL ne sont pas la solution.
L'une des raisons de la popularité des bases de données NoSQL est leur capacité à partitionner efficacement les données grâce à des algorithmes de hachage et autres techniques. Ceci résout de nombreux problèmes d'évolutivité liés à la capacité transactionnelle rencontrés par les bases de données relationnelles telles que SQL Server et Oracle.
Cependant, il existe des raisons pour lesquelles les bases de données NoSQL ne constituent pas la solution idéale pour ces goulots d'étranglement.
- Pas un magasin en mémoire : Les bases de données NoSQL, tout comme les bases de données relationnelles, stockent leurs données sur disque. Cela signifie que, quoi que vous fassiez, la lenteur du disque finira par constituer un goulot d'étranglement en termes de performances.
- Ne peut pas être utilisé la plupart du temps : Les bases de données NoSQL nécessitent l'abandon des bases de données relationnelles telles que SQL Server et Oracle, et leur remplacement par une base de données NoSQL. Dans la plupart des cas, cela s'avère impossible pour des raisons techniques et non techniques. En effet, votre activité dépend de votre base de données relationnelle et ne peut se permettre de l'abandonner facilement. Par conséquent, vous ne pouvez pas tirer pleinement parti des avantages d'une base de données NoSQL.
La solution : cache distribué en mémoire (NCache)
La solution à tous les problèmes mentionnés ci-dessus est d'utiliser un cache distribué en mémoire comme NCache dans le déploiement de votre application .NET Core. NCache Il s'agit d'un cache distribué open source pour .NET et .NET Core, extrêmement rapide et à scalabilité linéaire. Imaginez-le comme un système de stockage de données en mémoire distribué. Le stockage en mémoire lui confère une vitesse exceptionnelle, tandis que la distribution assure une scalabilité linéaire.
NCache est linéairement évolutif car il crée un cluster TCP de serveurs de cache à faible coût (même configuration que vos serveurs d'applications Web mais avec plus de mémoire) et regroupe la mémoire et les ressources CPU de tous ces serveurs en une seule capacité logique. NCache vous permet ensuite d'ajouter des serveurs de cache à ce cluster lors de l'exécution à mesure que votre charge de transaction augmente. Et depuis NCache Tout se déroule en mémoire, ce qui le rend ultra-rapide et vous offre des temps de réponse inférieurs à la milliseconde, chose que vous ne pouvez pas attendre de vos bases de données relationnelles ou même de vos bases de données NoSQL.
En plus de fournir une évolutivité linéaire, un cache distribué comme NCache réplique les données intelligemment afin que vos performances ne soient pas compromises tout en garantissant la fiabilité des données en cas de panne d'un serveur de cache.
NCache vous permet de faire évoluer vos applications .NET Core grâce aux éléments suivants :
- Mise en cache des données d'application
- Stockage de session ASP.NET Core
- Middleware de cache de réponse ASP.NET Core
- Fond de panier SignalR ASP.NET Core
- Messagerie Pub/Sub et événements CQ (en mémoire)
- Événements de requête continus (en mémoire)
Mise en cache des données d'application
Le principal goulot d'étranglement des applications .NET Core est la « base de données de l'application ». L'avantage de NCache c'est que, contrairement aux bases de données NoSQL, NCache ne vous demande pas d'arrêter d'utiliser votre base de données relationnelle existante. Vous pouvez continuer à utiliser SQL Server, Azure SQL Database, Oracle, etc. comme base de données tout en obtenant une évolutivité linéaire en utilisant NCache au-dessus de votre base de données relationnelle. Ceci est dû au fait NCache supprime tous les goulots d'étranglement de l'évolutivité de la base de données relationnelle, car contrairement à votre base de données, NCache est en fait linéairement évolutif.
La mise en cache des données d'application vous permet de supprimer les goulots d'étranglement de votre base de données. NCache vous permet de mettre en cache les données d'application et de réduire ces déplacements coûteux de la base de données. Vous pouvez vous attendre à détourner 80 à 90 % du trafic de la base de données vers NCache. Cela réduit la pression sur votre base de données et lui permet de fonctionner plus rapidement et de gérer des charges de transactions plus importantes sans ralentir.
La mise en cache des données d'application signifie que vous mettez en cache toutes les données d'application que vous obtenez de votre base de données relationnelle. Cela se présente généralement sous la forme d'objets de domaine (également appelés entités). Voici un exemple d'utilisation d'un cache distribué comme NCache pour la mise en cache des données d'application.
Customer Load(string custId)
{
ICache cache = CacheManager.GetCache("myCache");
string key = "Customer:CustomerID:" + custId;
Customer cust = cache.Get<Customer>(key);
if (cust == null)
{
// Item not in cache so load from db
LoadCustomerFromDb(cust);
// Add item to cache for future reference
cache.Add(key, cust);
}
return cust;
}Figure 3 : Utilisation du cache distribué en mémoire pour la mise en cache des données d'application
Stockage de session ASP.NET Core
Un autre goulot d'étranglement potentiel survient si vous stockez vos sessions ASP.NET Core dans SQL Server ou dans un cache mémoire autonome. Ces deux options présentent des limitations importantes en termes de performances et d'évolutivité. Le stockage SQL Server n'est pas adapté aux sessions ASP.NET Core et devient rapidement un goulot d'étranglement, tout comme pour les données de l'application.
NCache est un excellent endroit pour stocker vos sessions ASP.NET Core car il est beaucoup plus rapide et plus évolutif que les autres options de stockage. NCache Il est plus rapide car il s'exécute en mémoire et offre une interface clé-valeur où la valeur est un « objet », comme une session ASP.NET Core. De plus, il est évolutif car il s'agit d'un cache distribué.
Et, NCache Il réplique également intelligemment les sessions ASP.NET Core grâce à ses topologies de cache avancées, de sorte que même en cas de panne d'un serveur de cache, aucune donnée de session n'est perdue. Cette réplication est nécessaire car NCache fournit un magasin en mémoire et la mémoire viole le stockage.
NCache accélère également la sérialisation de la session ASP.NET Core, nécessaire avant son stockage hors processus. NCache Pour ce faire, elle utilise sa fonctionnalité de sérialisation compacte dynamique, 10 fois plus rapide que la sérialisation .NET et .NET Core classique. Vous pouvez utiliser cette fonctionnalité sans modifier votre code.
Vous pouvez utiliser NCache comme votre magasin de sessions ASP.NET Core de deux manières.
- IDistributedCache pour la session ASP.NET Core : NCache a implémenté l'interface IDistributedCache qui vous permet de brancher automatiquement NCache comme fournisseur de stockage de session pour ASP.NET Core. Cependant, cette option offre moins de fonctionnalités que l'autre.
- NCache Fournisseur pour la session ASP.NET Core : NCache a également implémenté son propre fournisseur de stockage de sessions ASP.NET Core plus complet que vous pouvez utiliser. Il offre davantage de fonctionnalités, notamment en matière de verrouillage, de délais d'expiration, etc.
Vous trouverez ci-dessous un exemple de configuration de votre application ASP.NET Core. NCache Fournisseur de sessions :
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Specify NCache as the session provider
services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
...
}
public void Configure(IApplicationBuilder app, ...)
{
// select NCache session provider for ASP.NET Core
app.UseNCacheSession();
...
}
}Figure 4 : Plug-in NCache en tant que sessions ASP.NET Core
Middleware de cache de réponse ASP.NET Core
Les applications ASP.NET Core, dont le contenu est généralement très dynamique, rencontrent des situations où le contenu ou la réponse de certaines pages reste inchangé malgré plusieurs requêtes. Or, ces pages doivent être exécutées à chaque requête, ce qui surcharge inutilement les ressources du serveur web et l'ensemble des couches de l'application. Il en résulte des goulots d'étranglement en termes de performances et une limitation de la scalabilité de l'application.
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Turn on ASP.NET Core Response Cache with IDistributedCache
services.AddResponseCaching();
// Select NCache as IDistributedCache provider
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
...
}
}Figure 5 : Plug-in NCache en tant que middleware de cache de réponse ASP.NET Core
Pour pallier la surcharge liée à l'exécution répétitive de pages dont la réponse ne change pas, ASP.NET Core propose un mécanisme de mise en cache des réponses de page appelé ASP.NET Response Cache Middleware. NCache a implémenté l'interface IDistributedCache dans ASP.NET Core, ce qui vous permet de vous connecter facilement. NCache en tant que middleware de cache de réponses ASP.NET Core.
Vous pouvez donc utiliser NCache Pour mettre en cache les réponses des pages ASP.NET Core pendant une certaine période, afin que lors du prochain appel à la même page avec les mêmes paramètres, cette réponse mise en cache puisse être renvoyée au lieu de réexécuter la page entière. Voici un exemple de code pour la configuration. NCache en tant que middleware de cache de réponses ASP.NET Core.
Fond de panier SignalR ASP.NET Core
Si votre application ASP.NET Core est une application web temps réel, elle utilise très probablement ASP.NET Core SignalR pour assurer ce comportement en temps réel. Les applications web temps réel fournissent des mises à jour fréquentes du serveur au client. Parmi ces applications, on peut citer les jeux, les ventes aux enchères, les systèmes de vote, les réseaux sociaux, etc.
Si votre application ASP.NET Core s'exécute dans un environnement multi-serveurs à charge équilibrée, elle doit utiliser un fournisseur de backplane SignalR ASP.NET Core pour partager les événements entre plusieurs serveurs web. Ce backplane doit être évolutif, sous peine de rencontrer des problèmes de performances.
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Specify NCache as the ASP.NET Core SignalR Backplane
services.AddSignalR().AddNCache(ncacheOptions =>
{ ncacheOptions.CacheName = "myPartitionedCache"; });
...
}
public void Configure(IApplicationBuilder app, ...)
{
// Use SignalR in ASP.NET Core
app.UseSignalR(config => { config.MapHub<MessageHub>("/messages"); });
...
}
}Figure 6 : Plug-in NCache en tant que fournisseur de fond de panier SignalR pour ASP.NET Core
NCache a implémenté un fournisseur de backplane SignalR pour ASP.NET Core. NCacheLe fournisseur de fond de panier SignalR d'ASP.NET Core utilise les fonctionnalités de messagerie Pub/Sub de NCache Ces événements sont extrêmement rapides car ils sont entièrement exécutés en mémoire. Cela permet à votre application ASP.NET Core SignalR d'accélérer la propagation des événements SignalR entre tous les serveurs web et, par conséquent, vers les clients.
Et cela rend votre application Web en temps réel plus réactive pour fournir ces mises à jour fréquentes aux clients. Et, vous pouvez continuer à augmenter le nombre de clients et également ajouter plus de serveurs Web sans craindre de goulots d'étranglement de performances.
Messagerie Pub/Sub (en mémoire)
Si votre application .NET Core utilise la messagerie Pub/Sub ou les événements, il est fort probable qu'elle utilise une plateforme de messagerie Pub/Sub qui n'est pas entièrement en mémoire et stocke tous les messages sur disque. Par conséquent, cela peut facilement créer un goulot d'étranglement en termes de performances si votre application génère un volume élevé de transactions.
NCache fournit également une messagerie Pub/Sub ultra-rapide car entièrement en mémoire. Et, il réplique tous les messages à un autre NCache serveur pour s'assurer qu'il n'y a pas de perte de données en cas de panne d'un serveur.
Par conséquent, si votre application .NET Core utilise NCache en tant que plate-forme de messagerie Pub/Sub, elle bénéficiera de performances ultra-rapides et d'une évolutivité linéaire car NCache elle-même est linéairement évolutive.
Vous trouverez ci-dessous un exemple d'utilisation de la messagerie Pub/Sub fournie par NCache dans votre application .NET Core.
private void PublishMessage (string topicName)
{
ITopic topic = _cache.MessagingService.GetTopic(topicName);
Order order = Order.GenerateOrder<Order>();
// Publish message containing "order" with expiry
Message message = new Message(order, new TimeSpan(0, 0, 15));
topic.Publish(message, DeliveryOption.All, true);
}
private ITopicSubscription SubscribeMessage (string topicName)
{
ITopic topic = _cache.MessagingService.GetTopic(topicName);
// Subscribes to the topic. Message delivered to MessageReceivedCallback
return topic.CreateSubscription(MessageReceivedCallback);
}
static void MessageReceivedCallback(object sender, MessageEventArgs args) { ... }Figure 7 : Utilisation de la messagerie Pub/Sub dans les applications .NET Core
Mise en cache des données d'application
Le principal goulot d'étranglement en matière de scalabilité que votre application .NET Core doit éliminer provient de la base de données. Dans ce domaine, la mise en cache des données permet à vos applications d'atteindre des performances élevées et une scalabilité linéaire. La raison est simple : la plupart des applications .NET Core effectuent d'importants échanges de données avec la base de données.
Gardez le cache frais
En ce qui concerne la mise en cache des données d'application, la plus grande crainte des utilisateurs est que le cache devienne obsolète, ce qui signifie qu'il contient une ancienne version des données qui a déjà été modifiée dans la base de données par un autre utilisateur ou une autre application.
- Données de référence vs données transactionnelles
Cette crainte qu'un cache devienne obsolète est si forte que la majorité des gens ne cachent que des données en lecture seule ou statiques (données de référence). Mais ces données en lecture seule ne représentent que 20 % du total des données sous la forme de tables de recherche et d'autres données de référence. La majeure partie des données de la base de données est transactionnelle, y compris les clients, les comptes, les activités, etc. Et, si vous ne mettez pas en cache ces données transactionnelles, vous ne bénéficiez pas pleinement de la mise en cache.
Ainsi, le véritable avantage de la mise en cache vient si vous pouvez mettre en cache tous les types de données sans craindre que la mise en cache ne devienne obsolète. NCache fournit une multitude de fonctionnalités pour résoudre ce problème.
- Synchroniser le cache avec la base de données
Le moyen le plus efficace de garder votre cache à jour est de toujours le synchroniser avec votre base de données. NCache vous permet de faire cela pour une variété de bases de données comme suit :
- Cache de synchronisation avec SQL Server : en utilisant SqlDependency et les notifications d'événements DB
- Synchroniser le cache avec Oracle : à l'aide d'OracleDependency et des notifications d'événements DB
- Cache de synchronisation avec Cosmos DB : à l'aide du traitement du flux de modification de Cosmos DB
- Synchroniser le cache avec n'importe quelle base de données (basé sur l'interrogation) : grâce à NCache fourni la synchronisation de la base de données basée sur l'interrogation.
Lorsque vous synchronisez votre cache avec SQL Server, vous demandez NCache pour s'enregistrer en tant que client de SQL Server, puis émettre un appel SqlDependency avec un ensemble de données basé sur une requête SQL. Ensuite, lorsque SQL Server voit des modifications dans cet ensemble de données, il notifie NCache à propos de ça
private static void CreateSqlDependency (Product product)
{
string connectionString = "Data Source=localhost;Database=northwind;...";
// SQL stmt on which the SQL Dependency is created in SQL Server
string sqlStmt = "SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice " +
"FROM dbo.PRODUCTS WHERE ProductID = " + product.Id;
CacheDependency sqlDependency = new SqlCacheDependency(connectionString, sqlStmt);
CacheItem cacheItem = new CacheItem(product) { Dependency = sqlDependency };
string key = "Product:ProductId:" + product.Id; ;
cache.Add(key, cacheItem);
}Figure 8 : Utilisation de SqlDependency pour synchroniser le cache avec SQL Server
Puis, NCache supprime cet élément du cache de sorte que la prochaine fois que l'application en aura besoin, elle devra récupérer la dernière copie de la base de données. Si vous utilisez le gestionnaire de lecture (voir ci-dessous), alors NCache peut également recharger automatiquement la dernière copie de la base de données pour vous. Vous trouverez ci-dessous un exemple d'utilisation de SqlDependency pour synchroniser votre cache avec SQL Server.
Cache de lecture et d'écriture
Le cache de lecture est un cache capable de lire les données de votre base de données en appelant un gestionnaire de lecture que vous avez développé et fourni au cache. De même, un cache d'écriture immédiate est capable d'écrire des modifications de données dans votre base de données en appelant un gestionnaire d'écriture immédiate que vous avez développé et fourni au cache. Write-behind Cache est identique à Write-through sauf que les mises à jour de la base de données sont effectuées de manière asynchrone.
Les modes de lecture directe, d'écriture directe et d'écriture différée offrent de nombreux avantages à vos applications .NET Core, notamment :
- Simplifiez le code de l'application : Déplacez le code de persistance de votre application vers le niveau de mise en cache.
- Recharger automatiquement les éléments à partir de la base de données : Utilisez la lecture à l'expiration ou au moment de la synchronisation de la base de données.
- Ecriture plus rapide : Utilisez des écritures de base de données asynchrones avec écriture différée.
Vous trouverez ci-dessous un exemple de la façon dont vous pouvez utiliser Read-through avec NCache.
// Read through handler for SQL Server
public class SqlReadThruProvider : Runtime.DatasourceProviders.IReadThruProvider
{
public void Init(IDictionary parameters, string cacheId) {}
public void Dispose() {}
// Get object from the database/data-source based on the key
public ProviderCacheItem LoadFromSource(string key) {}
// Bulk-Get objects from the database/data-source based on the keys
public IDictionary<string, ProviderCacheItem> LoadFromSource(ICollection<string> keys)
{}
}Figure 9 : Utilisation du gestionnaire de lecture avec NCache
Rechercher dans la cache
Une fois que vous êtes à l'aise avec la mise en cache de toutes les données, vous pouvez commencer à mettre beaucoup de données dans un cache distribué. Ici, vous pouvez commencer à faire face à un autre problème particulier, à savoir comment trouver rapidement et facilement vos données. Étant donné que la plupart des caches distribués sont des magasins clé-valeur, il devient très difficile de suivre toutes vos données uniquement via des clés.
C'est ici que NCache vous offre une variété de façons de trouver rapidement des données à partir de votre cache. Les exemples comprennent:
- Données de groupe dans le cache (groupe/sous-groupe, balises, balises nommées) : NCache vous offre plusieurs façons de regrouper vos données de manière logique et de récupérer ultérieurement l'ensemble du groupe en un seul appel. Cela simplifie vraiment la gestion de vos données.
- Rechercher des données avec des requêtes (SQL / LINQ) : en plus de rechercher des données basées sur des appels d'API de groupe, NCache vous donne également la possibilité de rechercher dans le cache des données basées sur des attributs d'objet, des groupes, des balises et des balises nommées.
- Recherches parallèles : Depuis NCache est de nature distribuée, lorsque votre application émet une requête de recherche ou un appel d'API de recherche, cette requête est exécutée en parallèle sur tous les serveurs de cache. Ensuite, les résultats de tous les serveurs sont renvoyés à la machine cliente (c'est-à-dire le serveur d'application) où ils sont fusionnés avant de renvoyer les résultats finaux à votre application. Cela accélère vraiment vos recherches dans le cache.
Vous trouverez ci-dessous un exemple de la façon dont vous pouvez utiliser des requêtes basées sur LINQ avec NCache.
// Search the cache based on object attributes by using LINQ
IQueryable>Product< products = new NCacheQuery<Product>(_cache);
var result = from product in products
where product.Id > 10
select product;
if (result != null)
{
foreach (Product p in result1)
{
// Process each “product” fetched from the database
Console.WriteLine("ProductID : " + p.Id);
}
}Figure 10 : Utilisation des requêtes LINQ avec NCache
NCache Architecture pour une évolutivité extrême
Les applications .NET Core à fort trafic ne peuvent se permettre aucune interruption de service, surtout aux heures de pointe. Pour ce type d'applications, trois objectifs architecturaux essentiels sont atteints grâce à un cache distribué en mémoire performant. NCache remplit.
- Cache client (vitesse InProc)
- Évolutivité linéaire avec réplication rapide
- Haute disponibilité grâce au clustering dynamique
Laissez-moi vous expliquer chacun ci-dessous.
Cache client (vitesse InProc)
NCache fournit un cache client qui est un cache local très proche de votre application. Il peut s'agir d'InProc (c'est-à-dire qu'il réside dans votre processus de candidature) ou d'OutProc local. Dans tous les cas, il fournit un accès très rapide à un sous-ensemble des données mises en cache dont votre application sur ce serveur d'applications a besoin à ce moment. Le cache client reste en même temps synchronisé avec le niveau de mise en cache afin que toutes les données modifiées par d'autres utilisateurs ou applications dans le niveau de mise en cache soient immédiatement propagées au cache client. Le client vous permet d'avoir une vitesse InProc tout en faisant partie d'un niveau de mise en cache très évolutif.
Évolutivité linéaire avec réplication rapide
L'un des objectifs architecturaux les plus importants de NCache est d'atteindre une évolutivité linéaire avec la fiabilité des données grâce à ses topologies de mise en cache. Voilà quelque NCache Topologies de mise en cache qui aident à atteindre ces deux objectifs.
- Cache partitionné : NCache partitionne le cache en fonction du nombre de serveurs de cache et attribue une partition à chaque serveur de cache. Il ajuste également le nombre de partitions lorsque vous ajoutez ou supprimez des serveurs de cache lors de l'exécution. Le partitionnement est le principal moyen d'assurer une évolutivité linéaire, car à mesure que vous ajoutez des serveurs, cette topologie de mise en cache augmente la taille de stockage globale ainsi que la puissance de traitement du processeur.
- Cache de réplica partitionné : Outre le partitionnement, NCache fournit également des répliques pour chaque partition. Ces répliques résident sur des serveurs de cache différents de la partition elle-même pour garantir que si un serveur de cache tombe en panne avec sa partition, la réplique devient immédiatement disponible. De cette façon, la fiabilité des données est assurée. En répliquant chaque partition une seule fois sur un autre serveur de cache, NCache assure la fiabilité des données sans compromettre l'évolutivité linéaire.
Haute disponibilité pour une disponibilité à 100 %
L'un des objectifs architecturaux les plus importants de NCache est d'obtenir une haute disponibilité et une élasticité du cache. Pour ce faire, il utilise les fonctionnalités architecturales suivantes :
- Cluster de cache peer-to-peer à réparation automatique : NCache construit un cluster de serveurs de cache sur TCP/IP. Ce cluster a un architecture pair à pair cela signifie qu'il n'y a pas de nœuds maître/esclave et pas de clustering majoritaire. Au lieu de cela, chaque nœud est un pair égal. Cela permet NCache pour gérer les situations où n'importe quel nœud pourrait tomber en panne et le cluster s'ajuste automatiquement et continue de fonctionner, et il n'y a pas d'interruption pour votre application.
- Paramétrage dynamique : Cela signifie que vous n'avez pas besoin de coder en dur les éléments dans les fichiers de configuration. NCache propage les informations de configuration à tous les clients de cache (c'est-à-dire vos applications) lors de l'exécution.
- Prise en charge du basculement de connexion : Si un serveur de cache tombe en panne, l'ensemble du cluster de cache et tous les clients de cache peuvent continuer à fonctionner sans aucune interruption. Les clients de cache continuent de fonctionner en interagissant avec d'autres serveurs de cache du cluster.