Campo 31 do Código de Boston

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

Ok, obrigado a todos, todos podem me ouvir bem? Ok, esqueci de incluir o slide, agradecendo a todos os patrocinadores. Vou entrar no site e mostrar os logos de todos os patrocinadores. nós somos um deles, então, eu vou mostrar isso no final também. Foi o que os organizadores nos disseram. Então, vou abordar este tópico e gostaria de manter esta conversa mais interativa, se possível. Então, se você tiver alguma dúvida, sinta-se à vontade para me parar. Deixe-me apenas ter certeza de que tudo está gravando.

Então, o tópico de hoje é como você otimiza ASP.NET core desempenho do aplicativo com cache distribuído? Vou usar um produto de código aberto chamado NCache. Quantos aqui, já ouviram falar NCache antes? Esse é um bom número. Ok, vou usar NCache como um exemplo. Esta conversa não é sobre NCache, é sobre ASP.NET Core desempenho e como você pode usar o cache? Então, tenho certeza que você estava aqui porque o ASP.NET core tornou-se popular, está se tornando popular, é a nova arquitetura leve e limpa, é a tecnologia de plataforma cruzada, a rearquitetura do .NET é de código aberto, há muitos aplicativos legados do ASP.NET que também estão migrando para o ASP.NET core. ASP.NET core será a principal tecnologia com a qual você desenvolveria aplicações web em .NET.

Assim, mais e mais pessoas agora estão desenvolvendo aplicativos que precisam de escalabilidade. Então, ASP.NET core é claro que também precisa de escalabilidade. Deixe-me definir rapidamente o que é escalabilidade? Tenho certeza que a maioria de vocês já sabe disso, mas para fins de completude, vou definir isso.

O que é escalabilidade?

Escalabilidade é se você tem um aplicativo que tem um tempo de resposta muito bom, tem um desempenho muito bom com cinco usuários, se você pode manter esse mesmo desempenho com cinco mil, cinquenta mil, quinhentos mil usuários, então seu aplicativo é escalável. Se o seu aplicativo não tiver um bom desempenho com cinco usuários, você terá outros problemas que não abordaremos aqui. Então, eu vou falar sobre como você pode manter esse bom desempenho de cinco usuários para cinquenta mil ou quinhentos mil usuários.

Escalabilidade linear

Escalabilidade linear significa que sua aplicação é arquitetada de tal forma que você pode adicionar mais servidores em produção à medida que sua carga cresce e à medida que você adiciona mais servidores, sua capacidade de transação cresce e é isso que lhe dá um bom desempenho se você puder manter escalabilidade linear. Se você não for capaz de manter a escalabilidade linear, haverá algum tipo de gargalo, que seu aplicativo enfrentará em breve à medida que você adicionar mais servidores, em breve não fará diferença se você adicionar mais servidores ou não e você vai acabou de acertar um gargalo, existe e vou falar sobre o gargalo.

Os seguintes aplicativos precisam de escalabilidade

Então, quais aplicativos precisam de escalabilidade? Geralmente, aplicativos de servidor, são aplicativos da Web, ASP.NET core, serviços da web, que são usados por outros aplicativos da web. Os serviços da Web podem ser aplicativos independentes que estão sendo usados por aplicativos externos ou podem ser parte de aplicativos da Web que você está desenvolvendo, de qualquer forma, se forem de alta transação, também precisarão de escalabilidade.

Microsserviços está se tornando uma nova palavra da moda agora, é assim que você deseja rearquitetar seu aplicativo. Os microsserviços também vão para a tecnologia do lado do servidor, são usados em aplicativos de alta transação e precisarão de escalabilidade. Para qualquer outro aplicativo de servidor, muitas organizações grandes têm processamento em lote no back-end e precisam fazer o fluxo de trabalho no back-end. Um monte de aplicativos de servidor de back-end que precisam apenas tentar lidar com muitas transações, eles também precisarão de escalabilidade. Então, se sua empresa ou se você está engajado em algum desses tipos de aplicativos e quer ter aquele bom desempenho, esse é o papo para você.

O problema de escalabilidade

Então, agora que estabelecemos que esses aplicativos precisam de escalabilidade, há um problema de escalabilidade? Sim, existe e não está na camada do aplicativo, o ASP.NET core aplicação você pode facilmente adicionar mais servidores à medida que a carga da transação cresce e, geralmente, você tem um balanceador de carga na frente da camada de aplicação, que direciona o tráfego uniformemente para todos os servidores e, à medida que você tem mais e mais usuários, basta adicionar mais caixas, não há problema. O problema, claro, é o armazenamento de dados ou os bancos de dados. Estes são seus bancos de dados relacionais, seu mainframe e esta é uma das razões, porque NoSQL databases começaram a ganhar força, mas na maioria das situações você ainda precisa usar bancos de dados relacionais, por motivos técnicos e não técnicos. Então, se você olhar para a maioria dos aplicativos que vocês fizeram ou estão fazendo, você acaba usando bancos de dados relacionais no caso do .NET, o mais popular, é claro, é um servidor SQL. Então, se você não é capaz de usar um NoSQL database, de que adianta ajudar na escalabilidade? E a razão é que o NoSQL database pede que você abandone o banco de dados relacional e mova os dados para NoSQL, que para alguns dados você pode, para muitos dados de negócios você não pode, todos os seus clientes, suas contas, suas atividades tudo o que ainda precisa permanecer em um banco de dados relacional. Então, você tem que resolver esse problema de escalabilidade com bancos de dados relacionais na imagem e é por isso que eu digo isso NoSQL database nem sempre é a resposta porque você não é capaz de usá-lo.

A Solução (Cache Distribuído)

Então, a maneira de resolver isso, é claro, é usar um cache distribuído e é assim que um cache distribuído é implantado em seu ambiente.

Então, essa é a camada do aplicativo, em alguns casos, você pode ter um balanceador de carga na frente aqui, que está direcionando o tráfego para todos os servidores de aplicativos. Em alguns casos, pode não haver um balanceador de carga, pode haver alguma outra maneira de a carga estar sendo compartilhada porque esses são alguns aplicativos de back-end, mas de qualquer maneira, você tem vários servidores executando seus aplicativos. Então, isso é muito escalável, mas o banco de dados você não pode continuar adicionando mais e mais bancos de dados. Agora que as empresas de banco de dados relacional estão tentando fazer o máximo possível para escalar, por exemplo, elas têm tabelas na memória, que são muito mais rápidas. Acho que o SQL Server também não introduziu esse conceito de réplicas somente leitura onde elas estão, portanto, se você combinar tabelas na memória com réplicas somente leitura, obterá um aumento de desempenho, mas, como você verá, entrarei em esta. Quanto mais réplicas você cria, mais dor de cabeça você tem, em termos de atualização toda vez que você atualiza alguma coisa, tem que ser atualizado em todas as réplicas. Portanto, para obter o melhor desempenho com escalabilidade é preciso garantir que você não tenha mais de uma réplica. Portanto, uma cópia mestre e uma réplica de cada parte dos dados e, ao mesmo tempo, você precisa ser capaz de dimensionar. Então, a razão pela qual eles não podem fazer isso é que um banco de dados relacional não pode ser particionado da mesma forma que um cache distributivo pode ser ou um NoSQL database pode ser porque tanto o cache distribuído quanto NoSQL são pares chave-valor, que é um design muito diferente de um banco de dados relacional, mas no final, você precisa colocar um cache distribuído como uma camada de cache entre a camada de aplicativo e seu banco de dados.

Então, como isso se parece em termos de qual é a configuração? Então, normalmente estas não são caixas muito caras. Geralmente são caixas de 8 núcleos para 16 núcleos, muita memória de 16 a 32 gigabytes de memória e placas de rede de 1 a 10 gigabits. Às vezes, você tem duas placas de rede, uma para o clustering e outra para as ferramentas, tipo os clientes, mas é isso, isso é muito diferente de obter um servidor de banco de dados de ponta e muito poder de processamento para fazer seu trabalho porque há apenas um deles ou muito poucos deles. Então, não há outra maneira de contornar isso. Dizemos aos nossos clientes que não recebem mais de 64 GB de RAM por caixa, porque quando você tem mais de 64 GB de RAM em um ambiente .NET, essa memória deve ser coletada por meio da coleta de lixo e coletada à medida que você coleta mais e mais memória do que você precisa de mais poder de processamento. Então, você entra na mesma questão de começar a comprar caixas muito caras. É melhor obter memória de 32, 16 a 32 bits, 16 a 32 GB, mas mais caixas mantêm-no mais barato.

Como funciona um Cache Distribuído?

Então, o que um cache distribuído faz? Na verdade, ele cria um cluster e, novamente, estou falando de um NCache perspectiva, há também outros como Redis que fazem coisas semelhantes, mas de uma maneira diferente. Então, o cache distribuído vai construir um cluster, é um cluster baseado em TCP e o mais importante em um cluster é que assim como você não quer que o banco de dados fique inativo e em produção, você não quer que o cache fique descer também. Portanto, esse cluster precisa ser altamente disponível. Portanto, a melhor maneira de torná-lo altamente disponível para os clientes é garantir que ele tenha uma arquitetura ponto a ponto, onde cada nó seja um cidadão igual e qualquer nó possa cair ou você possa adicionar mais caixas, não há mestre- slave porque isso cria complicações e problemas de alta disponibilidade. Então, ele reuniu os recursos, memória, CPU e placa de rede como recursos. Então, à medida que você adiciona mais, digamos que você tenha mais e mais tráfego ou mais e mais transações, você adiciona mais servidores a seguir em uma proporção de 4 para 1, 5 para 1, você normalmente adicionaria mais caixas. Mínimo de dois servidores de cache e então você continua adicionando mais, então você começará com dois, você começará a ter cada vez mais carga e de repente tudo começará a desacelerar e você adicionar uma terceira caixa tudo melhora quando você adiciona mais carregar e adicionar mais caixas, aqui as coisas começam a desacelerar até um certo ponto. Você adiciona uma quarta caixa e a imagem desaparece.

Então, é assim que escala linearmente, em teoria, nada é ilimitado, mas escala para mais situações, escala de forma ilimitada onde não há gargalo. Assim, isso permite que seu banco de dados não se torne um gargalo. Portanto, isso se tornou praticamente uma prática recomendada essencial da arquitetura do seu aplicativo. Se você está fazendo aplicativos de alta transação, você tem que incorporar o cache distribuído e porque essa é a única maneira, você poderá obter desempenho porque é tudo na memória, qualquer coisa que toque o disco nunca pode ser tão rápido quanto em -memória e escalabilidade porque é distribuído. Alguma dúvida sobre isso antes de ir? Na verdade, no caso de NCache você pode. NCache suporta .NET e Java, mas se você tiver outros aplicativos como Python ou outros, não poderá usar NCache, você precisa usar outras soluções de cache, mas o aplicativo precisa estar em um ambiente escalável. Basicamente, não importa qual idioma você use, a funcionalidade permanece a mesma. Existem alguns benefícios, se você é um aplicativo .NET, então NCache oferece muitos benefícios específicos do .NET que é uma pilha .NET completa, sua pilha de cursos .NET, então se encaixa muito bem. Existem produtos semelhantes no lado Java também que são chamados de grades de dados na memória e, portanto, eles se encaixam muito bem na pilha Java. Por exemplo, vou apenas compartilhar algumas informações. Então, NCache tem uma API Java mas as únicas pessoas que usam a API Java são as que compram NCache ou uso NCache de uma perspectiva .NET. Então, eles têm NCache internamente e eles disseram que poderia usá-lo para Java e uma loja Java iria procurar uma grade de dados na memória baseada em Java, uma loja .NET procuraria NCache. Então, é assim que o mercado é segmentado por causa de toda a experiência, se você é uma loja .NET, você tem toda a experiência .NET versus Java. Então, por que complicar a imagem? Para bancos de dados, então banco de dados não SQL qualquer banco de dados pode ser usado? Qualquer um, qualquer um porque a maneira como você acessa o banco de dados é por meio de seu próprio código personalizado que reside na camada de cache.

Então, esse é outro recurso, que vou abordar é que um dos recursos essenciais para garantir que o cache permaneça sincronizado com o banco de dados é que seu código personalizado precisa estar no servidor de cache. Se você tornar o cache uma caixa preta, onde não há nada no cache, exceto dados, é como ter um banco de dados relacional sem gatilhos e procedimentos armazenados ou outras coisas. Então, isso limita o uso do cache. Então, os caches começaram como sendo apenas a caixa preta. Memcached era um cache popular, não fazia nada, era apenas uma loja e, com o tempo, eles evoluíram para uma entidade inteligente adequada, onde eles também podem executar seu código. Algum NoSQL, qualquer banco de dados relacional pode ser usado com ele. E, novamente, todos esses recursos dos quais estou falando são de código aberto e corporativos. Então, é por isso que estou mencionando porque é de código aberto. Alguma outra pergunta? Ao lidar com NCache é principalmente cache automático ou você usa API para armazenar em cache? Então, vou entrar em mais detalhes, mas depende do que você está armazenando em cache? Certos tipos de uso de cache são automáticos. Por exemplo, se você estiver colocando ASP.NET core sessões, então é um módulo conectável, ele apenas se conecta e começa a armazenar as sessões no cache, então não há nada que você precise fazer, mas se você for armazenar em cache os dados do aplicativo, é onde está a maior parte do benefício , então há uma API que você precisa chamar para determinar o que deseja armazenar em cache? Por quanto tempo você deseja armazená-lo em cache? Como você deseja sincronizá-lo com o banco de dados? Há muitas outras coisas, que você deve ter em mente. Então, vou falar sobre todos os recursos de como você deve usar o cache distribuído, como NCache para garantir que você possa armazenar em cache todos os tipos de dados, mas há uma API. Sim.

Usando cache distribuído

OK. Então, agora que estabelecemos que um cache distribuído é importante. Ele oferece desempenho e escalabilidade, vamos ver como você usa um cache distribuído e há três maneiras possíveis de usá-lo. Os três grandes casos de uso técnico.

Cache de dados do aplicativo

E o número um é o cache de dados do aplicativo, sobre o qual tenho falado até agora e entrarei em mais detalhes sobre isso em breve. No cache de dados do aplicativo, há uma coisa que você deve ter em mente que os dados existem no banco de dados e no cache. Então, existem dois lugares em que os dados existem, quando os dados existem em dois lugares, qual é a coisa mais comum que pode dar errado? Eles podem ficar fora de sincronia, então um cliente pode retirar esses milhões de dólares duas vezes do banco, uma vez do cache, alguns do banco de dados e você não quer ter essa situação. Essa situação era tão ruim no passado que as pessoas usavam quando você menciona a palavra cache, o pensamento que veio para a maioria das pessoas é que eu vou armazenar em cache dados somente leitura. Os dados nunca mudam, porque se eu armazenar em cache qualquer coisa que mude, eu não poderia ter problemas. Então, vou explicar como você pode garantir que isso não aconteça, mas essa é a coisa mais importante a ter em mente no cache de dados do aplicativo.

ASP.NET Core Cache específico

O segundo caso de uso é ASP.NET core- cache específico e há duas coisas que você pode armazenar em cache do ASP.NET core. Uma são as sessões, que são praticamente todas as ASP.NET core aplicação usa sessões e você no ambiente ASP.NET anterior, a Microsoft deu três opções de armazenamento InProc, servidor de estado e SQL e quarto foi o personalizado. Os três primeiros praticamente não funcionaram, mas o quarto permitiu que você conectasse um cache, mas em ASP.NET core eles realmente fizeram a coisa certa, que é o código git, eles realmente o arquitetaram para que seja baseado em uma interface IDistributedCache. Então, ele permite que você conecte uma loja de terceiros e você pode conectar algo como NCache e ele automaticamente começa a armazenar suas sessões e eu vou te mostrar como isso é feito.

A segunda coisa em ASP.NET Core é o cache de resposta, que é a saída da página que você pode armazenar em cache. Então, da próxima vez que essa página for chamada, a página nem deve ser executada, ela deve apenas retornar a saída se não tiver sido alterada. Se vai reproduzir a mesma saída novamente, por que eles executam novamente ou executam a página? Por que não apenas servir a saída, então é assim que o cache de saída foi chamado no ASP.NET, agora é chamado de cache de resposta. Agora é baseado em mais padrões HTTP. Portanto, você pode conectar o cache de conteúdo de terceiros na borda, o que não era possível, mas também abordarei isso. A diferença a ter em mente entre o cache de dados do aplicativo e o ASP.NET core caching é que diferentemente do cache de dados de aplicativos, onde existiam dois lugares que os dados existiam, agora os dados existem apenas no cache e como o cache está na memória, esses dados serão perdidos se algum servidor de cache cair, a não ser que haja replicação . Portanto, esse é um ponto muito importante para se ter em mente que qualquer cache que não oferece boa replicação não é adequado para sessões de cache ou outras tendências de dados.

Há um terceiro ASP.NET core- coisa específica que é chamada SignalR, na qual eu não vou entrar, se você tem aplicativos da web ao vivo, que podem dar feedback ao vivo, digamos que os preços das ações precisam ser atualizados o tempo todo. Então, isso também pode usar um cache distribuído como backplane, mas eu não mencionei isso.

Segurança

Qualquer dúvida nos dois primeiros e entrarei em mais detalhes, se necessário, sobre eles. Então, antes de tudo, o cache fica por trás do seu aplicativo. Ele vive entre o aplicativo e o banco de dados. Geralmente, em um ambiente bastante seguro. Temos clientes que mantêm o cache mais próximo, se seu aplicativo estiver na DMZ, eles podem manter o cache não na DMZ, mas atrás do firewall. Às vezes, eles o mantêm na DMZ, mas na maioria das vezes está em uma situação segura, mas muitos de nossos clientes de serviços financeiros, como grandes bancos e outros, não estão satisfeitos com isso, então eles querem mais títulos. Então, é aí que a Enterprise Edition do NCache tem recursos, onde pode fazer criptografia. Assim, todos os dados que você colocar no cache serão automaticamente criptografados com criptografia 3DES ou AES256 e também há segurança, que todas as conexões com o cache serão autenticadas através do Active Directory e haverá coisas de autorização. Assim, os recursos de segurança completos são incorporados à edição corporativa.

Um cliente médio não usa criptografia, a menos que seus dados sejam confidenciais. Portanto, se eles estão mantendo dados financeiros, há alguns problemas de conformidade ou HIPAA, portanto, se assim que você entrar em problemas de conformidade, mesmo que seu ambiente seja seguro, você terá que dar um passo adiante e é aí que você faria a criptografia . Então, NCache Enterprise, por exemplo, fará a conexão TLS entre o cliente e a camada de cache. Portanto, essa conexão em si é completamente segura, além de você ter criptografia embutida, portanto, todos os dados mantidos na memória também são mantidos de forma criptografada. E isso satisfaz muito, quero dizer, temos muitos clientes de serviços financeiros e eles estão totalmente satisfeitos com isso.

NCache pode ser implantado e a maioria de nossos clientes ainda o usa em uma situação local. Então, eles têm seu próprio data center onde seu aplicativo é implantado, então eles implantam NCache como parte de sua aplicação. Se você estiver na nuvem, NCache está disponível no Azure e na AWS e está disponível como VMs ou estamos prestes a lançar o serviço de cache gerenciado também, de qualquer forma, garantimos que NCache vive dentro de sua rede virtual na nuvem. Portanto, em um local, isso não é um problema, porque sempre em seu próprio ambiente, você apenas obtém várias VMs ou, se for seu próprio data center, obtém seus próprios servidores e os implanta com o aplicativo. Você instala NCache como software e é para instalações internas, você também pode usar o docker e viu todas as coisas que você esperaria que os aplicativos modernos fossem capazes de fazer, NCache vai fazer. E então, na nuvem, você pode obter as VMs ou obter o cache gerenciado, mas na nuvem, sempre faremos isso dentro de sua VPC no caso de AWS e vnet no caso de azure. Está dentro da sua rede virtual. Então, está perto do seu aplicativo, porque se não for, se você tiver que crescer em vários saltos, e digamos que fosse um cache hospedado, o que provavelmente é bom para aplicativos pequenos, mas qualquer coisa séria, NCache é quase sempre usado em aplicativos de missão crítica em que você está fazendo seus negócios por meio desse aplicativo. Então, é aí que você usaria NCache.

Então, nessas situações, você não pode se dar ao luxo de ter nenhuma lentidão e se você não pode ter lentidão, é aí que você quer todo o controle e manter o cache o mais próximo possível do aplicativo. Depende de qual caso de uso você vai fazer, então, por exemplo, o maior e mais rápido benefício são as sessões e você deve conectá-lo imediatamente sem nenhuma alteração de código. É apenas uma mudança de configuração. No caso do ASP.NET core, não é uma mudança de configuração. É uma mudança de código de arquivo de inicialização, mas muito pequena, mas se você deseja fazer cache de dados de aplicativos, ainda é uma mudança muito direta.

Deixe-me mostrar rapidamente como é a API. Então, olhe para esta API.

Conexão de cache

Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

Buscando dados

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");

Gravando dados

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

É apenas um pequeno cache.get, cache.add, Insert, remove. Então, você tem uma chave e um valor como seu objeto. Então, muito fácil de incorporar, mas você tem que ir e fazê-lo, então sempre que você obtém dados do banco de dados, você verifica primeiro o cache, se o cache o possui, você o pega do cache ou então você vai para o banco de dados pegue e coloque no cache, esse é o modelo. Exatamente. Vou acelerar caso contrário, não vou conseguir. eu vou te mostrar NCache um pouquinho mais tarde.

Mensagens e eventos do Pub/Sub

Portanto, as mensagens pub/sub também são um recurso muito poderoso. Muitos aplicativos hoje precisam coordenar o esforço. Eu estava conversando com alguém hoje, que disse que eles precisam fazer muita programação baseada em eventos. Assim, as mensagens pub/sub oferecem um modelo de programação orientado a eventos muito poderoso porque você tem uma infraestrutura em que é uma plataforma escalável na memória agora dentro de seu aplicativo, você pode pensar nisso como um barramento de mensagens. Não é para ambientes distribuídos. É para o mesmo data center um tipo de localização de uma situação, mas é super rápido porque está tudo na memória e é escalável. Então, esse é o terceiro caso de uso que você terá para usar um cache distribuído como NCache. Sim, ele faz, ele faz e o código aberto também suporta isso. Portanto, todos esses recursos estão disponíveis tanto em código aberto quanto corporativo, de fato, todos os NCache A API é praticamente a mesma entre código aberto e corporativo.

O que vimos com pub/sub é novamente se você tem um aplicativo de alto tráfego, alta transação, então você realmente precisa que o mecanismo pub/sub seja super rápido e é aí que NCache realmente brilha.

ASP.NET Core Cache de dados do aplicativo

OK. Então, cache de dados do aplicativo. Como você faz isso? Então, isso também é para responder lá, então há três maneiras de fazer isso.

IDdistribuídoCache

Você pode usar a interface IDistributedCache que ASP.NET core vem com e se você programou contra ele, você pode simplesmente conectar NCache como provedor. Portanto, não há mais nenhuma alteração de código depois que você fizer a programação da API IDistributedCache. Portanto, o benefício é que você programa uma vez e não fica preso a nenhum fornecedor de cache. A desvantagem é que é o mínimo denominador comum. Eu vou te mostrar o que parece, isso é tudo. Tem Get and Put, é isso. Você sabe Get, Remove and Set, enquanto há muito mais que você precisa fazer para fazer uso total do cache, que estávamos falando sobre o fato de que você deseja que o cache seja sincronizado com o banco de dados. Portanto, há prós e contras nisso.

Entity Framework Core Cache

A segunda é se você tem um aplicativo EF Core, você tem um aplicativo EF Core, é uma maneira mais simples de conectar NCache e eu vou te mostrar. Então, na verdade, implementamos métodos de extensão para o EF Core e, novamente, isso é open source e corporativo. Há a amostra do EF Core. OK. Portanto, se você tivesse um aplicativo EF Core, normalmente teria uma consulta do EF Core como esta, você buscaria algo usando a consulta de estilo LINQ. Então, nós implementamos um método de extensão, digamos FromCache, então eles são um monte de métodos, este é um deles, então isso dirá vá para o cache se esta consulta foi armazenada pela última vez no cache, pegue-a do cache. Se não estiver no cache, vá para o banco de dados, execute esta consulta de núcleo EF regular, obtenha-a e coloque-a no cache. Portanto, é apenas uma linha ou apenas uma chamada de método que começa automaticamente a armazenar em cache todos os dados que vêm do banco de dados. Assim, simplifica seu trabalho e você sabe exatamente onde plugar, não há muitas chamadas extras de API que você precisa fazer.

Portanto, para aplicativos principais do EF, novamente há alteração de código, mas o mínimo possível que você pode fazer e começar a armazenar dados em cache. Então, na verdade, para o EF core, eles são vários métodos, isso é FromCache, a maior parte é de, há apenas quatro ou cinco métodos que você pode usar, o FromCache, depois LoadIntoCache, FromCacheOnly. Portanto, e também com o EF Core, quando você salva as alterações, ele também atualiza o cache antes ou depois de atualizar o banco de dados, ele também atualiza o cache. Assim, o cache tem a versão atualizada dos dados. A integridade do cache é mantida em primeiro lugar, certificando-se de que qualquer dado que você mantenha no cache e eu pule, por exemplo, este é um servidor de cache. Digamos que você tenha dois servidores e digamos que você tenha três servidores. Todo o cache é dividido em partições, cada partição tem seu próprio conjunto de buckets, para que seus dados residam apenas em uma das partições. Então, e então esses dados são replicados para algum outro servidor, que é chamado de réplicas, mas as réplicas no caso de NCache não está ativo, é passivo seu aplicativo não fala com as réplicas. Seu aplicativo fala apenas com a partição. Portanto, como os dados são armazenados apenas em um local, não há problema de sincronização. Todo mundo vai para o mesmo servidor, mas como é particionado, nem todo mundo vai para o mesmo servidor, algumas chaves são armazenadas aqui, algumas são armazenadas aqui, algumas são armazenadas aqui.

Então, é assim que um cache distribuído é NCache é capaz de fazer o que o servidor SQL não pode fazer porque a natureza do banco de dados relacional é que você não pode particionar, mas a natureza do cache distribuído é que você pode e quando você particiona aqui, estes são três servidores, eles talvez sejam compartilhados por dez servidores de aplicativos e cada servidor de aplicativos pode ter quatro ou cinco ou seis ou oito processos de trabalho. Portanto, há muitos processos clientes diferentes conversando com o cache, não há problema de sincronização porque os dados reais são armazenados apenas em um local. Agora existem outras topologias em NCache que são replicados, onde os mesmos dados existem ativo-ativo e múltiplo e, nesse caso, NCache tem que sincronizar as mudanças. É baseado em token, é um algoritmo de atualização baseado em sequência, não é muito escalável. Portanto, não recomendamos para um ambiente de alta transação.

Cache particionado com replicação é a melhor estratégia ou chamamos de topologia de cache melhor para usar. Então, é assim NCache garante que, dentro do cache, os dados estejam sempre corretos. Isto respondeu a sua pergunta? Então, a porta que você mostrou, há alguma configuração ou configuração no código que diz, de qual cache ele deve buscá-la? Sim. Então, por exemplo, quando você entrar no app.config, você verá que ele vai dizer que você usa mycacheId e eu vou te mostrar o que é o cache. Então, quando você cria um cache em NCache. Cada cache recebe um nome e esse nome por trás da cena sabe onde está o cache, então tudo que você precisa fazer é especificar o nome aqui e então ele saberá para onde ir e obter o cache. E eu vou te mostrar como o cache realmente se parece. Um nome de cache está em todos esses servidores e dentro dos mesmos servidores você pode ter vários nomes de cache, no mesmo servidor você pode ter vários caches e um cache pode viver em vários e é um cache distribuído, o único nome de cache tem que viver em vários servidores é assim que é distribuído, mas os mesmos servidores também podem ser usados para outros nomes de cache, e cada nome de cache fornece seu isolamento. Boa pergunta.

High Availability

Então, é aqui que eu estava dizendo que a alta disponibilidade é muito importante. Se você não conseguir adicionar ou remover servidores em tempo de execução sem qualquer interrupção, seu aplicativo realmente não está altamente disponível. Temos clientes que estão executando NCache durante meses e anos sem qualquer paragem. Então, por exemplo, digamos que você tenha uma configuração de dois servidores e acabou de adicionar um terceiro servidor porque sua carga aumentou. Então, você precisa adicionar um terceiro servidor, tudo o que você fará é adicionar um terceiro servidor e eu mostrarei a você apenas através da ferramenta, basta adicionar um e NCache nos bastidores vai reparticionar. Portanto, essas duas partições agora serão transformadas em três partições. Alguns dos buckets daqui e daqui serão atribuídos à terceira partição automaticamente enquanto um aplicativo estiver em execução, seu aplicativo nem percebe isso. Nos bastidores agora que existe uma terceira partição e agora a réplica também existe uma terceira réplica que é criada, então digamos que a réplica 2 precisa ser movida aqui e a réplica 3 é criada aqui.

NCache mantém, por trás disso NCache usa chaves para mapeamento de hash, mas faz tudo dinamicamente, como um mapa de distribuição, que é como um mapa de bucket que é reparticionado e reatribuído. Assim, os dados realmente se movem de um servidor para outro automaticamente em tempo de execução.

Afinidade de local

Portanto, em alguns casos, você pode querer manter alguns dos dados juntos na mesma partição. NCache tem um recurso de afinidade de local, onde você pode especificar e, em seguida, especificará. Você dirá que esses dois dados estão relacionados, quero que esteja no mesmo servidor e, em seguida, NCache irá mantê-lo no mesmo servidor através de uma chave extra que ele cria em cima dele. Como eu disse, todos esses são recursos avançados, que você não obtém se apenas usar o mínimo denominador comum e, usando esses recursos, poderá ajustar NCache ao seu ambiente de acordo com suas necessidades especificamente.

Recursos de cache de dados do aplicativo

Então, a primeira coisa que eu queria abordar, esses tópicos, são muito importantes. Para o cache de dados do aplicativo, o mais importante é que o cache esteja sempre atualizado, o que significa que fresco significa que possui dados corretos, se os dados forem alterados no banco de dados, o cache terá os dados mais recentes.

Expirações baseadas no tempo

Portanto, a expiração é a maneira mais comum de os caches fazerem isso, quase todos os caches têm expiração como um recurso. NCache também tem. Há uma expiração absoluta e depois há uma expiração deslizante. A expiração absoluta é, digamos que você esteja adicionando dados ao cache, pode dizer ok após cinco minutos expirar isso porque não acho seguro mantê-lo no cache por mais de cinco minutos. Então, você está fazendo um palpite, que é seguro manter os dados no cache por cinco minutos e isso é bom o suficiente para alguns dados, para outros dados pode não ser.

A expiração deslizante é mais para quando você está armazenando sessões e está dizendo tudo bem depois que ninguém está usando, depois que todos terminarem de usar essa sessão, basta removê-la. Então, é mais uma expiração de limpeza. A expiração absoluta é a sincronização é mantê-la consistente com o banco de dados, o deslizamento é limpo, mas a expiração é um palpite informado, seja qual for o palpite errado

Dependências do banco de dados

Em alguns casos, você pode permitir que os dados sejam inconsistentes em alguns casos, você não pode. Então, se você não pode, então você tem que ter outros recursos, então é aqui que NCache realmente se destaca que é que, por exemplo, você pode ter uma sincronização do cache com o banco de dados. Então, NCache usa a dependência SQL incorporada ao SQL Server para monitorar o SQL Server. Então, você pode para cada item que você armazenar em cache, você pode dizer ok mapear isso com esta linha correspondente na tabela do banco de dados SQL, NCache monitora, se essa linha mudar, NCache em seguida, remove esse item do cache ou o recarrega novamente. Então, agora de repente você tem um cache inteligente, ele é capaz de garantir que tudo o que você está armazenando em cache sempre será consistente e isso é algo que você não obtém se o cache for uma caixa preta.

Então, você tem que ter esse tipo de inteligência com o cache, e as dependências do SQL são um recurso .NET, então é aí que NCache ser .NET ajuda se seu banco de dados for SQL. Agora, também somos dependência do Oracle que também é, usa as notificações do banco de dados Oracle e há outra maneira de fazer que é nossa notificação baseada em polling, que é mais eficiente, mas não é tão em tempo real e você também pode sincronizar o cache com fontes de dados não relacionais. Seus dados podem estar em um NoSQL database, pode estar na nuvem, pode estar em qualquer lugar e você deseja monitorá-lo. Assim, você pode criar o que chamamos de dependência personalizada, que é o seu código que reside no servidor de cache. NCache chama em um determinado intervalo, ele vai e verifica sua fonte de dados, se os dados mudam, ele notifica NCache, ok os dados foram alterados por favor remova isso ou recarregue-o.

Então, essa é uma área onde NCache é realmente muito forte. Se você deseja manter seus dados atualizados, precisa fazer essas coisas para garantir que o cache esteja atualizado.

Read-Through e Write-Through

Outro recurso é a leitura e a gravação. Então, agora isso é combinado com expiração e sincronização de banco de dados. Isso permite que o cache carregue dados do seu banco de dados e é assim que, por exemplo, se você tiver uma leitura, mostrarei como é uma leitura. É apenas uma interface que você implementa e seu código realmente reside no cache, então aqui está uma interface que você implementa neste código. Então, há uma carga da chamada de origem, ela fornece uma chave e, em seguida, NCache chama seu método, o servidor de cache chama seu método, esse código está sendo executado nos servidores, todos os servidores de cache, NCache chama esse método e diz, por favor, vá em frente e carregue esta chave porque ela não está no cache. Então, se eu fizer um cache.Get, eu acho que aquela chave não está no cache, ou eu retorno um null, dizendo que a chave não existe, ou se eu tiver uma leitura, eu posso simplesmente ir no cache, e NCache pode ir ao banco de dados e lê-lo para você. Assim, você sempre terá. Agora, isso é muito útil em muitos casos, onde você deseja apenas manter esses dados no cache sempre.

Assim, a leitura permite, quando você combina leitura com expirações ou sincronização de banco de dados, o que isso faz é quando os dados expiram NCache pode atualizá-lo automaticamente, por que removê-lo? Se você for recarregá-lo, da próxima vez, porque esses dados são necessários e você os expira apenas para mantê-los atualizados. Então, por que não basta ter NCache volte e recarregue. Se você tiver implementado a leitura, NCache fará isso automaticamente e a mesma coisa acontece, se os dados forem alterados no banco de dados ou na fonte de dados e esse recurso de sincronização descobrir isso, ok esse banco de dados mudou, então se você implementou a leitura, ele irá automaticamente recarregá-lo .

Da mesma forma, o write-through oferece outro benefício que é que, se você tiver um write-behind, poderá atualizar o cache. Então, alguns dados, não são tão sensíveis para atualizações, quero dizer, é claro, se são saldos de bancos de dados financeiros que você não quer fazer write-behind, mas em alguns casos, tudo bem se você puder apenas enfileirar as atualizações. Então, se você atualizar o cache, atualizar o cache é muito mais rápido do que atualizar o banco de dados, claro, mais escalável porque ele é distribuído e você atualiza o cache e informa NCache por favor, vá em frente e atualize isso, o banco de dados de forma assíncrona nos bastidores. Então, esse é o recurso write-behind, e agora de repente acelera seu aplicativo porque qual é o gargalo? Lê do banco de dados e grava no banco de dados. As leituras que você pode armazenar em cache, para que você nem vá para o banco de dados, mas as gravações tenham que ir para o banco de dados, você não pode dizer que o banco de dados é o mestre certo, então não há como contornar isso, mas o tipo de gravação por trás é fácil.

Então, esse é outro recurso que, se você o tiver, NCache de repente lhe dá mais impulso em seu aplicativo. Pergunta: Então, caso não seja possível escrever no banco de dados e fazer assíncrono, ele lançará uma exceção? Sim. Ele lançará uma exceção, você pode ter um retorno de chamada que é chamado por NCache e, novamente, o código é, esse código write-behind está sendo executado nos servidores de cache, mas o retorno de chamada está aqui, então ele notificará o cliente e seu retorno de chamada será chamado, para que você possa executar ações corretivas. Depois de se sentir confortável com esse cache, NCache pode sincronizar o cache com o banco de dados, você armazenará mais e mais dados em cache. Quanto mais dados você armazena em cache, mais o cache começa a se parecer com um banco de dados, o que significa que uma maneira de buscar dados com valor-chave não é inteligente o suficiente. Então, você precisa encontrar dados baseados em SQL, especialmente dados de referência.

Pesquisa SQL

Quando falamos sobre a consulta do EF Core, você está buscando dados com base em atributos, não apenas na chave. Portanto, se você puder pesquisar os dados com consultas SQL ou LINQ ou com o núcleo EF, isso tornará o cache muito mais rápido. Essa é outra maneira NCache se destaca é que uma vez que você coloca todos esses dados no cache, você pode pesquisar, você pode dizer me dê todos os meus clientes que estão baseados em Boston ou Nova York e ele fornecerá uma coleção de objetos de clientes do cache. Então, está começando a se parecer mais com um banco de dados e você está tirando toda a pressão desse banco de dados, especialmente para dados de referência. Portanto, a pesquisa SQL é muito importante.

OK. Agora eu quero te mostrar o que NCache parece ou qualquer cache se pareceria? Então, estou logado no Azure. Então, eu tenho duas VMs de servidor de cache. então, eu tenho dois servidores de cache, um cliente Windows e uma linha Linux porque há .NET Core, você pode estar executando o aplicativo no Windows ou no Linux e NCache funciona na verdade, os servidores de cache também podem ser executados no Linux por causa .NET Core Porque NCache é o .NET Core nativo.

Criar um cache

Então, eu sou, por exemplo, eu fiz uma área de trabalho remota para o cliente Windows. Na verdade, vou criar um cache, então meu cache terá dois servidores e eu terei um cliente Windows, um cliente Linux, e quando eu usar a palavra cliente, na verdade são suas caixas de servidor de aplicativos. OK. Então, eu vou usar isso NCache ferramenta do gerenciador. Agora, essa ferramenta faz parte da Enterprise Edition, mas você pode fazer as mesmas coisas por meio de ferramentas de linha de comando de código aberto ou arquivos de configuração, mas apenas para fins de conveniência, vou em frente e criar um cache.

Vou chamar meu cache democache como eu disse que todos os caches são nomeados.

Vou escolher uma topologia. Vou escolher cache particionado com replicação.

Farei a replicação assíncrona, então há uma replicação assíncrona e uma replicação assíncrona. A replicação de sincronização é quando você não pode se dar ao luxo de fazer assíncrona se forem dados mais confidenciais, dados financeiros e outras coisas em que você deseja que essas replicações aconteçam como parte da atualização, o que, obviamente, torna as coisas mais lentas, mas as torna mais.

Então, aqui está meu servidor de cache um, aqui está meu servidor de cache dois, então acabei de criar um cluster de dois servidores. ainda não está rodando. Vou adicionar dois nós de cliente. Este é o meu windows, havia um servidor. Então, 6 é meu cliente Windows e 7 é meu cliente UNIX. OK. Então, eu tenho dois servidores de cache e dois clientes normalmente, como eu disse, você terá no mínimo dois servidores de cache e quatro para um, cinco para um proporção entre os clientes e o servidor. Então, estou apenas começando o cache agora. Novamente, de um lugar, posso fazer tudo isso e o mesmo na próxima versão que estamos prestes a lançar, tudo isso é baseado na web, então na nuvem, você pode fazer isso. Vou abrir as estatísticas e são como monitoramento, são estatísticas perfmon.

Simule o estresse e monitore as estatísticas de cache

Vou testar e ver se meu cliente consegue falar com isso, agora essa caixa é um cliente. então, vou abrir o console do PowerShell. Eu vou ter dois parciais do windows e estou logado em dois Linux aqui, então eu tenho um Linux aqui, agora o Linux aqui. Direita? Aqui, preciso iniciar o PowerShell e aqui, também preciso importar meu módulo que não preciso fazer para windows, já está lá para mim e preciso fazer o mesmo aqui. Eu preciso iniciar o PowerShell no Linux e tudo bem, agora vou iniciar um cliente. Então, NCache vem com esta ferramenta de teste de estresse, o que facilita muito o teste de estresse em seu próprio ambiente. Para que você possa ver exatamente como NCache executa? Assim, você não tem que tomar uma palavra para o seu desempenho. Então, digamos aqui, estou fazendo cerca de 500 solicitações por segundo por servidor.

OK. Então, eu quero aumentar a carga, então vou para o segundo console e direi executar um teste de estresse novamente.

Agora, de repente, você verá que isso vai dobrar em dobro, certo, e deixe-me ir em frente e adicionar mais estresse. Eu chegarei a um dos Linux e direi a mesma coisa e de repente agora estou com mais de 1500 por solicitação. Então, agora eu sou um total de cerca de 3,000 solicitações por segundo, como deixe-me fazer outra e agora estou fazendo mais de 4,000 solicitações por segundo. Então, eu posso continuar adicionando mais e mais se eu tiver mais VMs, eu posso ou posso ter mais instâncias e você verá que em breve, uma vez, atinge o máximo de qualquer que seja e esses dois servidores devem ser capaz de lidar com pelo menos 50,000 solicitações por segundo, mas novamente isso é com o pequeno conjunto de dados, à medida que o tamanho do objeto aumenta, isso diminuirá, é claro, mas quando eu maximizar isso, vou em frente aqui e novamente isso é funcionando bem, não tenho uma terceira VM, mas tudo o que preciso fazer é apenas fazer isso e adicionar um terceiro endereço e direi concluir e adicionará uma terceira caixa aqui e fará todo esse particionamento ou reparticionando automaticamente para você.

Da mesma forma, se eu precisar derrubar qualquer uma das VMs, ele também fará isso. Sim, é isso, esse é o fim da minha conversa. Podemos responder a alguma pergunta? É a única solução nativa .NET, a única outra solução nativa foi AppFabric que foi descontinuado. Então, Redis não é uma solução .NET, embora a Microsoft a tenha escolhido para o Azure porque eles queriam ser independentes de tecnologia, então eles a escolheram, mas nós somos .NET nativos. Temos sido assim desde o primeiro dia e, até onde sabemos, somos a escolha favorita para o .NET.

NCache Adicionar ao carrinho

Comparação de edições

Baixar NCache