El almacenamiento en caché distribuido ha sido reconocido como una parte importante e integral de las aplicaciones web .NET de alto rendimiento. Esto es válido para aquellas aplicaciones de usuario final que exigen un tiempo de respuesta rápido de los servicios o componentes web de nivel medio implementados. Por estas razones, Microsoft introdujo AppFabric, un caché distribuido en memoria, para proporcionar un impulso de rendimiento y escalabilidad para las aplicaciones que utilizan el .NET Framework.
AppFabric el almacenamiento en caché se ha utilizado principalmente para almacenar datos de estado de sesión de ASP.NET y para proporcionar funciones básicas de almacenamiento en caché de objetos. Pero a pesar de que el almacenamiento en caché es una parte integral de cualquier sistema N-Tier, Microsoft escribió en su blog que AppFabric extremos de apoyo a partir del 11 de abril de 2017 para todas las versiones. Este es un buen incentivo para las pilas .NET que emplean AppFabric para pasar a una memoria caché mejor, compatible y distribuida.
Entonces, ¿qué es el soporte final? realmente significa? Significa:
Por lo tanto, significa que usará AppFabric bajo tu propio riesgo. Microsoft no será responsable de contratiempos o errores. Debido a esto, tenemos que evaluar si las operaciones comerciales pueden soportar el tiempo de inactividad debido a un error que no se resuelve rápidamente.
Tales preguntas pueden llevarlo hacia alternativas. Si está listo para una alternativa, hay una que proporciona una migración sin problemas desde su configuración actual a una caché distribuida de .NET con cambios mínimos de código, por lo que no presenta ningún error. Esta caché distribuida alternativa no solo admite la migración sin problemas, sino que también es más rápida y ofrece más funciones que AppFabric.
NCache es una opción fuerte como alternativa. Microsoft de hecho recomendado NCache en su anuncio fin AppFabric apoyo. NCache obtuvo esta recomendación ya que se usa ampliamente dentro de la comunidad .NET y ha sido el líder del mercado en almacenamiento en caché distribuido .NET para 10 años corriendo. NCache proporciona un rendimiento excepcional junto con una amplia gama de características que incluyen:
Otros beneficios de NCache incluyen la facilidad de uso (está calificado por una firma de analistas líder como el caché distribuido más fácil de usar) sólidas capacidades de administración y monitoreo a través de sus herramientas GUI especialmente diseñadas y está disponible como código abierto (en GitHub) con un costo prácticamente nulo antes y después de la migración. Open Source y la versión Enterprise, con soporte oficial, están disponibles on premise y en la nube (Amazon Web Services y Azure).
Aunque la Redis es un buen caché In-Memory, el Redis la comunidad nota que Redis no está preparado para Windows, a pesar de la disponibilidad de un Redis Puerto de Windows. Redis no es completamente escalable ni ofrece características de alta disponibilidad. RedisEl conjunto de herramientas de monitoreo y administración es solo CLI. NCache proporciona muchas ventajas sobre Redis como se muestra en este enlace de video (y esta diapositiva compartida guía inteligente) incluido.
Para satisfacer las necesidades de cualquier entorno operativo, NCache proporciona tres formas de migrar aplicaciones .NET desde AppFabric a NCache; cada método tiene su propio conjunto de ventajas.
Los tres métodos de migración son:
NCache AppFabric Los contenedores ofrecen una migración más fluida y fluida, pero la migración a través de llamadas API directas brinda más control y le permite aprovechar todas las características de NCache.
Para aquellas organizaciones que buscan la transición más fácil y rápida de AppFabric, este contenedor proporciona la migración más sencilla jamás vista. Solo se requieren tres cambios menores en la aplicación .NET para que sea NCache compatible sin introducir ningún posible error en absoluto. Estos cambios son:
<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;
con:
using Alachisoft.NCache.Data.Caching;¡Y eso es! No es necesario ningún otro cambio de código dentro de la aplicación .NET.
Usar NCache Open Source le permite migrar desde AppFabric sin costo ya que ambos productos son gratuitos. NCache Open Source tiene un conjunto de funciones más limitado en comparación con la edición Enterprise, pero sin ninguna degradación en el rendimiento de la memoria caché central.
Para facilitar la migración, una versión separada del AppFabric se proporciona envoltorio para NCache OSS, que es compatible con la API de código abierto. Dadas menos características en NCache Open Source, la NCache Open Source wrapper soluciona las características que faltan, que incluyen:
El NCache Open Source envoltorio para AppFabric supera el desafío de mantener el control de versiones de elementos al encapsular cada objeto dentro de otra clase. Esto se hace introduciendo una nueva clase llamada MetaDataCapsule en el contenedor modificado.
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);
}
}
}Esto ayuda a mantener la versión de elemento de un objeto y llevar otra información útil si es necesario. La clase está marcada como Serializable ya que necesita viajar a través de la red.
Para garantizar la consistencia de la versión del elemento y del objeto en todas las múltiples instancias de aplicaciones diferentes o similares, se utiliza el bloqueo distribuido. El bloqueo distribuido es una característica de NCache lo que permite que múltiples aplicaciones accedan y modifiquen el mismo recurso sin comprometer la consistencia de los datos y evitando cualquier posible condición de carrera.
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 resumen, en cada operación Put:
El bloqueo en el escenario anterior garantizará que ninguna otra aplicación pueda actualizar o eliminar el elemento si otra aplicación intenta modificar la misma clave.
En el código anterior, hay un método llamado GetLock, la implementación es la siguiente.
// <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;
}El método GetLock intentará adquirir el bloqueo tres veces. Si falla, devolverá "nulo" y permitirá que el método de llamada maneje esta excepción. Así, con la ayuda de Distributed Locking, el AppFabric envoltorio para NCache Open Source mantiene la versión del elemento de caché insertado por las aplicaciones cliente, incluidos los casos de excepción.
Debido a la falta de algunas funciones empresariales en la edición de código abierto, las siguientes funciones están marcadas como "obsoletas" y marcadas con "arrojar error de compilación" para garantizar un cambio de código y evitar sorpresas.
Por lo tanto, si su aplicación depende en gran medida de estas funciones, seleccione NCache Enterprise podría ser la mejor opción para permitir una migración más fluida, sin problemas y sin errores.
Para los desarrolladores que quieren aprovechar al máximo muchas NCache Enterprise funciones, es posible que prefiera llamar directamente al NCache API en lugar de usar el contenedor. También puede usar el 'método de desenvolver' de la AppFabric envoltorio para trabajar directamente con NCache .
De cualquier manera, se recomienda realizar la migración en dos fases. En la fase 1, continúa usando tu AppFabric características, pero reemplace su caché con NCache. En la Fase 2, implementar nuevas y adicionales NCache características que no estaban disponibles en AppFabric.
En esta fase, su enfoque es solo reemplazar AppFabric. Por lo tanto, es importante comprender cómo se comportan estos dos cachés distribuidos (ver más detalles a continuación y en el sección de referencia al final). Como se mencionó, AppFabric almacena datos en regiones en máquinas específicas. Por otro lado, para replicar los datos de su región en NCache puedes crear un caché para cada AppFabric región, o puede crear NCache grupos para celebrar AppFabric datos de la región.
NCache Grupos/Subgrupos proporciona varias formas de agrupar elementos almacenados en caché. Como las regiones residen dentro de un caché con nombre, NCache utiliza grupos para reproducir este comportamiento. La única diferencia es que en AppFabric una clave debe ser única solo dentro de una región y no dentro de todo el caché con nombre. Mientras en NCache, la clave debe ser única en todo el caché y no importa a qué grupo pertenezca. Este obstáculo se puede superar rápidamente si los nombres de las regiones se anteponen a cada clave.
Por ejemplo:
In AppFabric, una operación Add básica tiene el siguiente aspecto:
// AppFabric API
regionCache.Add(stringKey, stringValue);Y en NCache el comando básico no es diferente, excepto que se puede especificar un nombre de región como un grupo en el comando:
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
Aquí, cada clave se antepone con el nombre de la región para lograr la unicidad entre las claves de caché. Se asigna un grupo a la clave para una recuperación más rápida o para facilitar la recuperación de datos mediante consultas SQL al realizar operaciones de búsqueda.
La otra forma de agrupar elementos almacenados en caché es descartar por completo la correlación de región a grupo y usar una caché separada para cada región. Para obtener el mismo resultado, donde a cada región se le asigna un caché separado, se puede almacenar un mapa de nombres de regiones correspondientes a los cachés.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);En este ejemplo, no es necesario anteponer la clave de región a la clave de caché, ya que las cachés en NCache son mutuamente excluyentes incluso si residen en el mismo clúster.
Si su aplicación debe manejar muchas regiones (por ejemplo, más de 15), entonces es mejor usar regiones como grupos, ya que 15 cachés por clúster es una cantidad máxima recomendada de cachés (aunque un clúster puede albergar lógicamente una cantidad infinita de cachés) .
En la siguiente fase, puede aprovechar las características que NCache proporciona que AppFabric y Redis falta. Características tales como:
La sincronización de la base de datos es una característica muy importante para cualquier buen caché distribuido. Dado que la mayoría de los datos que se almacenan en caché provienen de una base de datos relacional, siempre hay situaciones en las que otras aplicaciones o usuarios pueden cambiar los datos y hacer que los datos almacenados en caché se vuelvan obsoletos.
Las aplicaciones a menudo quieren obtener un subconjunto de estos datos y si pueden buscar en la memoria caché distribuida con un lenguaje de consulta similar a SQL y especificar atributos de objeto como parte de los criterios, la memoria caché distribuida será mucho más útil para ellas.
Mucha gente usa el caché distribuido como "caché lateral" donde obtienen datos directamente de la base de datos y los colocan en el caché. Otro enfoque es "caché a través", donde su aplicación solo le pide a la memoria caché los datos. Y, si los datos no están allí, la memoria caché distribuida los obtiene de su fuente de datos. Lo mismo ocurre con la escritura simultánea.
Junto con esto, NCache también es compatible con MapReduce, que habilita Big Data Analytics en datos en memoria, produciendo resultados casi en tiempo real.
La memoria caché del cliente es simplemente una memoria caché InProc/OutProc local en la máquina del cliente, pero permanece conectada y sincronizada con el clúster de memoria caché distribuida. De esta manera, el rendimiento de la aplicación realmente se beneficia de esta "cercanía" sin comprometer la integridad de los datos.
La replicación de WAN es una característica importante para muchas aplicaciones que se implementan en varios centros de datos, ya sea con fines de recuperación ante desastres o para equilibrar la carga del tráfico regional.
La idea detrás de la replicación de WAN es que no debe ralentizar el caché en cada ubicación geográfica debido a la alta latencia de WAN. NCache proporciona Bridge Topology para manejar todo esto.
Soporte para Microsoft AppFabric finaliza en abril de 2017. Este documento técnico presenta tres formas posibles de migrar aplicaciones .NET desde AppFabric a NCache, y ventajas de realizar este cambio. NCache es una memoria caché .NET estable, con todas las funciones y distribuida, disponible como código abierto en Azure y Amazon Web Services, así como en el NCache sitio web. El soporte completo también está disponible.
Usando el gratis NCache AppFabric envoltorio para cualquiera NCache Open Source or NCache Enterprise, ofrece el método de migración más fácil, sin codificación y libre de errores. Migrar llamando directamente al NCache La API proporciona más control de datos y habilita todos NCache caracteristicas. Todos los métodos de migración se describen en este documento técnico.
Consulte estos recursos adicionales para satisfacer sus necesidades de evaluación y producto.
Regiones in AppFabric son contenedores lógicos de pares clave-valor almacenados en una instancia de un caché, que está vinculado a una máquina servidor. Debido a esto, los datos dentro de las regiones no se pueden distribuir. Esta estructura arquitectónica pretende permitir recuperaciones más rápidas. Pero reduce significativamente el rendimiento general en comparación con un caché distribuido.
NCache es un caché distribuido en su núcleo. Todos los datos dentro NCache se distribuye y se mantiene una copia de seguridad en otra máquina física si la Réplica de partición Se utiliza la topología (PR). PR proporciona un rendimiento ultrarrápido de clase mundial y réplicas de conmutación por error para una pérdida de datos cero.
Así, las regiones en AppFabric se configuran como cachés independientes en NCache sin comprometer ninguna de las capacidades de obtención de datos. los AppFabric wrapper se hace cargo de esta complejidad y almacena automáticamente todos los datos de la región en el nombre de caché proporcionado. El único requisito es que los cachés en NCache debe preexistir. Creas cachés a través de NCache Manager , una herramienta de administración de clústeres basada en GUI. Una vez que se crean los cachés, los datos que residen en AppFabric regiones se distribuyen a la especificada NCache clúster(es). A pesar de que los datos se distribuyen realmente, no se compromete su capacidad para ejecutar búsquedas avanzadas, incluidas las consultas SQL (las consultas SQL no están disponibles con AppFabric en absoluto).
La otra diferencia notable entre NCache y AppFabric es la forma en que se configuran ambos productos. AppFabric es configurado por la aplicación en tiempo de ejecución (incluso la creación de caché) y en contraste NCache se configura antes de que se inicie la memoria caché. Por ejemplo, las topologías de la memoria caché no se pueden cambiar en tiempo de ejecución, mientras que otras configuraciones, por ejemplo, los vencimientos predeterminados de la memoria caché, etc., se pueden cambiar más adelante y se denominan como aplicables en caliente. A pesar de NCache se puede administrar usando la aplicación .NET (incluida la creación de caché) pero es preferible administrar desde la NCache Administrador: una única herramienta dedicada para administrar los clústeres de caché. También se puede crear, configurar y mantener un caché desde la CLI.
Aunque la NCache AppFabric-wrapper proporciona la forma más fácil de migrar aplicaciones .NET a NCache, que también es con la menor cantidad de cambios de código posible, algunos desarrolladores aún prefieren aprovechar todas las características que NCache debe ofrecer. Ahí es donde llamando directamente al NCache La API ayuda. También existe la opción de usar ambos métodos llamando al método Unwrap desde el AppFabric envoltura.
El AppFabric el clúster no es completamente dinámico. dependencia de "Regla de la mayoría de los anfitriones principales" significa que el clúster puede fallar muy fácilmente si incluso un host principal falla. Estos nodos principales de host también se asemejan a la arquitectura "maestra" y "esclava" y, por lo tanto, tampoco son totalmente de igual a igual.
NCache mientras que es altamente dinámico y le permite agregar o eliminar servidores de caché en tiempo de ejecución sin ninguna interrupción en el caché o su aplicación. Los datos se reequilibran automáticamente (lo que se denomina transferencia de estado) en tiempo de ejecución sin interrupción ni degradación del rendimiento. NCache los clientes continúan comunicándose con los servidores de caché, independientemente del estado del servidor. Los clústeres garantizan la ejecución de las operaciones de los clientes incluso cuando el equilibrio de datos está en proceso.
Esto significa que incluso para NCache, no hay nodos "maestros" o "esclavos" en el clúster. Hay un nodo de "coordinador principal" que es el nodo más antiguo. Y, si se cae, el siguiente nodo más antiguo se convierte automáticamente en el coordinador principal. Todo esto ocurre sin interrupción de las operaciones del cliente.