La mise en cache distribuée a été reconnue comme une partie importante et intégrale des applications Web .NET hautes performances. Cela est vrai pour les applications des utilisateurs finaux qui exigent un temps de réponse rapide de la part des services de niveau intermédiaire déployés ou des composants Web. Pour ces raisons, Microsoft a introduit AppFabric, un cache distribué en mémoire, pour améliorer les performances et l'évolutivité des applications utilisant le .NET Framework.
AppFabric la mise en cache a été principalement utilisée pour stocker les données d'état de session ASP.NET et pour fournir des fonctionnalités de base de mise en cache d'objets. Mais même si la mise en cache fait partie intégrante de tout système N-Tier, Microsoft a blogué que AppFabric le soutien se termine au 11 avril 2017 pour toutes les versions. C'est une bonne incitation pour les piles .NET employant AppFabric pour passer à un meilleur cache distribué, pris en charge.
Alors, qu'est-ce que la fin prend en charge signifie en fait? Ça veut dire:
Par conséquent, cela signifie que vous utiliserez AppFabric à vos risques et périls. Microsoft ne sera pas responsable des incidents ou des bogues. Pour cette raison, nous devons évaluer si les opérations commerciales peuvent supporter des temps d'arrêt en raison d'un bogue sans résolution rapide.
De telles questions peuvent vous conduire vers des alternatives. Si vous êtes prêt pour une alternative, il en existe une qui permet une migration transparente de votre configuration actuelle vers un cache distribué .NET avec des modifications de code minimales, n'introduisant donc aucun bogue. Ce cache distribué alternatif prend non seulement en charge la migration transparente, mais il est également plus rapide et offre plus de fonctionnalités que AppFabric.
NCache est un choix fort comme alternative. Microsoft a en fait recommandé NCache dans leur annonce fin AppFabric soutien. NCache a obtenu cette recommandation car il est largement utilisé au sein de la communauté .NET et a été le leader du marché de la mise en cache distribuée .NET pour 10 années consécutives. NCache offre des performances exceptionnelles ainsi qu'un large éventail de fonctionnalités, notamment :
Autres avantages de NCache incluent la facilité d'utilisation (il est classé par un cabinet d'analystes de premier plan comme le cache distribué le plus facile à utiliser) de solides capacités de gestion et de surveillance grâce à ses outils d'interface graphique spécialement conçus et il est disponible en Open Source (sur GitHub) avec un coût pratiquement nul avant et après la migration. L'Open Source et la version Enterprise, avec support officiel, sont disponibles sur site et dans le cloud (Amazon Web Services et Azure).
Tandis que Redis est un bon cache en mémoire, le Redis la communauté note que Redis n'est pas prêt pour Windows, malgré la disponibilité d'un Redis Port Windows. Redis n'est pas entièrement évolutif et n'offre pas de fonctionnalités de haute disponibilité. Redis' L'ensemble d'outils de surveillance et de gestion est CLI uniquement. NCache offre de nombreux avantages par rapport Redis comme le montre ce lien vidéo (et cette diapositive partage guide intelligent) y compris.
Pour répondre aux besoins de tout environnement d'exploitation, NCache fournit trois façons de migrer des applications .NET depuis AppFabric à NCache; chaque méthode ayant son propre ensemble d'avantages.
Les trois méthodes de migration sont :
NCache AppFabric Les wrappers offrent une migration plus fluide et plus transparente, mais la migration via des appels API directs offre plus de contrôle et vous permet de profiter de toutes les fonctionnalités de NCache.
Pour les organisations à la recherche de la transition la plus simple et la plus rapide de AppFabric, ce wrapper offre la migration la plus simple qui soit. Seules trois modifications mineures sont nécessaires dans l'application .NET pour la rendre NCache conforme sans introduire de bugs possibles du tout. Ces changements sont :
<appSettings>
<add key="region1" value="myPartitionedCache"/>
<add key="Expirable" value="True"/>
<add key="TTL" value="5"/>
</appSettings>using Microsoft.ApplicationServer.Caching.Client;
using Microsoft.ApplicationServer.Caching.core;
avec:
using Alachisoft.NCache.Data.Caching;Et c'est tout! Aucune autre modification de code n'est nécessaire dans l'application .NET.
En utilisant NCache Open Source vous permet de migrer depuis AppFabric sans frais puisque les deux produits sont gratuits. NCache Open Source a un ensemble de fonctionnalités plus limité par rapport à l'édition Enterprise, mais sans aucune dégradation des performances du cache principal.
Pour faciliter la migration, une version distincte du AppFabric l'emballage est fourni pour NCache OSS, qui est compatible avec l'API open source. Compte tenu de moins de fonctionnalités dans NCache Open Source, NCache Open Source wrapper contourne les fonctionnalités manquantes, notamment :
La NCache Open Source wrapper pour AppFabric surmonte le défi de maintenir la gestion des versions des éléments en encapsulant chaque objet dans une autre classe. Cela se fait en introduisant une nouvelle classe nommée MetaDataCapsule dans le wrapper modifié.
namespace Alachisoft.NCache.Data.Caching.Util
{
[Serializable]
class MetaDataCapsule
{
private object value;
public ItemVersion CacheItemVersion { get; set; }
public string Group { get; set; }
public object Value { get { return this.value; } }
private MetaDataCapsule(object value, ItemVersion version, string group)
{
this.CacheItemVersion = version;
this.Group = group;
this.value = value;
}
public static MetaDataCapsule Encapsulate(object value, string region)
{
return new MetaDataCapsule(value, 1, region);
}
}
}Cela permet de conserver la version d'élément d'un objet et de transporter d'autres informations utiles si nécessaire. La classe est marquée comme sérialisable car elle doit voyager sur le réseau.
Pour garantir la cohérence de la version d'élément et de l'objet dans toutes les multiples instances d'applications différentes ou similaires, un verrouillage distribué est utilisé. Le verrouillage distribué est une caractéristique de NCache qui permet à plusieurs applications d'accéder à la même ressource et de la modifier sans compromettre la cohérence des données et en évitant toute condition de concurrence possible.
LockHandle lockhandle = null;
MetaDataCapsule oldMetadata;
bool lockAcquired = GetLock(_key, ref lockhandle, out oldMetadata);
if(!lockAcquired)
{
_NCache.Unlock(key);
throw new DataCacheException("Unable to acqurie lock to update Item Version");
}
//Return in case of version provided
if (oldVersion != null && oldMetadata.CacheItemVersion == oldVersion._itemVersion)
{
_NCache.Unlock(key);
return null;
}
if (lockAcquired)
(_item.Value as MetaDataCapsule).CacheItemVersion = ++metadata.CacheItemVersion;
_NCache.Insert(_key, _item, lockhandle, true);En résumé, à chaque opération Put :
Le verrouillage dans le scénario ci-dessus garantira qu'aucune autre application ne pourra mettre à jour ou supprimer l'élément si une autre application tente de modifier la même clé.
Dans le code ci-dessus, il existe une méthode nommée GetLock, l'implémentation est la suivante.
// <summary>
// Tries to acqurie lock and return LockHandle and MetaDataCapsule object.
// If LockHandle is provided uses that instead.
// <para>Default Lock Timeout (default 5 seconds), Retry Count (default 3)
// and retry interval (default 100 ms) is set when Cache Handler is instantiated.
// </para>
// </summary>
// <param name="key">Formatted Key i.e compile from formatter</param>
// <param name="lockHandle">Either provide a lock or keep it null to acquire a new lock
// </param>
// <param name="metadata">The returned object for internal use</param>
// <returns>true if lock was acquired</returns>
internal bool GetLock(string key, ref LockHandle lockHandle,
out MetaDataCapsule metadata)
{
//Item is locked
int count = _retries;
while (count != 0)
{
//If lock was provided attempt to acquire the lock from the given handle
if (lockHandle == null)
{
lockHandle = new LockHandle();
}
object obj = _NCache.Get(key, _defaultLockTime, ref lockHandle, true);
//obj is null of the lock was not acquired
if (obj == null)
{
count--;
Thread.Sleep(_retryTimeOut);
}
else
{
metadata = obj as MetaDataCapsule;
return true;
}
}
lockHandle = null;
metadata = null;
return false;
}La méthode GetLock tentera d'acquérir le verrou trois fois. En cas d'échec, il renverra "null" laissant la méthode appelante gérer cette exception. Ainsi, avec l'aide du verrouillage distribué, le AppFabric wrapper pour NCache Open Source conserve la version de l'élément de cache insérée par les applications clientes, y compris les cas d'exception.
En raison de l'absence de certaines fonctionnalités d'entreprise dans l'édition open source, les fonctions suivantes sont marquées "obsolètes" et marquées avec "lancer une erreur de compilation" pour assurer un changement de code et éviter toute surprise.
Par conséquent, si votre application dépend fortement de ces fonctionnalités, sélectionnez NCache Enterprise version pourrait être la meilleure option pour permettre une migration plus fluide, transparente et sans bogue.
Pour les développeurs qui souhaitent tirer pleinement parti de nombreux NCache Enterprise fonctionnalités, vous préférerez peut-être appeler directement le NCache API au lieu d'utiliser le wrapper. Vous pouvez également utiliser la "méthode de déballage" de la AppFabric wrapper pour travailler directement avec NCache également.
Dans tous les cas, il est recommandé d'effectuer votre migration en deux phases. Dans la phase 1, continuez à utiliser votre AppFabric fonctionnalités, mais remplacez votre cache par NCache. Dans la phase 2, mettre en œuvre de nouvelles NCache fonctionnalités qui n'étaient pas disponibles dans AppFabric.
Dans cette phase, votre objectif est simplement de remplacer AppFabric. Par conséquent, il est important de comprendre le comportement de ces deux caches distribués (voir plus de détails ci-dessous et dans le section de référence à la fin). Comme mentionné, AppFabric stocke les données dans des régions sur des machines spécifiques. D'autre part, pour répliquer les données de votre région dans NCache vous pouvez créer un cache pour chaque AppFabric région, ou vous pouvez créer NCache groupes à tenir AppFabric données de la région.
NCache Les groupes/sous-groupes offrent différentes manières de regrouper les éléments mis en cache. Comme les régions résident dans un cache nommé, NCache utilise des groupes pour reproduire ce comportement. La seule différence est que dans AppFabric une clé doit être unique uniquement dans une région et non dans l'ensemble du cache nommé. Alors qu'en NCache, la clé doit être unique dans tout le cache et peu importe le groupe auquel elle appartient. Cet obstacle peut être rapidement surmonté si les noms de région sont ajoutés à chaque touche.
Par exemple :
In AppFabric, une opération d'ajout de base ressemble à ceci :
// AppFabric API
regionCache.Add(stringKey, stringValue);Et dans NCache la commande de base n'est pas différente, sauf qu'un nom de région peut être spécifié en tant que groupe dans la commande :
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
Ici, chaque clé est précédée du nom de la région pour obtenir l'unicité parmi les clés de cache. Un groupe est affecté à la clé pour une récupération plus rapide ou pour faciliter la récupération des données à l'aide de requêtes SQL lors de l'exécution d'opérations de recherche.
L'autre façon de regrouper les éléments mis en cache consiste à supprimer complètement la corrélation région-groupe et à utiliser un cache distinct pour chaque région. Pour obtenir le même résultat, où chaque région se voit attribuer un cache séparé, une carte des noms de région correspondant aux caches peut être stockée.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);Dans cet exemple, il n'est pas nécessaire d'ajouter la clé de région à la clé de cache puisque les caches dans NCache sont mutuellement exclusifs même s'ils résident dans le même cluster.
Si votre application doit gérer de nombreuses régions (par exemple plus de 15), alors il est préférable d'utiliser les régions en tant que groupes puisque 15 caches par cluster est un nombre maximum de caches recommandé (même si un cluster peut logiquement héberger un nombre infini de caches) .
Dans la phase suivante, vous pouvez profiter des fonctionnalités qui NCache fournit ce qui AppFabric ainsi que Redis manquer de. Des fonctionnalités telles que :
La synchronisation de la base de données est une fonctionnalité très importante pour tout bon cache distribué. Étant donné que la plupart des données mises en cache proviennent d'une base de données relationnelle, il existe toujours des situations où d'autres applications ou utilisateurs peuvent modifier les données et rendre les données mises en cache obsolètes.
Les applications veulent souvent récupérer un sous-ensemble de ces données et si elles peuvent rechercher dans le cache distribué avec un langage de requête de type SQL et spécifier des attributs d'objet dans le cadre des critères, cela rend le cache distribué beaucoup plus utile pour elles.
De nombreuses personnes utilisent le cache distribué comme "cache sur le côté" où ils récupèrent les données directement de la base de données et les mettent dans le cache. Une autre approche est le "cache through" où votre application demande simplement au cache les données. Et, si les données ne sont pas là, le cache distribué les obtient de votre source de données. La même chose vaut pour l'écriture.
Avec cela, NCache prend également en charge MapReduce qui permet l'analyse de Big Data dans les données en mémoire, produisant des résultats en temps quasi réel.
Le cache client est simplement un cache InProc/OutProc local sur la machine cliente, mais qui reste connecté et synchronisé avec le cluster de cache distribué. De cette façon, les performances des applications bénéficient réellement de cette "proximité" sans compromettre l'intégrité des données.
La réplication WAN est une fonctionnalité importante car de nombreuses applications sont déployées dans plusieurs centres de données, soit à des fins de reprise après sinistre, soit pour équilibrer la charge du trafic régional.
L'idée derrière la réplication WAN est qu'elle ne doit pas ralentir le cache dans chaque emplacement géographique en raison de la latence élevée du WAN. NCache fournit Bridge Topology pour gérer tout cela.
Prise en charge de Microsoft AppFabric se termine en avril 2017. Ce livre blanc présente trois façons possibles de migrer des applications .NET depuis AppFabric à NCache, et les avantages de faire ce changement. NCache est un cache .NET stable, complet et distribué disponible en Open Source dans Azure et Amazon Web Services, ainsi que sur le NCache site Internet. Un support complet est également disponible.
Utiliser le gratuit NCache AppFabric emballage pour soit NCache Open Source or NCache Enterprise, offre la méthode de migration la plus simple, sans codage et sans bogue. Migrer en appelant directement le NCache L'API fournit plus de contrôle des données et permet à tous NCache fonctionnalités. Toutes les méthodes de migration sont décrites dans ce livre blanc.
Veuillez consulter ces ressources supplémentaires pour répondre à vos besoins en matière d'évaluation et de produit.
Régions in AppFabric sont des conteneurs logiques de paires clé-valeur stockées dans une instance d'un cache, qui est lié à une machine serveur. Pour cette raison, les données à l'intérieur des régions ne peuvent pas être distribuées. Cette structure architecturale prétend permettre des récupérations plus rapides. Mais cela réduit considérablement les performances globales par rapport à un cache distribué.
NCache est un cache distribué en son cœur. Toutes les données à l'intérieur NCache est distribué et une copie de sauvegarde est conservée sur une autre machine physique si le Réplique de partition La topologie (PR) est utilisée. PR fournit des performances ultra-rapides de classe mondiale et des répliques de basculement pour une perte de données nulle.
Ainsi, les régions de AppFabric sont configurés en tant que caches distincts dans NCache sans compromettre la capacité de récupération de données. Le AppFabric wrapper prend en charge cette complexité et stocke automatiquement toutes les données de région dans le nom de cache fourni. La seule exigence est que les caches dans NCache devrait préexister. Vous créez des caches via NCache Gérante, un outil de gestion de cluster basé sur une interface graphique. Une fois les caches créés, les données résidant dans AppFabric les régions sont distribuées aux NCache groupes). Bien que les données soient réellement distribuées, il n'y a aucun compromis dans votre capacité à exécuter des recherches avancées, y compris l'interrogation SQL (l'interrogation SQL n'est pas disponible avec AppFabric du tout).
L'autre différence notable entre NCache ainsi que AppFabric est la façon dont les deux produits sont configurés. AppFabric est configuré par l'application au moment de l'exécution (même la création du cache) et en revanche NCache est configuré avant le démarrage du cache. Par exemple, les topologies de cache ne peuvent pas être modifiées au moment de l'exécution, tandis que d'autres configurations, telles que les expirations par défaut du cache, etc., peuvent être modifiées ultérieurement et sont appelées hotapply-able. Bien que NCache peut être géré à l'aide de l'application .NET (y compris la création de cache) mais il est préférable de gérer depuis le NCache Gestionnaire - Un outil unique dédié à la gestion des clusters de cache. Un cache peut également être créé, configuré et maintenu à partir de la CLI.
Tandis que NCache AppFabric-wrapper fournit le moyen le plus simple de migrer des applications .NET vers NCache, qui est également avec le moins de changements de code possible, certains développeurs préfèrent encore profiter de toutes les fonctionnalités qui NCache doit offrir. C'est là qu'appeler directement le NCache L'API aide. Il est également possible d'utiliser les deux méthodes en appelant la méthode Unwrap à partir du AppFabric emballage.
La AppFabric cluster n'est pas complètement dynamique. Dépendance à "règle de la majorité des hôtes principaux" signifie que le cluster peut tomber très facilement si même un hôte principal tombe en panne. Ces nœuds hôtes principaux ressemblent également à une architecture "maître" et "esclave" et ne sont donc pas entièrement peer to peer également.
NCache alors que très dynamique et vous permet d'ajouter ou de supprimer des serveurs de cache au moment de l'exécution sans aucune interruption du cache ou de votre application. Les données sont automatiquement rééquilibrées (appelées transfert d'état) au moment de l'exécution sans interruption ni dégradation des performances. NCache les clients continuent de communiquer avec les serveurs de cache, indépendamment de l'état du serveur. Les clusters garantissent l'exécution des opérations client même lorsque l'équilibrage des données est en cours.
Cela signifie que même pour NCache, il n'y a pas de nœuds "maître" ou "esclave" dans le cluster. Il existe un nœud « coordinateur principal » qui est le nœud le plus ancien. Et, s'il tombe en panne, le nœud le plus ancien suivant devient automatiquement le coordinateur principal. Tout cela se produit sans aucune interruption des opérations du client.