O cache distribuído foi reconhecido como uma parte importante e integral de aplicativos Web .NET de alto desempenho. Isso vale para os aplicativos de usuário final que exigem tempo de resposta rápido dos serviços de camada intermediária implantados ou componentes da Web. Por essas razões, a Microsoft introduziu AppFabric, um cache distribuído na memória, para fornecer um aumento de desempenho e escalabilidade para aplicativos que usam o .NET Framework.
AppFabric caching tem sido usado principalmente para armazenar dados de estado de sessão ASP.NET e para fornecer recursos básicos de cache de objetos. Mas mesmo que o cache seja parte integrante de qualquer sistema N-Tier, a Microsoft blogou que AppFabric o suporte termina em 11 de abril de 2017 para todas as versões. Este é um bom incentivo para pilhas .NET que empregam AppFabric para mudar para um cache distribuído melhor e com suporte.
Então, o que o fim suporta realmente significa? Isso significa:
Portanto, significa que você usará AppFabric por sua conta e risco. A Microsoft não será responsável por contratempos ou bugs. Por isso, temos que avaliar se as operações de negócios podem sustentar o tempo de inatividade devido a um bug sem resolução rápida.
Essas perguntas podem levá-lo a alternativas. Se você estiver pronto para uma alternativa, existe uma que fornece migração perfeita de sua configuração atual para um cache distribuído .NET com alterações mínimas de código, portanto, não apresenta nenhum bug. Esse cache distribuído alternativo não apenas oferece suporte à migração contínua, mas também é mais rápido e fornece mais recursos do que AppFabric.
NCache é uma escolha forte como alternativa. A Microsoft de fato recomendou NCache na sua anúncio fim AppFabric . NCache ganhou essa recomendação, pois é amplamente usado na comunidade .NET e tem sido líder de mercado em cache distribuído .NET para 10 anos consecutivos. NCache fornece desempenho excepcional juntamente com uma ampla gama de recursos, incluindo:
Outros benefícios de NCache incluem facilidade de uso (ele é classificado por uma empresa de analistas líder como o cache distribuído mais fácil de usar) fortes recursos de gerenciamento e monitoramento por meio de suas ferramentas GUI criadas especificamente e está disponível como código aberto (no GitHub) com custo praticamente zero antes e depois da migração. Open Source e a versão Enterprise, com suporte oficial, estão disponíveis no local e na nuvem (Amazon Web Services e Azure).
Enquanto Redis é um bom cache In-Memory, o Redis comunidade observa que Redis não está pronto para o Windows, apesar da disponibilidade de um Redis Porta do Windows. Redis não é totalmente escalável nem oferece recursos de alta disponibilidade. Redis' conjunto de ferramentas de monitoramento e gerenciamento é apenas CLI. NCache oferece muitas vantagens sobre Redis como mostrado neste link de vídeo (e este compartilhamento de slides guia inteligente) Incluindo.
Para atender às necessidades de qualquer ambiente operacional, NCache fornece três maneiras de migrar aplicativos .NET de AppFabric para NCache; cada método tem seu próprio conjunto de vantagens.
Os três métodos de migração são:
NCache AppFabric Os wrappers oferecem uma migração mais suave e contínua, mas a migração por meio de chamadas diretas à API oferece mais controle e permite que você aproveite todos os recursos do NCache.
Para aquelas organizações que procuram a transição mais fácil e rápida de AppFabric, esse wrapper fornece a migração mais fácil de todos os tempos. Apenas três pequenas alterações são necessárias no aplicativo .NET para torná-lo NCache compatível sem introduzir quaisquer possíveis bugs. Essas mudanças são:
<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;
com:
using Alachisoft.NCache.Data.Caching;E é isso! Nenhuma outra alteração de código é necessária no aplicativo .NET.
utilização NCache Open Source permite migrar de AppFabric sem custo, pois ambos os produtos são gratuitos. NCache Open Source tem um conjunto mais limitado de recursos em comparação com a edição Enterprise, mas sem qualquer degradação no desempenho do cache principal.
Para facilitar a migração, uma versão separada do AppFabric invólucro é fornecido para NCache OSS, que é compatível com a API de código aberto. Dado menos recursos em NCache Open Source, NCache Open Source wrapper funciona em torno dos recursos ausentes que incluem:
A NCache Open Source invólucro para AppFabric supera o desafio de manter o controle de versão do item encapsulando cada objeto dentro de outra classe. Isso é feito introduzindo uma nova classe chamada MetaDataCapsule no wrapper 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);
}
}
}Isso ajuda a manter a versão do item de um objeto e a transportar outras informações úteis, se necessário. A classe é marcada como Serializable, pois precisa trafegar pela rede.
Para garantir a consistência da versão do item e do objeto em todas as várias instâncias de aplicativos diferentes ou semelhantes, o bloqueio distribuído é usado. O bloqueio distribuído é uma característica do NCache que permite que vários aplicativos acessem e modifiquem o mesmo recurso sem comprometer a consistência dos dados e evitando possíveis condições de corrida.
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);Em resumo, em cada operação Put:
Bloquear no cenário acima garantirá que nenhum outro aplicativo possa atualizar ou remover o item se outro aplicativo estiver tentando modificar a mesma chave.
No código acima, existe um método chamado GetLock, a implementação é a seguinte.
// <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;
}O método GetLock tentará adquirir o bloqueio três vezes. Se falhar, ele retornará "null" permitindo que o método de chamada trate essa exceção. Assim, com a ajuda do Bloqueio Distribuído, o AppFabric invólucro para NCache Open Source mantém a versão do item de cache inserido pelos aplicativos cliente, incluindo casos de exceção.
Devido à falta de alguns recursos corporativos na edição de código aberto, as seguintes funções são marcadas como "obsoletas" e marcadas com "erro de compilação de lançamento" para garantir uma alteração de código e evitar surpresas.
Portanto, se seu aplicativo depende muito desses recursos, selecionar NCache Enterprise versão pode ser a melhor opção para permitir uma migração mais suave, perfeita e livre de bugs.
Para desenvolvedores que desejam aproveitar ao máximo muitos NCache Enterprise recursos, você pode preferir ligar diretamente para o NCache API em vez de usar o wrapper. Você também pode usar o 'método unwrap' do AppFabric wrapper para trabalhar diretamente com NCache tão bem.
De qualquer forma, é recomendável realizar sua migração em duas fases. Na fase 1, continue a usar seu AppFabric recursos, mas substitua seu cache por NCache. Na Fase 2, implemente novas NCache funcionalidades que não estavam disponíveis em AppFabric.
Nesta fase seu foco é apenas substituir AppFabric. Portanto, entender como esses dois caches distribuídos se comportam é importante (veja mais detalhes abaixo e no seção de referência no final). Como mencionado, AppFabric armazena dados em regiões em máquinas específicas. Por outro lado, para replicar os dados da sua região em NCache você pode criar um cache para cada AppFabric região, ou você pode criar NCache grupos para manter AppFabric dados da região.
NCache Grupos/Subgrupos fornece várias maneiras de agrupar itens em cache. Como as regiões residem dentro de um cache nomeado, NCache usa grupos para reproduzir esse comportamento. A única diferença é que em AppFabric uma chave precisa ser exclusiva apenas em uma região e não em todo o cache nomeado. Considerando que em NCache, a chave precisa ser exclusiva em todo o cache e não importa a qual grupo ela pertence. Esse obstáculo pode ser rapidamente superado se os nomes das regiões forem pré-anexados a todas as chaves.
Por exemplo:
In AppFabric, uma operação Add básica se parece com o seguinte:
// AppFabric API
regionCache.Add(stringKey, stringValue);E NCache o comando básico não é diferente, exceto que um nome de região pode ser especificado como um grupo no comando:
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
Aqui, cada chave é anexada com o nome da região para obter exclusividade entre as chaves de cache. Um grupo é atribuído à chave para uma recuperação mais rápida ou para facilitar a recuperação de dados usando consultas SQL ao realizar operações de pesquisa.
A outra maneira de agrupar itens em cache é eliminar completamente a correlação de região para grupo e usar um cache separado para cada região. Para obter o mesmo resultado, onde cada região recebe um cache separado, um mapa de nomes de regiões correspondentes aos caches pode ser armazenado.
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);Neste exemplo, não há necessidade de pré-anexar a chave de região à chave de cache, pois os caches em NCache são mutuamente exclusivos, mesmo que residam no mesmo cluster.
Se seu aplicativo deve lidar com muitas regiões (por exemplo, mais de 15), é melhor usar regiões como grupos, pois 15 caches por cluster é um número máximo de caches recomendado (mesmo que um cluster possa hospedar logicamente um número infinito de caches) .
Na próxima fase, você pode aproveitar os recursos que NCache fornece quais AppFabric e Redis falta. Características como:
A sincronização de banco de dados é um recurso muito importante para qualquer bom cache distribuído. Como a maioria dos dados armazenados em cache vem de um banco de dados relacional, sempre há situações em que outros aplicativos ou usuários podem alterar os dados e fazer com que os dados armazenados em cache se tornem obsoletos.
Os aplicativos geralmente desejam buscar um subconjunto desses dados e, se puderem pesquisar o cache distribuído com uma linguagem de consulta semelhante a SQL e especificar atributos de objeto como parte dos critérios, isso tornará o cache distribuído muito mais útil para eles.
Muitas pessoas usam o cache distribuído como "cache no lado", onde buscam dados diretamente do banco de dados e os colocam no cache. Outra abordagem é "cache through", onde seu aplicativo apenas solicita os dados ao cache. E, se os dados não estiverem lá, o cache distribuído os obterá de sua fonte de dados. A mesma coisa vale para a escrita.
Junto com isso, NCache também suporta MapReduce que permite Big Data Analytics em dados In-Memory, produzindo resultados quase em tempo real.
O cache do cliente é simplesmente um cache InProc/OutProc local na máquina cliente, mas que permanece conectado e sincronizado com o cluster de cache distribuído. Dessa forma, o desempenho do aplicativo realmente se beneficia dessa "proximidade" sem comprometer a integridade dos dados.
A replicação de WAN é um recurso importante para muitos aplicativos implantados em vários data centers para fins de recuperação de desastres ou para balanceamento de carga do tráfego regional.
A ideia por trás da replicação de WAN é que ela não deve reduzir a velocidade do cache em cada local geográfico devido à alta latência da WAN. NCache fornece Bridge Topology para lidar com tudo isso.
Suporte para Microsoft AppFabric termina em abril de 2017. Este white paper apresenta três maneiras possíveis de migrar aplicativos .NET de AppFabric para NCache, e as vantagens de fazer essa alteração. NCache é um cache .NET estável, completo e distribuído, disponível como Open Source no Azure e Amazon Web Services, bem como no NCache local na rede Internet. Suporte completo também está disponível.
Usando o grátis NCache AppFabric invólucro para qualquer um NCache Open Source or NCache Enterprise, oferece o método de migração mais fácil, sem codificação e sem bugs. Migrando chamando diretamente o NCache API fornece mais controle de dados e permite que todos NCache recursos. Todos os métodos de migração são descritos neste whitepaper.
Verifique esses recursos adicionais para atender às suas necessidades de avaliação e produto.
Regiões in AppFabric são contêineres lógicos de pares de chave-valor armazenados em uma instância de um cache, que é vinculado a uma máquina servidora. Por causa disso, os dados dentro das regiões não podem ser distribuídos. Essa estrutura arquitetônica afirma permitir buscas mais rápidas. Mas reduz significativamente o desempenho geral em comparação com um cache distribuído.
NCache é um cache distribuído em seu núcleo. Todos os dados dentro NCache é distribuído e uma cópia de backup é mantida em outra máquina física se o Réplica de partição (PR) topologia é usada. PR fornece réplicas de failover de classe mundial, desempenho super-rápido e failover para zero perda de dados.
Assim, as regiões de AppFabric são configurados como caches separados em NCache sem comprometer nenhum dos recursos de busca de dados. o AppFabric wrapper assume essa complexidade e armazena automaticamente todos os dados da região no nome de cache fornecido. O único requisito é que os caches em NCache deve pré-existir. Você cria caches via NCache Novos Negócios, uma ferramenta de gerenciamento de cluster baseada em GUI. Uma vez que os caches são criados, os dados que residem em AppFabric regiões são distribuídas para o especificado NCache cluster(s). Apesar de os dados serem verdadeiramente distribuídos, não há comprometimento em sua capacidade de executar pesquisas avançadas, incluindo consultas SQL (consultas SQL não estão disponíveis com AppFabric em absoluto).
A outra diferença notável entre NCache e AppFabric é a forma como ambos os produtos são configurados. AppFabric é configurado pelo aplicativo em tempo de execução (mesmo a criação do cache) e em contraste NCache é configurado antes que o cache seja iniciado. Por exemplo, topologias de cache não podem ser alteradas em tempo de execução, enquanto outras configurações, por exemplo, expirações padrão de cache, etc., podem ser alteradas posteriormente e são chamadas de hotapplyable. Embora NCache pode ser gerenciado usando o aplicativo .NET (incluindo a criação de cache), mas é preferível gerenciar a partir do NCache Manager - Uma ferramenta única dedicada para gerenciar os clusters de cache. Um cache também pode ser criado, configurado e mantido a partir da CLI.
Enquanto NCache AppFabric-wrapper fornece a maneira mais fácil de migrar aplicativos .NET para NCache, que também é com o mínimo de alterações de código possível, alguns desenvolvedores ainda preferem aproveitar todos os recursos que NCache deve oferecer. É aí que chamar diretamente o NCache API ajuda. Há também a opção de usar os dois métodos chamando o método Unwrap do AppFabric embrulho.
A AppFabric cluster não é completamente dinâmico. Dependência de "regra da maioria dos anfitriões líderes" significa que o cluster pode ser desativado com muita facilidade se até mesmo um host principal for desativado. Esses nós de host principais também se assemelham à arquitetura "mestre" e "escravo" e, portanto, também não são totalmente ponto a ponto.
NCache Considerando que é altamente dinâmico e permite adicionar ou remover servidores de cache em tempo de execução sem qualquer interrupção no cache ou em seu aplicativo. Os dados são reequilibrados automaticamente (chamado transferência de estado) em tempo de execução sem qualquer interrupção ou degradação de desempenho. NCache os clientes continuam se comunicando com os servidores de cache, independentemente do estado do servidor. Os clusters garantem a execução das operações do cliente mesmo quando o balanceamento de dados está em andamento.
Isso significa que mesmo para NCache, não há nós "master" ou "slave" no cluster. Existe um nó “coordenador primário” que é o nó mais sênior. E, se cair, o próximo nó mais sênior se torna automaticamente o coordenador primário. Tudo isso acontece sem qualquer interrupção nas operações do cliente.