Acampamento do Código Orlando 2019

Otimizar ASP.NET Core Desempenho com cache distribuído

Por Iqbal Khan
Presidente e Evangelista de Tecnologia

ASP.NET Core está rapidamente se tornando popular para o desenvolvimento de aplicativos da Web de alto tráfego. Aprenda a otimizar ASP.NET Core desempenho para lidar com cargas de transações extremas sem diminuir a velocidade usando um Cache Distribuído .NET de código aberto. Esta conversa abrange:

Visão geral rápida do ASP.NET Core gargalos de desempenho
Visão geral do cache distribuído e como ele resolve problemas de desempenho
Onde você pode usar o cache distribuído em seus aplicativos
Alguns recursos importantes de cache distribuído
Exemplos práticos usando código aberto NCache como o cache distribuído

Eu vou passar por cima deste tópico de como você pode otimizar ASP.NET core desempenho e vou usar o cache distribuído como a técnica para fazer essas melhorias e vou usar NCache como o exemplo neste.

ASP.NET Core Populares (aplicativos de alto tráfego)

Todos sabemos que ASP.NET core é o novo .NET core, a arquitetura limpa e leve, a plataforma cruzada e o código aberto, e isso está se tornando uma das principais razões pelas quais mais e mais pessoas estão migrando para ASP.NET core.

Além disso, há uma enorme base de usuários ASP.NET herdada e, especialmente, se você é um aplicativo ASP.NET MVC, então mude para ASP.NET core é bem direto. Se você não é um MVC então, é claro, você tem muito código para escrever. Então, todas essas são as razões pelas quais eu tenho certeza que você também está aqui porque ASP.NET core é a escolha .NET líder para fazer aplicações web.

ASP.NET Core Precisa de escalabilidade

Então, quando você tem ASP.NET core está sendo usado cada vez mais em situações de tráfego intenso. Alto tráfego geralmente significa que você tem um aplicativo voltado para o cliente. Você pode ser um negócio online, você pode ser um negócio de varejo. Há uma série de indústrias, saúde, governo eletrônico, mídia social, apostas online, jogos de azar, tudo o que você pode imaginar. Todo mundo está online hoje em dia. Então, qualquer um! Quando há um ASP de aplicativo da web.NET core está sendo usado, o que significa ASP.NET core precisa ser escalável.

O que é escalabilidade?

O que isso significa? Deixe-me definir isso, tenho certeza que você sabe muito disso, mas apenas para fins de completude, vou apenas definir a terminologia.

Então, escalabilidade significa que se você tem um aplicativo com cinco usuários você tem um tempo de resposta muito bom, você clica nele e dentro de um ou dois segundos a página volta. Então, se você conseguir o mesmo tempo de resposta com cinco mil, cinquenta mil ou quinhentos mil usuários, seu aplicativo será escalável. Se você não pode, então você não é escalável. Se você não tem um alto desempenho com cinco usuários, então você tem que ir para outras discussões sobre como você escreveu seu código. Mas, suponho que seu aplicativo seja desenvolvido com bons algoritmos, com boa abordagem e seja um aplicativo de alto desempenho com cinco usuários. Então, como torná-lo de alto desempenho sob cargas de pico?

O que é escalabilidade linear?

Então, se você pode ir de cinco a cinco mil para cinquenta mil, isso é chamado de escalabilidade linear.

E, da maneira como você consegue isso, como você sabe em um ambiente com balanceamento de carga, você implanta o ASP.NET core aplicativo com um balanceador de carga e você adiciona mais e mais servidores. Então, à medida que você adiciona mais servidores, aqui, sua capacidade de transação, seu número de solicitações por segundo de capacidade aumenta de forma linear. Se você pode conseguir isso, então você será capaz de alcançar o mesmo desempenho. E, esse é o objetivo da palestra de hoje que queremos poder alcançar esse alto desempenho sob cargas de pico. Então, se você não tem um alto desempenho sob carga de pico, se você não tem uma aplicação linear isso significa que você tem alguns gargalos, em algum lugar. Então, assim que você ultrapassar um certo limite, não importa se você adicionar mais caixas. Na verdade, provavelmente vai atrasar as coisas porque há um gargalo em algum lugar que está impedindo seu aplicativo. Então, você definitivamente não quer ser uma escalabilidade não linear.

Quais aplicativos precisam de escalabilidade?

Apenas para recapitular, que tipos de aplicativos precisam ser escaláveis?

Obviamente, ASP.NET core é disso que estamos falando. Você também pode ter Serviços da Web, o que significa que os aplicativos ASP.NET são os aplicativos da Web, o que significa que seus usuários são humanos. Os serviços da Web são novamente aplicativos da Web. Seus usuários são outros aplicativos. Microsserviços é um conceito relativamente novo que também é para aplicativos do lado do servidor. Claro, isso envolve a rearquitetura de todo o seu aplicativo. Eu não vou entrar em como você faz isso. Estou apenas mencionando o aplicativo de tipos para que você possa mapear o que quer que vocês estejam fazendo ou que sua empresa esteja fazendo mapear para isso ou não. E, finalmente, muitos aplicativos de servidor gerais. Esses aplicativos de servidor podem estar fazendo processamento em lote. Por exemplo, se você é uma grande corporação, digamos, se você é um banco, pode precisar processar muitas coisas em segundo plano em modo de lote, em modo de fluxo de trabalho e esses são os aplicativos de servidor.

O problema e a solução de escalabilidade

Portanto, todos esses diferentes tipos de aplicativos precisam ser capazes de lidar com a escalabilidade, o que significa que precisam ser capazes de processar todas as cargas de transações crescentes sem diminuir a velocidade. Então, obviamente há um problema de escalabilidade, senão não estaríamos tendo essa conversa. Se tudo correu bem, a boa notícia é que sua camada de aplicativo não é o problema, seu ASP.NET core aplicativo não é o problema, é o armazenamento de dados. Quaisquer que sejam os dados que você está tocando, o que quer que seja, não importa, isso está causando um gargalo de desempenho. E esses são seus bancos de dados relacionais, seus dados legados de mainframe e vários outros dados. Interessantemente, NoSQL databases nem sempre são a resposta porque em muitas situações você não é capaz... porque NoSQL database pede que você abandone seu banco de dados relacional e mude para um novo banco de dados SQL ou NoSQL database que você não pode fazer por vários motivos técnicos e não técnicos. E, se você não conseguir mover para um NoSQL database, de que adianta? Direita?

Então, meu foco é que você tem que resolver esse problema com o banco de dados relacional na foto, porque esse é o banco de dados que você terá que usar, como eu disse, por vários motivos. E, se você não for capaz de se afastar dele, então NoSQL databases não são a resposta em muitas situações.

Implantação de cache distribuído

Portanto, você deve continuar usando um banco de dados relacional e, em vez disso, implantar um cache distribuído em seu aplicativo.

Aqui está o que parece. Portanto, se você perceber que tem a mesma camada de aplicativo, pode adicionar mais e mais servidores a ela à medida que sua carga de transações aumenta. No caso de muitos deles, digamos, aplicativos da Web e serviços da Web, eles geralmente são um balanceador de carga acima, que garante que todos os servidores da Web recebam carga igual dos usuários. No caso de aplicações de servidor, pode não ter muito balanceador, pode, depende da natureza da aplicação. Mas, o fato é que você pode adicionar mais e mais servidores e há apenas um banco de dados aqui. E, como eu disse, pode haver alguns NoSQL database para alguns dados de especialidade menores, mas a maioria dos dados ainda é relacional. Assim, o objetivo é colocar uma camada de cache no meio e um cache distribuído é essencialmente um cluster de dois ou mais servidores e esses servidores são servidores de baixo custo. Estes não são servidores de banco de dados de última geração e tudo é armazenado na memória.

Por que na memória? Porque, a memória é muito mais rápida do que o disco rígido. Se o seu aplicativo precisa ter um desempenho cada vez maior, você precisa ser absolutamente claro sobre isso. O disco rígido, seja SSD ou HDD, vai te matar. Você tem que ir na memória. Tudo tem que ser armazenado na memória ou então você não conseguirá o desempenho que deseja. E isso independentemente de você ir para um cache distribuído ou não, mas na memória é esse o armazenamento. Portanto, um cache distribuído possui dois ou mais servidores. Ele forma um cluster e a palavra cluster significa que cada servidor conhece o outro servidor do cluster, eles agruparam os recursos, a memória, a CPU e a placa de rede. Então, esses são os três recursos que ele reúne em uma capacidade lógica.

Memória, porque cada servidor tem RAM, então uma configuração típica que vimos nossos clientes usarem é entre 16 a 32 giga de RAM e cada servidor de cache. recomendamos o mínimo de 16, entre 16 a 32. E então, em vez de ir acima de 32 para, digamos, 64 ou 128 giga de RAM, em cada caixa o que exige que você aumente a capacidade da CPU porque quanto mais memória você tiver, mais coleta de lixo que você tem que fazer. Como o .NET usa GC, quanto mais coleta de lixo, mais CPU, ou então a coleta de lixo se torna o gargalo. Então, é melhor ter um alcance de 16 a 32 e não maior e apenas ter mais caixas do que ter 128 giga de duas caixas. Então, é para isso que serve a memória.

CPU obviamente é a segunda coisa. Novamente, a configuração típica é de cerca de 8 núcleos. Algumas das implantações de ponta usariam cerca de 16 núcleos, mas 8 núcleos são bons o suficiente por caixa. Como eu disse, servidores de baixo custo. E a placa de rede, é claro, porque quaisquer dados enviados daqui para cá estão sendo enviados pelas placas de rede. Agora, na camada de aplicativos, você obviamente tem mais servidores de aplicativos do que os servidores de cache. E, novamente, geralmente o que recomendamos é uma proporção de quatro para um ou cinco para um. Cinco servidores de aplicativos para um servidor de cache com no mínimo dois servidores de cache. Então, se você tem cinco servidores de aplicativos aqui, eles têm cinco placas de rede, eles estão enviando dados para uma proporção de cinco para um de placas de rede.

Então, a placa de rede, você tem que ter pelo menos uma placa de rede gigabit ou 10 gigabit nos servidores de cache. Fora isso, você só precisa juntá-los e digamos que você comece com dois como o mínimo e quando você maximizar dois, o que vai acontecer é você sub-lo, você executará seu aplicativo. Tudo vai correr muito rápido ou talvez você esteja fazendo testes de carga. Tudo vai correr super-rápido e a carga aumentada. De repente, o lado do servidor começará a ver maior CPU, maior consumo de memória e o tempo de resposta começará a diminuir. Agora é isso que vai acontecer com o banco de dados relacional, exceto que aqui você pode adicionar uma terceira caixa e, de repente, você obtém outro grande alívio e agora começará com uma taxa de transferência mais alta e agora poderá adicionar mais e mais transações. fora e então você adiciona uma quarta caixa, você sabe.

Então, é assim que esse quadro continua aumentando e isso nunca se torna um gargalo isso, e Never Say Never, mas quase nunca, isso se torna um gargalo porque você pode adicionar mais e mais servidores. E, à medida que você adiciona mais servidores aqui, você apenas adiciona mais nesse cache aqui, o que você não pode fazer com o banco de dados. Agora, eu coloquei 8020 de carga. Na realidade, é mais como 90% do tráfego vai para o cache 10% vai para o banco de dados porque mais e mais dados você vai apenas ler do cache. Vou falar sobre alguns outros aspectos que um cache tem que lidar, mas isso é basicamente uma imagem, esta é a razão pela qual você precisa de um cache distribuído.

Usando cache distribuído

Ok! Então, vamos seguir em frente. Agora que espero convencê-lo de que você precisa incorporar um cache distribuído em seu aplicativo que a primeira pergunta que vem à mente é, bem, o que eu faço com isso? Como eu uso isso? Portanto, existem três categorias principais nas quais você pode usar um cache distribuído.

Existem outros, mas para a maior parte da discussão, os três são realmente de alto nível.

Cache de dados do aplicativo

O número um é o cache de dados do aplicativo. Isso é o que eu tenho falado até agora. Quaisquer dados que estejam no banco de dados, isso é o que chamo de dados do aplicativo, você os está armazenando em cache para não ir ao banco de dados. Agora, lembre-se, e com cada um deles, com um aplicativo de armazenamento de dados em cache, a natureza do problema é que os dados existem em dois lugares; o cache e o banco de dados. E, sempre que os dados existem em dois lugares, o que pode dar errado? Fora de sincronia! Sim! Assim, os dados podem ficar fora de sincronia. Portanto, se seus dados e o cache estiverem fora de sincronia com o banco de dados, isso poderá criar muitos problemas. Eu poderia sacar um milhão de dólares duas vezes supondo que tivesse que começar, mas, digamos que... Esse é o primeiro problema que me vem à mente.

Qualquer cache, qualquer cache distribuído que não seja capaz de lidar com esse problema, significa que você está limitado a dados somente leitura. Mas, o que chamamos de dados de referência. E foi assim que o cache começou a ser entendido como cache de dados somente leitura em minhas tabelas de pesquisa. A tabela de consulta é cerca de 10% dos seus dados. Em algumas aplicações não é mas uma aplicação média. 90% dos seus dados não são dados de pesquisa. São dados transacionais. São seus clientes, suas atividades, seus pedidos, tudo. Então, se você não conseguir armazenar em cache todos eles, então o benefício, digamos, 10% dos dados, talvez a pesquisa esteja realmente sendo feita mais do que seu quinhão justo. Então, esses 10% podem lhe dar o benefício de 30%, mas você ainda tem 70% dos dados que precisa ir para o banco de dados. Mas, se você pudesse armazenar em cache todos os dados, o que só seria possível se obtivesse esse conforto, obteria o benefício real.

ASP.NET Core Cache específico

O segundo caso de uso ou a segunda maneira de usar é, o que chamo de ASP.NET core cache específico e existem três maneiras. Um é as sessões que é o mais comumente entendido. ASP.NET os tinha ASP.NET core os tem. Eles estão aqui para ficar. Eu não acho que as sessões vão desaparecer, embora algumas pessoas argumentem que não devemos usar as sessões. Não há nenhum mal se você usá-los. O único problema com eles é que onde você os armazena. Esse sempre foi o problema com o ASP.NET. Quaisquer opções de armazenamento que a Microsoft deu a você estavam cheias de problemas. Portanto, a única opção naquele momento era usar um cache distribuído que você poderia, felizmente, conectar como uma opção personalizada nos dias do ASP.NET. Em ASP.NET core, a Microsoft não possui um built-in ou eles têm uma imagem como um autônomo na memória, mas eles imediatamente entram em um IDdistribuídoCache ou provedor de sessão personalizado que você pode conectar a um cache distribuído de terceiros, como NCache.

Sessions é o primeiro, o segundo é o cache de resposta. Eu ia dizer quem não sabe sobre o cache de resposta, mas essa não é uma boa maneira de perguntar. O cache de resposta é como uma versão mais recente do cache de saída, mas é mais baseado em padrões. É a saída da página que você pode armazenar em cache e eu a examinarei, mas isso também é algo que você pode armazenar em cache e conectar um cache distribuído como um middleware para ele.

E o terceiro é se você tiver um sinal ou aplicativo que seja o aplicativo da web ao vivo. Os aplicativos da web ao vivo são aqueles em que, digamos, você tem um aplicativo de negociação de ações que precisa propagar constantemente todas as mudanças no preço das ações e tem centenas de milhares de clientes. Eles estão todos conectados para que permaneçam conectados ao cache ou às camadas do aplicativo. É diferente do HTTP normal, onde para cada solicitação da Web uma nova conexão de soquete é aberta. Aqui, a conexão do soquete permanece aberta e os eventos são propagados do servidor. Então, em um SignalR, quando você tem uma transação maior, um grande número de usuários, você tem que ter um formulário web com balanceamento de carga, mas como os soquetes são mantidos abertos, cada servidor vai conversar com seu próprio cliente, mas agora que todos os clientes ou todos os servidores têm diferentes conjuntos de clientes, então eles precisam compartilhar dados. Então, esses dados são compartilhados através de um backplane e esse backplane se torna... Então, é aí que você conecta um Cache distribuído. Eu não vou passar por cima dos detalhes desse Específico. Vou falar sobre os dois primeiros, mas não sobre o terceiro.

Agora, a coisa específica sobre ASP.NET core cache específico é que os dados existem apenas no cache. Isso é o que eu estava dizendo, não coloque no banco de dados. Não há necessidade. Estes são dados temporários. Você só precisa dele por 20 minutos, 30 minutos, hora, 2 horas, o que quer que os dados precisem desaparecer. Então, se é temporário, deve existir apenas no cache e quando os dados existem apenas no cache e é um cache na memória, o que pode dar errado? Você pode perder dados porque está tudo na memória. A memória é volátil. Então, um bom cache distribuído tem que lidar com essa situação, claro, isso significa que você precisa replicar.

Mensagens e eventos do Pub/Sub

O terceiro caso de uso é que muitos aplicativos precisam fazer operações do tipo fluxo de trabalho. O microsserviço é um bom exemplo disso. Eles precisam coordenar atividades, embora microsserviços não sejam o tópico, mas até ASP.NET core aplicativos ocasionalmente precisam fazer isso. Então, mensagens pub/sub é outra maneira porque você tem, mais uma vez, em mente, você tem uma infraestrutura em que todas essas caixas estão conectadas a essa infraestrutura redundante na memória. Então, por que não usá-lo para mensagens pub/sub também?

Então, esses são os três casos de uso comuns. Então, estas são as três maneiras que você deve usar NCache ou um cache distribuído se você quiser se beneficiar, se quiser maximizar o benefício.

Demonstração prática

Então, vou rapidamente, antes de entrar em como você realmente os usa, quero mostrar a você como é um cache distribuído. Vou usar o Azure como ambiente e vou usar NCache. E, é apenas uma demonstração rápida de…

Configurando um ambiente

Então, estou logado no Azure. Eu tenho quatro VMs, novamente, são todas .NET core.

Então, eu tenho quatro VMs no Azure. Vou usar duas dessas VMs como servidor de cache, que é basicamente -- essas são essas duas... Vou ter um cliente Windows e um cliente Linux. Então, se você tem porque .NET core suporta Linux. Se você tem .NET core como o aplicativo, você pode querer implantá-lo no Linux. Agora, em caso de NCache, novamente, não estou fazendo marketing NCache. Mas no caso de NCache, isto é .NET core para que possa ser executado em Windows ou Linux, tanto nos servidores quanto nos clientes.

Ok! Vamos entrar… Então, estou logado neste cliente, a caixa do cliente Windows. Então, agora vou em frente e criar um cache para mim.

Criar um cache clusterizado

Então, vou usar essa ferramenta chamada NCache, NCache Gerente na verdade não vem com código aberto. Há um equivalente de linha de comando, mas estou sendo preguiçoso aqui. Então, eu só vou usar NCache manager, mas é a mesma funcionalidade. A funcionalidade não muda, então acabei de lançar NCache Gerente. Eu vou dizer para criar um novo cache. Você acabou de nomear um cache. Todos os caches são nomeados. Pense nisso como uma string de conexão para o banco de dados e escolha uma topologia. Não vou entrar nas topologias, mas vou falar mais sobre o que um cache precisa fazer para poder lidar com todas essas necessidades. Então, vou usar apenas a topologia de cache de réplica de partição. Replicação assíncrona. Vou adicionar meu primeiro servidor de cache. 10.0.0.4 e o segundo 5. Então, eu tenho dois servidores de cache. Vou manter tudo como padrão. Vou para os despejos e todos os outros.

E, agora vou especificar dois clientes. 10.0.0.6 e 7. Eu vou vir aqui e vou começar o cache. Então, pense nisso como um banco de dados, em vez de um servidor, você tem vários servidores que constituem o cluster e cria um cluster de servidores de cache e, em seguida, atribui clientes. Você não precisa atribuir os clientes porque pode apenas executá-los, mas estou fazendo isso aqui porque dá mais flexibilidade.

Simule o estresse e monitore as estatísticas de cache

Então, eu quero ir e testar o cliente. Então, eu sou o cliente. Acho que sou 10.0.0.6. deixe-me apenas ter certeza de qual sou eu. Acho que sou 10.0.0.6, acho. Vamos! Então, novamente, estou fazendo tudo dentro da rede virtual do Azure para que o cliente seja realmente o servidor de aplicativos e o cache esteja tudo junto agora. No caso de NCache você poderia ter obtido isso do azure marketplace. Portanto, .6 é o cliente Windows. Então, vou lançar o PowerShell e vou me certificar de que posso ver. Ok! Ok! Então, você verá que esse cliente vai falar com o cache e agora estou fazendo cerca de XNUMX requisições por segundo em cada servidor de cache. Deixe-me adicionar um pouco mais de carga. Vou abrir outro PowerShell e estressar outra instância do cliente. Agora, você verá que subirá para mais de mil a mil e trezentos por servidor.

e agora vamos fazer... Na verdade, eu vou... Então, eu abri um prompt de comando aqui. Deixe-me entrar na caixa Linux. Ops! E desculpe! Começamos o PowerShell lá. Preciso importar as bibliotecas parciais do clone de NCache e vou fazer o mesmo cache de demonstração de estresse, então vou... Antes de fazer isso, como você pode ver, estou fazendo cerca de treze a mil e quinhentos por servidor, adicionar isso como um cliente baseado em Linux conversando com o cache e agora de repente tenho quase dois mil e quinhentos pedidos por servidor.

Então, estou fazendo cerca de cinco mil solicitações por segundo em um servidor de dois. Como eu disse, você pode adicionar mais e mais carga e, à medida que você maximiza essas duas caixas, adiciona uma terceira e, em seguida, adiciona uma quarta. Então, é tão simples quanto isso e, novamente, isso é uma simulação. É uma coisa real como uma ferramenta de teste de estresse. Então, é isso que você deve ter em mente. Vou continuar com o cache real agora. É um programa de teste de estresse. Ele apenas coloca como uma matriz de bytes. Eu acho que coloca em 1k de dados. Ele adiciona, ele atualiza, ele recebe. Então, ele simula qualquer que seja o seu aplicativo real e tem parâmetros que você pode alterar para ver qual é a proporção de leitura versus gravação como estávamos falando. E, esta é uma ferramenta que damos com NCache, para que você possa realmente testá-lo em seu próprio ambiente. Então, para ver como NCache está realmente funcionando antes de você gastar muito tempo migrando seu aplicativo para ele. Deixe-me passar rapidamente. Acho que estou executando isso.

ASP.NET Core Armazenamento de Sessão

Então, agora que vimos como é um cache, como você pode adicionar mais clientes e como adicionar mais carga nele, é muito simples. Portanto, a maneira mais fácil de usar um cache é colocar sessões nele. E, para as sessões, há duas coisas que você pode fazer.

Ou você pode simplesmente usar um provedor IDistributedCache. Digamos NCache tem um. Assim que você especificar NCache como IDistributeCache, ASP.NET core passa a utilizá-lo para armazenamento de sessões. E, deixe-me mostrar um pouco disso. eu tenho esse ASP.NET core inscrição. Como você pode ver aqui. Nos meus serviços de configuração, estou especificando isso, estou dizendo make NCache meu provedor de cache distribuído. Então, assim que eu fizer isso, ele começará a usar sessões padrão e essas sessões padrão usarão IDistributedCache que agora está usando NCache. Portanto, seja qual for o provedor de cache distribuído que você tiver, isso é tudo o que você precisa fazer. Como você pode ver, um código muito pequeno muda e todo o seu aplicativo é automaticamente, todas as sessões serão imediatamente colocadas em um cache distribuído.

public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc();
	//Add NCache as your IDistributedCache so Sessions can use it for their storage
	services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
	
	//Add regular ASP.NET Core sessions
	services.AddSession();	
}

E, uma das coisas que vimos é quando muitos de nossos clientes, quando estão armazenando sessões no banco de dados e estão tendo problemas, eles conectam algo como NCache é instantâneo e o benefício que eles veem, uma melhora notável é instantânea. A menor quantidade de esforço o ganho máximo está lá. Porque, é claro, o cache direto do aplicativo também está lá.

Vou pular algumas porque acho... Então, existem várias maneiras de especificar sessões. Um foi o IDistributedCache, o segundo é que você pode realmente usar um provedor de sessão personalizado que NCache também tem e, novamente, todos eles são de código aberto. Então, para o cache de resposta, novamente, você faz a mesma coisa. Você especifica NCache como o cache distribuído e ele se torna automaticamente o cache para o cache de resposta. Não vou entrar em mais detalhes.

ASP.NET Core Cache de dados do aplicativo

Eu quero que você toque um pouco mais neste tópico. Então, quando você faz o cache de dados do aplicativo, diferentemente das sessões, agora você precisa fazer a programação da API. A menos que você esteja fazendo o núcleo do framework de entidade.

Assim, por exemplo, no caso de NCache, novamente de código aberto, há um provedor principal EF. Então, implementamos métodos de extensão para o EF core. Então, você pode realmente conectar NCache open source e use suas consultas de núcleo EF regulares e, no final, você pode dizer do cache ou do banco de dados, algo, é apenas um método de extensão que começa automaticamente a armazenar coisas em cache. Dá a você controle total sobre o que você deseja armazenar em cache, o que não deseja armazenar em cache. Dê uma olhada nisso. É uma maneira realmente poderosa.

Se você estiver fazendo o EF core, é isso que eu recomendo que você faça. Eu acho que, para qualquer ASP.NET core aplicativo, toda a programação do banco de dados deve ser feita através do núcleo EF, especialmente porque o núcleo EF é uma arquitetura muito melhor do que o antigo EF. Então, essa é uma maneira de fazer isso.

A outra é que você pode realmente fazer isso. Você pode usar a API IDistributedCache ou a interface que oferece flexibilidade para não ficar preso a uma solução de cache, mas tem um custo. É muito básico. Há apenas uma entrada de obtenção e isso é basicamente, bem, também há uma remoção. É sobre isso. E, todas as coisas sobre as quais falamos, se você não consegue manter o cache sincronizado com o banco de dados, todas essas coisas você perde tudo isso. Portanto, se você deseja se beneficiar de todos esses recursos, precisa acessar a API que realmente suporta todos eles. E novamente, porque você vai se comprometer com um cache de código aberto, geralmente é mais fácil fazer isso, mas o cache direto do aplicativo, a API é muito direta, há uma chave e um valor. O valor é seu objeto.

Mantendo o cache atualizado

Agora, deixe-me chegar ao tópico do que permite que você mantenha o cache atualizado. A informação realmente valiosa, certo? O que você faz?

Bem, a primeira coisa que quase todo cache distribuído faz, expira! Você faz a expressão absoluta. O que quer que você coloque no cache, você diz para removê-lo do cache daqui a cinco minutos. Então, é seguro manter em cinco minutos, acho que em cinco minutos sou o único a atualizá-lo depois que outras pessoas podem. Então, NCache tem, todo mundo também tem. Transitório… há uma expressão deslizante para dados transitórios como sessões e outros que depois que você terminar de usá-lo, se não for tocado por um determinado período de tempo, digamos sessões, quando o usuário sair após 20 minutos de inatividade, a sessão expira. Então, a mesma coisa acontece. Expirações, praticamente todo mundo tem.

Em seguida é o cache sincronizado com o banco de dados. Este é um recurso que permite que o cache monitore seu banco de dados. Então, você pode realmente... quando estiver adicionando coisas a NCache, digamos, você pode ter uma dependência SQL que permite NCache monitorar. A dependência SQL é um recurso ADO.NET do servidor SQL que usamos. A dependência SQL permite que você especifique a instrução SQL ou o procedimento de armazenamento que permite NCache para monitorar seu banco de dados do servidor SQL, esse conjunto de dados específico. E, se ocorrer alguma alteração nesse conjunto de dados, o SQL Server notifica NCache e qualquer cache remove esses dados do cache ou, se você combinar essa sincronização com um recurso de leitura, ele os recarregará. Então, digamos que você tenha um objeto de cliente que foi armazenado em cache e era dependência de SQL e esse cliente foi alterado no banco de dados que são dados transacionais de clientes, então ele será alterado com frequência. Você pode usar a leitura e recarregar automaticamente na expressão ou sincronização de banco de dados.

Então agora, de repente, seu cache é responsável por monitorar os dados. Existem três maneiras de fazer isso, há dependência de SQL, dependência de banco de dados e selo são procedimentos armazenados CLR. Não vou entrar em detalhes disso. Você pode ir ao nosso site e lê-lo. Mas, novamente, o mais importante é que, se você não tiver a sincronização do cache com o banco de dados como um recurso, estará limitado a esses dados estáticos e somente leitura. E, então, isso limita tudo e, novamente, você também pode sincronizar esse cache com a fonte de dados não relacional.

E, a terceira coisa é que você pode ter um relacionamento... na maioria das vezes você estará armazenando dados relacionais em cache, que tem relacionamentos um-para-muitos um-para-um. Então, digamos que um cliente tenha vários pedidos. Se você remover o cliente, os pedidos também não devem ficar no cache porque talvez você o tenha excluído do banco de dados. Portanto, se você não fizer isso, seu aplicativo precisará fazer tudo isso, mas o objeto de cache do ASP.NET possui esse recurso chamado recurso de dependência de chave. NCache implementou isso que permite que você tenha um relacionamento um-para-muitos ou um-para-um entre vários itens de cache e que, se uma coisa for atualizada ou removida, a outra será removida automaticamente. Portanto, essas quatro coisas combinadas permitem que você tenha certeza de que seu cache permaneça atualizado e consistente com o banco de dados. E é isso que permite que você comece a armazenar dados em cache. Então, esse é o primeiro benefício.

Read-thru e Write-thru

A segunda é que, se você puder usar leitura e gravação, isso simplificará seu aplicativo.

Leitura, como eu disse, você pode combinar leitura para recarregar automaticamente, que é algo que seu aplicativo não seria capaz de fazer se você não tivesse leitura. E, write-through novamente, você pode atualizar o cache e o cache pode atualizar o banco de dados, especialmente se você tiver um logo atrás, novamente estamos falando de desempenho, certo? Portanto, todas as atualizações devem ser feitas no banco de dados. Bem, e as atualizações serão lentas em comparação com as leituras do cache. Então, e se você pudesse delegar as atualizações ao cache e dizer que vou atualizar o cache, por que você não atualiza o banco de dados para mim? Eu sei que é seguro porque e vamos trabalhar no modelo de consistência eventual, que é o que os sistemas distribuídos são, que você sacrifica ou se torna mais tolerante com a consistência e segue com o modelo de consistência eventual. O que significa que, embora neste momento não seja consistente, porque o cache é atualizado, o banco de dados não é, dentro de alguns milissegundos ele será atualizado. E, alguns dados você não pode fazer isso, mas muitos dados você pode.

Então, fazendo logo atrás, de repente suas atualizações também são super-rápidas, seu aplicativo não precisa arcar com o custo de atualização do banco de dados. O cache faz porque é um cache distribuído e pode absorver isso como um lote e existem outros. Então, quando você começar a fazer isso, significa que agora você pode armazenar em cache muitos dados.

Agrupamento de dados

Depois de armazenar dados em cache, mais e mais dados, seu cache se torna tão rico quase como um banco de dados, o que significa que você está armazenando em cache quase todos os dados.

Quando você armazena em cache quase todos os dados, o valor da chave não é suficiente para encontrar as coisas. Você tem que ser capaz de pesquisar coisas. AppFabric costumava ter grupos e subgrupos, tags nomeadas tags, a propósito, NCache open source tem AppFabric invólucro. Então, aqueles de vocês que conseguiram AppFabric pode se mudar para NCache como uma coisa gratuita. Assim, o agrupamento permite que você busque dados facilmente.

Encontrando dados

A pesquisa SQL permite que você encontre coisas como, dê-me todos os meus clientes onde a cidade é Nova York. Então, agora você está fazendo o tipo de banco de dados de consultas no cache. Por quê? Porque seu cache não contém muitos dados.

Todo o paradigma está mudando porque você está cada vez mais na memória. Novamente, o banco de dados é o mestre. Portanto, o cache ainda o possui apenas por um período temporário.