Acampamento de Código de Cidades Gêmeas
Dimensionamento de aplicativos .NET com cache distribuído
Por Iqbal Khan
Presidente e Evangelista de Tecnologia
Veja esta demonstração prática de um cache distribuído e aprenda as práticas recomendadas para usar um cache .NET em vários ambientes. Esta conversa abrange:
- Visão geral rápida dos gargalos de escalabilidade em aplicativos .NET
- Descrição 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 em um cache distribuído
- Exemplos práticos usando um cache distribuído
Visão geral
Obrigado a todos por terem vindo. Meu nome é Iqbal Khan. Está um lindo dia lá fora. Estou aqui de Tampa. Então, temperatura muito mais agradável aqui. Eu estava esperando um clima muito mais frio do que o que temos aqui. Então, obrigado por ficar dentro de casa. Eu sou um evangelista de tecnologia nesta empresa chamada Alachisoft. Nós somos os fabricantes de NCache. Apenas os próximos um ou dois minutos serão uma declaração de marketing. Assim, temos dois produtos para o espaço .NET. Um é o nosso principal produto chamado NCache que é um cache distribuído para .NET. Essa é a expertise que temos. Então, estamos neste espaço há cerca de 10 anos e é assim que construímos expertise neste tópico específico.
Temos outro produto chamado NosDB que é algo que lançamos no final do ano passado. É um código aberto NoSQL database para .NET. É como um recurso de nível MongoDB, mas .NET nativo e, novamente, tudo de código aberto. NCache também é de código aberto e, assim é NosDB. Por favor, dê uma olhada em nossos produtos.
Então, eu preferiria ter uma discussão mais interativa. Vamos passar por uma combinação de algumas discussões conceituais de arquitetura e alguns códigos-fonte. Assim, podemos realmente ver como você usaria um cache para seu aplicativo. Então vamos começar.
AMPLIAR
Vamos tirar algumas definições do caminho. O número um é; o que é escalabilidade. Escalabilidade não é desempenho. Portanto, se seu aplicativo tiver um desempenho rápido com 5 usuários, ele não será escalável, a menos que você possa ter o mesmo bom desempenho com 5000, 50,000 ou 500,000 usuários. Claro, se sua aplicação não funciona rápido com 5 usuários, então você precisa olhar para outros aspectos além do que vamos falar.
Escalabilidade Linear
A escalabilidade linear é mais uma terminologia de arquitetura de implantação. Se sua aplicação está arquitetada de forma que você possa adicionar mais servidores para incrementar sua capacidade, sua capacidade de transação, aliás quando eu uso a palavra escalabilidade estou falando principalmente de capacidade de transação, não estou falando muito De dados. Portanto, não estamos falando de terabytes de dados em termos de escalabilidade. Estamos falando de você pode lidar com muitas transações, muita atividade. Portanto, uma escalabilidade linear significa que você pode aumentar sua capacidade de transação apenas adicionando servidores e não há gargalos e é isso que queremos alcançar.
Escalabilidade Não Linear
Não linear, é claro, não é algo que queremos alcançar. Isso significa que não importa quantos servidores você adicionar, seu desempenho cairá depois de um certo ponto, porque há algum gargalo fundamental na arquitetura do aplicativo em sua implantação, que está impedindo que você possa escalar.
Quais aplicativos precisam de escalabilidade?
Que tipo de aplicativos precisam de escalabilidade? Geralmente são aplicativos do tipo servidor, ASP.NET, ASP.NET Core agora, Web Services, que geralmente são WCF, back-end IoT, que geralmente são serviços da Web, embora não precisem ser. Aplicações de processamento de big data. Eles geralmente são feitos em Java, mas se você fizer isso em .NET, terá o mesmo problema que em Java e em qualquer outro aplicativo de servidor que precise processar muitas transações. Você pode ser, por exemplo, um banco ou uma empresa de serviços financeiros com milhões de clientes. Eles estão ligando para você mudar de endereço, talvez transferir fundos e à noite você precisa processar tudo isso por conformidade ou por outros motivos de SLA. Então, mesmo que você tenha, você sabe, esses são mais processamento em lote, processamento de back-end, esses são seus outros aplicativos de servidor que ainda precisarão processar tanta informação e, se não conseguirem, você sabe, você está em um monte de problemas.
O problema de escalabilidade
Se você tiver esses aplicativos, provavelmente eles precisarão de escalabilidade. Então, vamos agora falar sobre onde está esse problema? Onde está o problema de escalabilidade, que vamos tentar resolver? O problema de escalabilidade realmente não está na camada do aplicativo. Seu aplicativo, todos os que eu falei, geralmente são arquitetados de forma que você possa adicionar mais servidores e não há problema algum. O problema é com o armazenamento de dados. O que quero dizer com isso é onde residem seus dados de aplicativos, seus bancos de dados relacionais. Pode ser SQL Server, Oracle, MySQL. Não é qualquer um fornecedor específico. O conceito de bancos de dados relacionais por design não pode ser dimensionado. Na verdade, eles também não podem escalar em termos de quantidade de dados. É por isso NoSQL databases tornaram-se tão populares, mas, especialmente no lado da transação e, o mesmo se você tiver um legado de dados de mainframe. Muitos aplicativos precisam acessar dados legados. Então, é aí que ocorre o gargalo e, se você tiver esse gargalo, não importa se essa camada for escalável, você não poderá escalar.
NoSQL databases tornaram-se populares exatamente por isso que fornecem escalabilidade. E, você sabe, e nós também temos um NoSQL database produto, mas muitas vezes eles não resolvem o problema. Eles não podem resolver o problema porque, por uma combinação de motivos técnicos e comerciais, você não pode usá-los. Para usar um NoSQL database você tem que colocar dados neles e não em seu banco de dados relacional. Alguns dados que você pode fazer. Você pode definitivamente colocar no NoSQL database mas muitos de seus dados de negócios tradicionais permanecerão em bancos de dados relacionais. Então, se você não pode mover seus dados para NoSQL databases, eles não são bons. Então, você tem que resolver esse problema, tendo em mente que você vai continuar vivendo com bancos de dados relacionais, mesmo que você coloque um NoSQL database na mistura, que é apenas um subconjunto dos dados. Geralmente não é uma substituição de bancos de dados relacionais. E, sendo um NoSQL database empresa, sabe, estou sendo muito honesto com você, quando falamos com nossos clientes, não dizemos para parar de usar o relacional, isso nunca vai acontecer. Dizemos, use-o como um aumento do relacional. Então, se você tem que ficar com o relacional, você tem que resolver esse problema, sabe, com isso na mistura e é aí que um cache distribuído entra em cena, é por isso que estamos tendo essa conversa.
Implantação de Cache Distribuído (NCache)
Um cache distribuído, deixe-me definir isso um pouco. Um cache distribuído é distribuído. Ele vive em dois ou mais servidores, aqui. É uma camada de cache separada, logicamente falando. Fisicamente pode estar na mesma caixa que o aplicativo, mas logicamente é uma camada de cache separada. Dois ou mais servidores e um cache distribuído geralmente formam um cluster. Então, geralmente é um cluster desses, clusters baseados em TCP são os mais comuns. NCache definitivamente usa TCP para clustering. E, esse cluster significa que todos os recursos, todos esses servidores, a CPU, a memória, as placas de rede, estão todos agrupados. E é assim que isso se torna escalável. Porque você pode adicionar mais servidores, pois precisa aumentar a capacidade.
Isso é algo que você pode fazer aqui também. Mas, você não pode fazer aqui. Como eu disse, você pode adicionar outro banco de dados SQL na mistura, mas, você sabe, você precisa ter isso na imagem. Assim que você tiver isso na foto, você precisará de algo assim no seu mix.
Um cache distribuído vive em servidores baratos. Essas não são configurações típicas de servidor da Web de banco de dados high-end. A maioria dos nossos clientes tem uma caixa de 8 núcleos, é como se fosse uma CPU dupla, agora usamos apenas a palavra 8 núcleos e uma de 64 bits com muita memória. Lotes significa que 16 a 32 giga é praticamente a média por servidor que vemos. Nós nem recomendamos mais de 64 giga em cada caixa. Porque, se você tiver mais de 64 GB de memória, o .NET requer coleta de lixo. O próprio GC é uma tarefa bastante demorada e começa a se tornar um gargalo por si só. Então, é melhor ter mais servidores do que ter poucos realmente sofisticados. Porque, você sabe, mesmo que o cache seja distribuído por design, agora o gargalo começa a se tornar uma coleta de lixo. E aprendemos isso através de muitas experiências dolorosas ao longo dos anos. Você sabe, tivemos clientes que subiram para 128 GB e, de repente, houve muita pressão na CPU. Então, eles tiveram que aumentar um pouco seu poder de processamento e começou a parecer mais um banco de dados. Então, você sabe, recomendamos que derrubá-lo.
Você armazena em cache os dados que residem no banco de dados. E, 80% do tempo você vai basicamente para a camada de cache, 20% do tempo você vai para o banco de dados. O cache é super-rápido na memória, muito mais rápido do que qualquer banco de dados, incluindo NoSQL database, inclusive mais rápido que o nosso NoSQL database. NCache é pelo menos uma ordem de magnitude mais rápida do que qualquer banco de dados. Porque, você sabe, os bancos de dados têm que ir para o disco. Mas, é claro que todas as atualizações precisam ir para o banco de dados real. Então, é aí que vêm os 20% mais, é claro, algumas das leituras.
Agora, se você fizer isso, de repente toda a pressão é retirada do banco de dados. Agora ele executa. Suas leituras são muito mais rápidas e as atualizações também são muito mais rápidas. Assim, você é capaz de alcançar essa escalabilidade, mas também é capaz, não apenas o aplicativo é escalável agora, como de repente é mais rápido. Embora, a principal razão para usar um cache não seja melhorar o desempenho, o que é o oposto do que as pessoas tradicionalmente pensavam, você sabe, que o cache existe para melhorar o desempenho. Isso é, em uma situação autônoma, sim, esse é o caso. Até os bancos de dados usam cache na memória. Nosso NosDB também usa cache embutido, mas é realmente para escalabilidade, onde você precisa ser capaz, porque esse é um problema do qual você não pode se livrar. Você não pode comprar hardware mais caro para obter escalabilidade. Você precisa arquitetar o aplicativo e usar a infraestrutura certa ou os componentes certos como parte de sua arquitetura, se quiser ter um aplicativo escalável.
No lado Java, isso é chamado de grade de dados na memória. No lado .NET, é chamado de cache distribuído. Outra palavra para isso é um in-memory NoSQL armazenamento de valor-chave. Então, quero dizer, há três maneiras diferentes de olhar para isso. Este não é um NoSQL database é um NoSQL valor-chave armazenado na memória. Porque, ele não faz nenhuma persistência, não tem um armazenamento permanente.
Então, quando você tem uma imagem como essa, arquitetonicamente eu quero que você se convença de que agora você terá um aplicativo que nunca terá gargalos. Se você arquitetar seu aplicativo para usar isso como para sua infraestrutura. Qualquer dúvida, até agora antes de passar para mais profundidade.
Eu acho que depende dos detalhes como você sabe, se o cache está obsoleto ou se você atualiza algo fora do caso? Deixe-me chegar a isso. Boa pergunta.
Usos comuns do cache distribuído
Então, digamos que estamos convencidos de que precisamos ter um cache distribuído como parte de nossa arquitetura de aplicativo, a próxima pergunta que vem à mente é como você o usa? Onde você usa o cache e quais são os problemas relacionados a cada tipo de uso? Então, como desenvolvedor .NET, e novamente meu foco é .NET, mas os mesmos conceitos se aplicam a outros aplicativos também.
Cache de dados do aplicativo
O caso de uso mais comum é o cache de dados de aplicativos, é disso que eu estava falando até agora, onde você tem um banco de dados e apenas armazena dados em cache aqui. Portanto, o objetivo é não acessar o banco de dados com tanta frequência. E, você obtém todos os benefícios que eu falei. Assim que você faz isso, há um problema que ocorre, que é o que você acabou de falar. Os dados agora existem em dois lugares. Um deles é o armazenamento mestre permanente, que é seu banco de dados, onde sempre deve e o segundo é o cache. E, de fato dentro da cache ela existe em mais de um lugar e vou falar sobre isso também.
Então, quando os dados existem em mais de um lugar, o que pode dar errado? Sabe, pode ficar fora de sincronia. Portanto, se um cache distribuído não puder lidar com essa situação, você será forçado a armazenar em cache os dados somente leitura. Na verdade, a maioria das pessoas, quando pensam em cache, a reação do empurrão do joelho é apenas para dados somente leitura. Porque, se eu armazenar em cache dados que mudam, o que estou chamando de dados transacionais. Então vai sair de sincronia. E, se você sabe, aquele problema clássico de sacar um milhão de dólares duas vezes da mesma conta bancária, vem aqui. Então, você sabe, se um cache não resolver esse problema, você estará limitado a um subconjunto muito pequeno. Cerca de 10% a 15% dos dados é tudo o que você pode armazenar em cache e isso não é suficiente. Então, um bom cache distribuído deve resolver esse problema e falarei sobre isso.
Cache específico do ASP.NET
O segundo caso de uso é, se você tiver um aplicativo ASP.NET, há três coisas diferentes que você pode armazenar nele. É claro que isso está mudando à medida que novas estruturas estão chegando. Então, o mais comum é o estado de sessão ASP.NET, que existe tanto no ASP..NET core e a estrutura ASP tradicional. Sessões são algo que, por padrão, você armazena no In-Proc ou no SQL Server. Ambos têm problemas de escalabilidade. SQL também tem problemas de desempenho. E, porque os bancos de dados relacionais não foram projetados para armazenar blobs e as sessões são armazenadas como blobs. E em segundo lugar, você sabe, pelo mesmo motivo que você deseja armazenar em cache os dados do aplicativo e não ir para o banco de dados, você também não deseja manter as sessões no banco de dados. Portanto, este é um caso de uso muito ideal para aplicativos ASP.NET. E, você sabe, essa é a primeira coisa que a maioria dos nossos clientes usa. Você sabe, se você tem um aplicativo existente e deseja incorporar o cache distribuído, o menor esforço necessário para incorporá-lo são as sessões. Porque, ASP.NET framework permite que um cache de terceiros seja conectado. Não há necessidade de programação. Você acabou de fazer uma alteração no web.config. Na verdade, deixe-me mostrar isso rapidamente. Eu só vou pular para frente e para trás.
Então, por exemplo, eu tenho esse pequeno aplicativo ASP.NET e tenho um web.config aqui e vou usar NCache como o exemplo, mas, digamos, para usar NCache como o provedor de estado da sessão, você precisa colocar esses assemblies. Então, “adicionar montagem” tag. Então, essa montagem de NCache implementou a interface do provedor de estado de sessão ASP.NET.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<machineKey validationKey="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24" decryptionKey="ACD8EBF87C4C8937" validation="SHA1" />
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
</compilers>
<assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" />
</assemblies>
</compilation>
<customErrors mode="RemoteOnly" />
<authentication mode="None" />
<authorization>
<allow users="*" />
</authorization>
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
<!-- For NCache Developer Edition replace 'myPartitionedCache' with 'myCache' or any other local-cache-->
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="1">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" exceptionsEnabled="true" enableSessionLocking="true" emptySessionWhenLocked="false" sessionLockingRetry="-1" sessionAppId="NCacheTest" useInProc="false" enableLogs="false" cacheName="myPartitionedCache" writeExceptionsToEventLog="false" AsyncSession="false" />
</providers>
</sessionState>
<!-- GLOBALIZATION
This section sets the globalization settings of the application.
-->
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<xhtmlConformance mode="Legacy" />
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />
</system.web>
<system.webServer>
<directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension, LongDate" />
</system.webServer>
</configuration>Então, é assim que está cumprindo o ASP.NET framework spec para ser um cache de terceiros. Então, essa é a primeira coisa que você faz e depois muda o namespace. Na verdade, você acabou de usar esta tag. Portanto, certifique-se de que o modo seja personalizado e que o tempo limite definitivamente não seja de um minuto. Deve ser 20. E, eu vou voltar a isso. Esse é o nome do cache.
No caso de NCache, todos os caches são nomeados. Eu vou voltar a isso. Então, isso é tudo que você faz e seu aplicativo começa a armazenar as sessões em um cache. E você verá imediatamente um aumento de desempenho, porque é na memória, muito mais rápido que o SQL. Não mais rápido que o In-Proc, mas mais rápido que o SQL, mas mais escalável em ambos os casos.
O segundo caso de uso para o ASP.NET é o estado de exibição, ou seja, se você não estiver usando a estrutura MVC, se ainda estiver no ASP.NET herdado, você terá um estado de exibição, que pode ou não conhecer. Um estado de visualização, para quem não sabe, é uma string criptografada que é enviada pelo servidor da web para o navegador apenas para voltar quando houver um post back. Então, isso pode chegar a centenas de kilobytes de tamanho. Multiplique isso por milhões de solicitações que seu aplicativo precisa processar e há duas coisas ruins que estão acontecendo, uma é consumir muita largura de banda e a largura de banda não é gratuita. Ao hospedar seu aplicativo, você precisa pagar pela largura de banda. Segundo, o tempo de resposta é mais lento porque é uma carga muito mais pesada. Portanto, se você pudesse armazenar isso em cache em um servidor, isso eliminaria tudo isso e tornaria o aplicativo mais rápido.
O cache de saída é um asp.NET framework que permite armazenar em cache a saída da página, de modo que, se a saída da página não for alterada, ela será apenas da última execução. Então, novamente, é melhor conectar um cache distribuído em um web farm do que manter cópias separadas desse cache de saída em cada servidor web. Na verdade, o que você quer fazer é tornar esses servidores da Web totalmente sem estado do ponto de vista do gerenciamento de aplicativos. Se eles são sem estado, você pode fazer todos os patches, você pode, você sabe, todas as correções de bugs, quaisquer atualizações em seu aplicativo, são muito mais frequentes do que quaisquer atualizações no cache em termos de atualizações de software. Portanto, se não houver nenhum estado sendo mantido aqui, você pode soltar qualquer uma dessas caixas do web farm, o usuário nem perceberá. Porque todo o estado está sendo mantido aqui ou no banco de dados e, novamente, não é algo que você toca com tanta frequência, então, novamente, armazene isso em cache.
Agora, no caso de cache específico do ASP.NET, há uma coisa boa que tudo isso não requer programação. Então, basta conectá-los imediatamente sem nenhum esforço. A única coisa que você faz, é claro, é algum teste de sanidade. Por exemplo, estado de sessão ASP.NET, se você conectá-lo e estiver usando sessões In-Proc, poderá descobrir que nem todos os seus objetos são serializáveis. E você não sabia e, de repente, seu aplicativo começará a lançar exceções. Então, quero dizer, você sabe, esse nível de teste que você precisa fazer. Mas, agora há outro problema peculiar, diferente deste onde você tem duas cópias dos dados, agora os dados existem apenas no cache.
Então, quando uma loja na memória é sua loja principal, o que pode dar errado? Máquina cai. Sim, você sabe, se algum servidor cair, você perde dados e não quer perder nenhum desses dados, especialmente as sessões. Então, um bom cache distribuído deve resolver isso e isso geralmente é feito através da replicação de que os mesmos dados existem pelo menos em dois lugares e se isso não acontecer, por favor, não coloque nenhuma sessão nesse cache, a menos que você não, não é realmente... não importa se seus usuários usam esta sessão, o que não é o caso na maioria das situações.
Compartilhamento de dados em tempo de execução
O terceiro caso de uso é compartilhamento de dados em tempo de execução através de eventos. Isso é algo que normalmente as pessoas faziam com filas de mensagens, que você sabe, elas têm seu próprio lugar e um cache distribuído não está aqui para substituí-las, mas um cache distribuído é muito mais rápido, mais escalável e se as mensagens ou se houver o compartilhamento de dados sendo feito no mesmo local, no mesmo datacenter, então você pode usar um cache distribuído em um Pub / Sub maneira, você pode fazer isso. Existem também outros tipos de eventos que você pode, sabe, mostrar interesse em determinados itens. Diga, se este item mudar, por favor me avise. Ou em caso de NCache há um recurso chamado consulta contínua onde você também pode fazer uma instrução SQL e dizer, 'SELECIONE CLIENTES ONDE CUSTOMER.CITY = NOVA YORK'. Se esse conjunto de dados for atualizado, excluído ou se um novo objeto for adicionado, atualizado ou excluído, por favor, avise-me. Então, se esse tipo de monitoramento que o aplicativo pode fazer e é assim que os consumidores podem ser muito mais espertos sobre o que eles querem ser notificados. E os produtores podem continuar atualizando o cache.
Então, esse é o terceiro caso de uso que muitas pessoas não conhecem, mas agora está se tornando cada vez mais óbvio que o cache é um bom lugar para fazer isso. Porque você já está usando o cache por esses dois motivos. Então, por que não colocar isso e isso é muito simples de incorporar em seu aplicativo. Alguma dúvida, antes de entrar nos detalhes destes?
Demo
Então, vou mostrar primeiro como é um cache. Então, podemos colocar isso no contexto de tudo o que estamos falando. usarei NCache como o exemplo. Então, eu tenho um monte de VMs no Azure. Então, eu tenho um demo1, demo2 e um cliente de demonstração. Demo1 e Demo2 são minhas VMs de servidor de cache. O cliente de demonstração é a caixa do servidor de aplicativos. Então, esse é o cliente de cache. Então, eu tenho tudo isso.
Eu vou e estou logado, digamos, estou logado no cliente de demonstração. Vou seguir em frente e criar um cache. Então, eu vou usar NCache Gerente, a ferramenta gráfica. Vou em frente e direi 'Criar um novo cache de cluster'.
No caso de NCache, todos os caches são nomeados. Não vou explicar todos os detalhes. Vou apenas dar um nome a cada cache.
Vou escolher uma topologia do cache. topologia é na verdade uma estratégia de armazenamento e replicação. Assim, uma topologia, no caso de NCache, digamos, há uma topologia chamada réplica de partição. Então, esses dois são servidores de cache aqui e cada servidor tem uma partição. Então, digamos em caso de NCache, NCache cria uma partição para cada servidor e cada servidor contém uma réplica da partição de outro servidor. Cada partição contém um enésimo do número total de buckets. No caso de NCache há 1000 buckets por cache.
Então, digamos, se for um cluster de dois nós, são os 500 buckets cada, se for um cluster de três nós, é um terço, um terço, um terço.
Réplica de partição, as partições estão ativas, as réplicas não estão ativas, são passivas. Então, o cliente só fala com as partições e digamos que se um cliente for atualizar um item aqui, a partição vá em frente e o replica para a réplica e essa replicação por padrão é assíncrona. Porque, para obter escalabilidade real, você precisa ir para esse modelo de consistência eventual. Mas, em alguns casos, seus dados são muito sensíveis. Você sabe, você tem muitas empresas de serviços financeiros como bancos que usam NCache e seus dados são, na verdade, dinheiro. Então, eles não podem fazer consistência eventual nesse caso. Então, aí você tem que fazer a replicação síncrona, o que significa que a aplicação espera até que os dados sejam atualizados nos dois lugares. Se um servidor ficar inativo, digamos, se você tiver um cluster de três nós e o servidor 3 estiver inativo, a partição 3 estiver inativa, a réplica 3 ficará imediatamente ativa.
Então, é assim que você obtém a alta disponibilidade e agora, uma vez ativo, ele perceberá que existem apenas dois servidores e três partições, o que não é como deveria ser. Então, ele se fundirá com a partição 1 e 2 e, uma vez feito isso, uma réplica para a partição 2 será criada aqui.
Tudo isso em caso de NCache é feito em tempo de execução sem que seu aplicativo perceba que isso está acontecendo. Da mesma forma, você pode ter um cluster de 2 nós e adicionar um terceiro servidor e novamente todo o mapa mudará daqui para aqui automaticamente. Então, isso é o que essa escolha significava.
Então, eu só vou escolher réplica de partição como a topologia.
Vou manter a replicação assíncrona.
Eu vou escolher meu primeiro servidor que é o demo 1, o segundo servidor que é o demo 2.
Vou pegar todos os padrões. Vou especificar, vou dizer, é apenas 1 Gig, vou especificar o tamanho da partição.
No seu caso se você tem uma máquina de 16 Gig, você deve deixar cerca de 2 a 2.5 Gig para o SO e outros processos e consumir todo o resto para o cache e qualquer que seja a memória que restar, metade dela deve ser partição ativa, metade dele é para a réplica.
Quando você está fazendo seu planejamento de capacidade, é muito importante que você aloque memória suficiente para que, no caso de sessões, as sessões tenham memória suficiente para ficar, caso contrário, quando o cache tiver usado toda essa memória, o cache será considerado cheio e, então apenas uma de duas coisas acontecerá, ou o cache rejeitará quaisquer novas entradas ou despejará algumas das entradas existentes. NCache fornece-lhe três algoritmo. Você sabe, o mais comum é usado menos recentemente.
então, NCache irá despejar imediatamente 5% do cache, quando o cache for considerado cheio. Então, agora que eu criei isso, vou em frente e adicionar um nó cliente que, neste caso, é o cliente de demonstração e vou em frente e direi iniciar o cache.
Então, quando estou iniciando o cache, muita coisa está acontecendo nos bastidores. Um novo cluster está sendo formado. A associação de cluster está sendo formada e está sendo propagada para o cliente. Então, que o cliente sabe o que é a associação do cluster? O que é o mapa de distribuição? Então, uma vez que tudo isso é feito, então tudo está pronto. Então, agora eu vou dizer estatísticas. Eu quero ver alguns PerfMon. E quero executar rapidamente essa ferramenta chamada ferramenta de teste de estresse, que é executada rapidamente. Ele testa rapidamente o cache em seu ambiente.
Então, dessa forma você não precisa fazer nenhuma programação para fazer isso. Então, é assim que o cache se parece. Você vai instalar algo assim. Digamos que você instale NCache. Leva apenas esse tempo para obter um cluster de 2 nós com um servidor de aplicativos configurado. No seu caso, você terá mais de um cliente, é claro. A configuração mais comum é de cerca de 5 a 8 clientes e cluster de cache de 2 a 3 nós. E então, você sabe, à medida que você adiciona mais clientes, você adiciona mais servidores.
Então, agora que você tem esse cache em execução, agora vamos voltar aos nossos tópicos atuais. Então, agora tudo o que fazemos você precisa ter em mente como criamos esse cache nomeado. E eu já mostrei a você o estado de sessão específico do ASP.NET.
Visão geral do cache de dados do aplicativo (API)
Então, agora vamos entrar no cache de dados do aplicativo, que é a riqueza da minha palestra hoje. Portanto, no caso de um cache de dados de aplicativo, há uma API para a qual você precisa programar. Porque, ASP.NET core agora tem uma interface chamada IDistributed Cache que você pode chamar essa API e, em seguida, nos bastidores, você pode plugar um cache de terceiros. No lado Java eles têm uma API muito poderosa como padrão chamada JCache, mas no lado .NET não há nada. Portanto, na maioria dos casos, você realmente precisará programar a própria API de cache. Mas, a API é muito simples.
- Conexão de cache
ICache cache = CacheManager.GetCache("myCache"); cache.Dispose(); - Buscando dados
Employee employee = cache.Get<Employee>("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); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
No caso de NCache isso se parece muito com o objeto de cache ASP.NET, se você notar. Então, o que você está fazendo basicamente é, você faz um cache.Get, você obtém o objeto, você sabe, cache dot Adicionar, Inserir, Remover ou e também existem versões assíncronas dele. Assíncrono significa não esperar que o cache seja atualizado apenas, você sabe, retornar o controle e você pode especificar a chamada de volta nesse caso.
Deixe-me mostrar rapidamente como é um aplicativo. Então, eu tenho esse aplicativo de console muito simples que usa NCache.
using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;
namespace BasicOperations
{
public class BasicOperations
{
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...
Então, a primeira coisa que você precisa fazer é certificar-se de fazer referência aos conjuntos de cache que, em caso de NCache são dois. Há NCache.Tempo de execução, NCache.Rede e então você precisa usar os espaços de nome que novamente são dois no caso de NCache. NCache.Tempo de execução, NCache.Web.Caching. E, depois, no início da sua aplicação, que no caso de console está logo ali. No caso do aplicativo ASP.NET, este é provavelmente o seu global.asax. Você precisa se conectar ao cache e é aí que entra o nome do seu cache, seja qual for o nome que você deu ao seu cache. É isso que entra aqui. E, agora que você tem um identificador de cache, você pode prosseguir com o aplicativo, criar seus objetos e fazer cache.Adicionar. Você especifica uma chave baseada em string e a chave deve ser exclusiva. A propósito, esta não é uma boa chave. Sua chave precisa ser muito mais específica e aqui está seu objeto. E, quero dizer, é assim que e mais tarde você pode fazer cache.Obter e você pode obter seu objeto do cache.
Agora, esta chamada que você fez realmente resultou em caso de NCache, então, quando você fez cache.Adicionar, basicamente foi, a partir daqui foi para a partição em que os dados deveriam entrar. Então, ele fez cache.Add lá e esta partição então replicou esses dados para sua réplica. Se fosse um aplicativo assíncrono, apenas essa partição seria atualizada e o controle voltaria. Se você fez uma chamada assíncrona, até mesmo essa partição e nem esperou que a partição fosse atualizada. Mas, apenas aquele cache.Adicionar chamada resultou em todo esse trabalho sendo feito.
E, da mesma forma, quando você faz um cache.Obter o cliente vai diretamente para onde os dados estão. Então, ele usa o mapa de distribuição abaixo para saber onde estão os dados e vai diretamente para onde e obtém isso. Digamos que, se você quisesse o item número 3, você o pegaria imediatamente de lá.
Então, esse código está nos bastidores, é isso que realmente está acontecendo. Para o banco de dados. Qual é seu. É apenas o cachê. Na verdade, falarei sobre isso daqui a pouco também. Então, você serializou / deserializou automaticamente os dados? Sim, na verdade ainda mais do que isso. Portanto, antes que os dados sejam enviados daqui para aqui, o objeto deve ser serializado. No caso de NCache, NCache mantém em um formato serializado, no cache. E, quando você faz um cache.Get, ele volta e depois é desserializado no próprio cliente. E, no momento em que você o obtém, está tudo desserializado. Portanto, a API parece muito direta para você, mas há muito trabalho sendo feito.
Recursos de cache de dados do aplicativo
Agora, sobre o cache de dados de aplicativos, a maior preocupação era que os dados existissem em dois lugares, certo? E, se um cache não resolver essa preocupação, isso realmente limitará seu benefício. Então, como um cache aborda essa preocupação?
Expirações absolutas
O número um é chamado Vencimentos e existe o Expiração Absoluta o que significa expirar este objeto, digamos, daqui a 10 minutos. Então, você faz um palpite para cada objeto em termos de quanto tempo é seguro manter esse objeto no cache. E, ao final desse tempo, o cache remove automaticamente esse objeto.
Deixe-me mostrar como isso se parece no código. Então, em caso de NCache se você olhar para a mesma chamada cache.Add, o terceiro argumento é um argumento de data e hora que tem o valor de um minuto a partir de agora.
public static void Main(string[] args)
{
try
{
//Initialize cache via 'initializeCache' using 'Cache Name'
//to be initialized.
Cache cache = NCache.InitializeCache("demoCache");
cache.Clear();
//Another method to add item(s) to cache is via CacheItem object
Customer customer = new Customer();
customer.Name = "David Johnes";
customer.Age = 23;
customer.Gender = "Male";
customer.ContactNo = "12345-6789";
customer.Address = "Silicon Valley, Santa Clara, California";
DateTime calendar = new DateTime();
calendar.AddMinutes(1);
//Adding item with an absolute expiration of 1 minute
cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
...Então, está basicamente dizendo que o cache expire este objeto daqui a um minuto. Não importa se você precisa ou não, após um minuto esse objeto será removido do cache. Por quê? Porque você não se sente confortável em mantê-lo no cache por mais de um minuto. E, por que você não se sente confortável? Porque, você acha que vai mudar no banco de dados. Não é seguro mantê-lo no cache.
Expirações deslizantes
Há outro tipo de expiração chamado Expiração deslizante, que serve a um propósito totalmente diferente. Não é para manter o cache atualizado, é mais para limpeza. Assim, no caso de sessões, por exemplo, NCache usa uma expiração deslizante, que diz basicamente, você especifica um intervalo e diz 10 minutos, 20 minutos, 5 minutos, você diz. Então, por tanto tempo, se ninguém tocar nesse objeto NCache remove esse item do cache.
Portanto, expiração deslizante, embora o nome ainda seja expiração, serve a um propósito totalmente diferente. É a expiração absoluta que você precisa para o cache de dados do aplicativo para manter o cache atualizado. Quase todo cache tem a expiração absoluta. Incluindo Redis, todo mundo tem.
Sincronizar Cache com Banco de Dados
Mas, o problema com a expiração absoluta é que você está apenas fazendo um palpite. E se esse palpite estiver errado e os dados realmente mudarem no banco de dados. Então o que acontece? Temos que criar um mecanismo. Então, você sabe, se você tem a capacidade de sincronizar o cache com o banco de dados onde você pode dizer ao cache para monitorar o banco de dados em busca de alterações para esse conjunto de dados muito específico, seja ele qual for.
NCache, por exemplo, usa esse recurso de dependência de cache ADO.NET SQL. Onde, se você especificar, se você usar esse recurso, deixe-me mostrar como ele é usado. Se você usar esse recurso, então NCache monitora o banco de dados e solicita que o banco de dados notifique NCache quando esses dados mudam. Então, digamos, eu tenho o exemplo de dependência SQL. Então, novamente estou fazendo o mesmo cache.Add, aqui. Então, estou fazendo o mesmo cache.Add. Eu tenho uma chave. Agora, em vez de ter o objeto, eu tenho um item de cache que é uma estrutura que contém o objeto real mais algumas outras coisas. Assim, por exemplo, ele contém uma instrução SQL de uma única linha na tabela de produtos. Como estou armazenando em cache um produto em um banco de dados Northwind, esta instrução SQL, NCache então use.
private static void AddProductToCacheWithDependency(Product product)
{
// Any change to the resultset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);
// Let's create SQL depdenency
CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);
CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlServerDependency;
// Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
_cache.Add(cacheKey, cacheItem);
}Então, há um SQLCacheDependency aula em NCache que é nossa própria classe, mas nos bastidores ela mapeia para a dependência de cache ADO.NET SQL. Agora, você está fazendo esta ligação no real e então, você está fazendo a ligação, você precisa ligar aqui. E essa chamada está chegando aos servidores de cache e o servidor de cache agora faz a chamada ADO.NET no banco de dados do servidor SQL. E, agora, o servidor de cache se torna um cliente do seu banco de dados. E, ele diz ao banco de dados, ele diz, por favor, notifique-me se este conjunto de dados mudar.
E, o servidor SQL tem o mecanismo de notificação de banco de dados tipo de oráculo. Pelo menos nesses dois bancos de dados, você pode usar esse recurso. E a dependência de cache do SQL permite que você essencialmente tenha certeza de que, se não conseguir adivinhar, ainda pode ter certeza de que seus dados permanecerão consistentes com o banco de dados.
Alguma pergunta sobre isso? Então, você tem quaisquer componentes de estrutura. Então, NCache também tem um plugin para EF, EF6 e agora EF Core também, até EF Core. Antes do EF Core, o EF não tinha uma arquitetura conectável. Portanto, tivemos que implementar um provedor ADO.NET personalizado e armazenar em cache as consultas SQL.
SQL Core é uma arquitetura muito mais flexível. Então, agora podemos fornecer um cache L2. NHibernate, que é algo que existe há muito tempo. O NHibernate tem essa arquitetura há muito tempo. NCache forneceu o cache L2 para NHibernate e também para Hibernate para o cliente Java. Mas agora o EF Core tem essa arquitetura. Portanto, o benefício do EF Core é que você não precisa fazer essas chamadas. A desvantagem é, claro, que é um subconjunto muito pequeno do cache que você usa, em termos de recursos. Porque todas essas outras coisas, por exemplo, a parte de dependência do SQL é algo que NCache fornece e você pode configurar isso através dos arquivos de configuração, mas também muitos outros recursos sobre os quais falarei que você precisa usar, que se você apenas passar por uma arquitetura conectável, eles precisam passar pela abordagem do mínimo denominador comum. Portanto, sua API, qualquer que seja o uso, não pode usar muitos recursos sofisticados, mas agora todos os caches os fornecem. Então, e eles precisam ser flexíveis para todos. Considerando que, se você quiser se beneficiar, por exemplo, no lado Java, quase todos os caches têm todos esses recursos de que estou falando. No lado .NET quase nenhum deles tem além de NCache. Então, não é realmente um NCacheÉ o fato de que, você sabe, o .NET não é tão avançado ou maduro quanto a comunidade Java no uso dessas práticas recomendadas. Então, está se tornando cada vez mais. O fato de agora .NET Core passou por uma mudança tão grande, é uma boa indicação de como as coisas vão melhorar.
Mas, a partir de hoje, não basta manter o cache sincronizado com as expirações do banco de dados. Você tem que ir além dos vencimentos. Você precisa sincronizar o cache com o banco de dados. E, se o banco de dados não suportar notificações, você pode passar pela abordagem de pesquisa, que é algo que NCache implementou.
Há uma terceira abordagem que é que você pode usar um procedimento armazenado CLR para adicionar diretamente os dados do banco de dados ao cache. Então, assim como você está invertendo todo o paradigma. Agora, o banco de dados está alimentando o cache. Então, você sabe, por exemplo, você tem um gatilho que pode fazer o... eu vou acelerar, senão eu não vou conseguir completar todos os tópicos. Portanto, esse é um recurso muito importante sem o qual você realmente não pode se beneficiar e também pode sincronizar o cache com fontes de dados não relacionais. Por exemplo, em caso de NCache há um recurso de dependência personalizado que é o seu código que pode fazer chamadas. Digamos que suas fontes de dados sejam uma nuvem e seja um método da Web chamado toda vez, para realmente saber quais são os dados. Então nada disso funciona e essa dependência personalizada é algo que funciona. Portanto, a dependência personalizada é seu código que reside no cache e é chamado pelo cache para verificar a fonte de dados.
Assim, depois de atingir esse objetivo, você pode começar a armazenar em cache mais e mais dados e realmente se beneficiar. Dependência de banco de dados, pois estou trabalhando com o mainframe agora, dependência de SQL ou dependência de Oracle não funciona. Então, com que frequência uma sondagem deve ser, porque estou trabalhando com dados de produção com vários milhões de transações de registros acontecendo em um minuto. Então, com que frequência. Então, como você sabe, com que frequência você pesquisa? A sondagem é um intervalo configurável e é o seu código que será chamado. Então, você determina em cada pesquisa, quantos dados você vai olhar. Porque, no caso de dependência personalizada, você vai realmente verificar uma chave específica e ver se essa chave foi atualizada em seu mainframe legado ou não. Então, é basicamente para cada chave quando vai como ok verifique esta chave, verifique esta chave. Em caso de dependência personalizada. No caso de dependência de banco de dados não é uma chave, é todo o conjunto de dados e temos outro recurso em NCache chamado atualizador de dados. Há um carregador de cache, é um atualizador de cache que é outro serviço onde seu código reside. Então, há um recurso chamado cache loader em NCache, que na verdade não mencionei todos esses recursos aqui, mas há um recurso chamado cache loader que é o seu código que pode, quando você iniciar o cache, carregar o cache, pré-carregar o cache da sua fonte de dados. Então, isso poderia ser o seu mainframe. Mas também há um recurso chamado atualizador de cache que chama automaticamente seu código a cada intervalo configurável e esse código pode verificar toda a fonte de dados e procurar atualizações com base em sua lógica personalizada e quaisquer dados alterados ou novos dados. ocorreu ou quaisquer dados foram excluídos, isso é algo que você também pode atualizar o cache. Assim, o cache permanece sincronizado com sua fonte de dados. Por padrão, eles são chamados em intervalos de cerca de 15 segundos. Mas, pode ser mais rápido. Pode ser mais frequente ou menos frequente, isso depende das suas necessidades. Eu respondi sua pergunta? Eu tenho mais, mas vou pular isso. Podemos falar sobre isso mais tarde.
Leitura e escrita
Assim, quando você atingir esse objetivo, começará a armazenar em cache mais e mais dados. Então a próxima coisa é, ok, agora você tem, que outros benefícios você pode alcançar? A próxima coisa mais importante é a leitura, escrita. O que é leitura? É novamente o seu código que fica no servidor de cache. Então, quando você faz um cache.Get, Então, digamos, um read-through é o seu código, no caso de NCache você implementa essa interface chamada IReadThruProvider. Tem três métodos.
...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
object connString = parameters["connstring"];
sqlDatasource = new SqlDatasource();
sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}
// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
sqlDatasource.DisConnect();
}
// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
cacheItem.ResyncOptions.ResyncOnExpiration = true;
// Resync provider name will be picked from default provider.
return cacheItem;
}
...Existe um Init que é chamado quando o cache é iniciado, descartado quando o cache para, mas o mais importante é essa carga. Então, a carga é chamada de passa. Então, o cache chama esse método. NCache chama esse método e passa sua chave. E, com base nessa chave, você acessa seu banco de dados e busca esse item. Então, quando você faz isso agora o efeito líquido para o cliente, o aplicativo é, toda vez que você faz um cache.Obter, o cache sempre terá os dados. Claro que se você não quiser que o read-thru seja chamado, você também pode fazer isso, você pode ter detalhes. Mas, o cache sempre tem os dados. Então, esse é um benefício. Então, você está consolidando sua camada de persistência em uma camada de cache. Então, se você tem vários aplicativos usando a mesma camada de cache, você sabe, o aplicativo está se tornando mais simples porque eles não precisam manter o mesmo código de persistência. Eles apenas fazem um cache.Obter e eles obtêm o objeto de domínio ou o objeto de entidade do cache. Então, o cache está muito mais parecido com um EF agora. A leitura em si pode ser baseada em EF.
A outra coisa que você pode fazer com a leitura é combinar isso com expirações e sincronização de banco de dados. Então, quando essas duas coisas acontecem, em vez de remover esses dados do cache, por que não recarregá-los? Porque, quando você removê-lo, o aplicativo terá que recarregá-lo de qualquer maneira, na próxima vez que quiser. E, em muitos casos, esses dados podem ser usados com muita frequência. Então, você realmente deseja recarregá-lo de volta no cache. Assim, uma leitura não apenas consolida o código, mas também melhora seu desempenho porque seu banco de dados não está sendo atingido. Em muitas das situações de comércio eletrônico, os mesmos dados podem ser acessados com tanta frequência que, assim que você os remover do cache, milhares de solicitações chegarão ao banco de dados para os mesmos dados e já vimos clientes reclamarem disso. Isso continua acontecendo com tanta frequência porque existem milhões de itens de dados à medida que cada item de dados expira e o banco de dados é atingido. Então, no geral, mesmo depois de ter o cache, eles estavam vendo muitos acessos no banco de dados. Então, a resposta para isso foi recarregar em vez de expirar. Portanto, o recarregamento significa que os dados nunca saem do cache, apenas são atualizados. Portanto, o banco de dados nunca é tocado, exceto por uma chamada de banco de dados que o cache faz. Então, a leitura é super importante nesse sentido.
O outro é o write-through que funciona exatamente como o read-through, exceto que ele faz a escrita. E, a gravação significa que pode ser adicionar, atualizar ou excluir. Agora, a escrita tem outro recurso. Um benefício do write-thru é o mesmo do read-thru, que é a consolidação do código.
write-behind
O segundo benefício é chamado write-behind. Você sabe, as atualizações do banco de dados, assim como as leituras do banco de dados, não são rápidas. As atualizações do banco de dados também não são rápidas. Então, se seus dados não forem tão sensíveis, se não for algo que você tenha que esperar que o banco de dados seja atualizado, você pode apenas atualizar o cache. Assim, todas as instâncias do aplicativo têm os mesmos dados agora e permitem que o cache atualize os dados para o banco de dados de maneira assíncrona. E, de repente, o desempenho do seu aplicativo melhora porque você não está esperando que o cache seja atualizado. Portanto, o write-behind tem esse benefício adicional. Então, ele constrói a fila. No caso de NCache essa fila é replicada para vários servidores, mas novamente leitura-através de gravação é um recurso muito importante. E, isso também é algo que é o seu código que vive no servidor de cache.
Quero que você tenha isso em mente, todo esse carregador de cache, o atualizador, a dependência personalizada, a leitura, a gravação, tudo o que é código do servidor que vive nele. O que é algo que... novamente, esses recursos também existem no lado Java. Então, não é apenas algo que NCache inventado, mas você não obterá esses recursos em nenhum dos outros caches básicos do .NET.
Então, uma vez que você começa, uma vez que você tem tudo isso, uma vez que você faz isso, agora você coloca muitos dados no cache. Realmente começando a se beneficiar. E, se um cache é apenas acesso a valor-chave, você sabe, não é muito amigável. Portanto, um cache deve acomodar maneiras amigáveis de buscar dados.
Agrupamento de dados
Então, no caso de NCache há muitos dados que você pode fazer, você pode fazer grupo e subgrupo, tags, tags de nome. Você também pode pesquisar com base em SQL ou LINQ. Então, você pode fazer algo como, 'SELECIONE CLIENTES ONDE CUSTOMER.CITY = NOVA YORK'. E agora, de repente, muitos dos seus conjuntos de dados, especialmente os dados de referência que você precisa ler repetidamente de uma maneira mais filtrada, podem buscá-los diretamente do cache. E agora você tem o benefício dos dados que deseja fazer.
Uma coisa, lembre-se, sempre que você faz uma pesquisa SQL, todo o conjunto de dados deve existir no cache. Porque isso não irá para o banco de dados. Assim, ele irá apenas pesquisar o cache. Digamos, se você dissesse me dê todos os clientes baseados em Nova York. Se todos os clientes não estiverem no cache, se todos os clientes de Nova York não estiverem no cache, o NCache ou qualquer cache não fornecerá o conjunto de dados correto de volta. Então, é importante ter em mente que as pessoas muitas vezes confundem isso bem se eu pesquisar, se eu esperar, se não estiver no cache, vamos buscá-lo no banco de dados. Mas, as consultas SQL não são as consultas SQL do banco de dados. Essas são as próprias consultas do cache.
Agora muitos dados, você pode manter todo o conjunto de dados no cache, especialmente os dados de referência e é aí que você os usaria. Mas, pelo menos também dentro dos dados transacionais, existem subconjuntos que podem ser totalmente mantidos no cache. Então, é assim que você espera. Então, mantendo tudo isso em mente, agora você está começando a se beneficiar do cache.
Cache de cliente
Eu vou entrar em mais uma coisa que é esse recurso chamado Cache de cliente. Uma das coisas que as pessoas ficam realmente chocadas quando começam a usar um cache distribuído é que, se estivessem especialmente se estivessem usando um cache In-Proc antes, isso é autônomo, é que seu desempenho realmente cai. Então, muitos clientes nos ligam e dizem, você sabe, você estava dizendo isso, o desempenho vai aumentar, a escalabilidade vai melhorar, nosso desempenho realmente caiu. E, a razão é porque inicialmente eles tinham apenas um cache autônomo. Era limitado em tamanho, mas o cache estava em forma de objeto, os objetos eram mantidos em seu heap e agora eles têm que ir para um cluster de cache, há uma serialização, desserialização, houve uma viagem de rede, é muito mais lento.
Então, para trabalhar para corrigir esse problema, muitos dos caches, novamente eu uso a palavra muitos porque todos os caches do lado Java têm, o lado .NET NCache tem. Eles têm esse recurso chamado cache do cliente. No lado Java, é chamado de cache próximo. Este é o mesmo cache autônomo que você tinha anteriormente, mesmo significa semelhante, mas agora está ciente do fato de que faz parte desse cache clusterizado. Portanto, quaisquer que sejam os dados que estão sendo mantidos, estão sendo sincronizados com eles com o cluster de cache. Então, ele apenas se conecta sem que você faça nenhuma programação.
Portanto, com a ajuda de um cache de cliente, você pode obter esse desempenho de cache autônomo In-Proc e é muito bom para muitos dados em que você está fazendo muito mais leituras do que gravações. Você não quer usar isso para algo como sessões. Porque, nas sessões você faz uma leitura e uma escrita. Portanto, você precisa fazer muito mais leituras do que gravações para se beneficiar.
Cluster de cache dinâmico
Então, arquitetonicamente, você precisa ver que o cache é como o banco de dados agora. Ele mora em seu datacenter, seu ambiente de produção e se sua aplicação tem uma necessidade de alta disponibilidade então o cache também deve estar altamente disponível, caso contrário você sabe, você tem um problema. E a única maneira de fazer isso é se o cache garantir 100% de tempo de atividade. Então, um bom cache, no caso de NCache ele tem uma cluster de cache dinâmico. É uma arquitetura ponto a ponto. Você pode adicionar ou descartar qualquer servidor e está tudo bem, nada para. O cache não para, o aplicativo não para.
Escalabilidade linear com replicação
Então, nós conversamos sobre a partição e então o topologias já. A replicação tem que ser feita de forma inteligente. Portanto, no caso de réplica de partição, ele faz apenas uma cópia. Assim, os dados existem apenas em dois lugares e não mais do que dois, porque cada vez que você faz cópias custa mais tempo ou esforço. Isso atrasa as coisas.
Replicação WAN de Cache Distribuído
Há também um recurso chamado Replicação de WAN. Muitas pessoas têm vários datacenters agora. Se você espera que seu banco de dados seja capaz de lidar com vários datacenters, por que não o cache? Este é um recurso que a maioria dos caches Java possui, NCache tem também, mas apenas no lado .NET.
NCache vs Redis
Apenas rapidamente uma última coisa que é, já que, no lado .NET, você sabe, existem realmente apenas duas opções. Um é NCache, um é Redis. Redis na verdade, é mais de um cache baseado em Linux, mas, desde que a Microsoft fez parceria com eles no Azure, eles certamente se tornaram muito mais populares. Então, eu queria dar como uma comparação justa.
A propósito, se você for ao nosso site e for para o página de comparações e vai para recurso detalhado por comparação de recursos com base em sua documentação e nossa documentação e veja todas as coisas. E, isso não é um, você sabe, nós não estamos cuspindo isso e você pode ser um bom juiz disso. É apenas para tornar seu trabalho mais fácil de preparar.
Mas, ambos são de código aberto, mas NCache é .NET nativo para pessoas .NET, você sabe, toda a sua pilha é .NET. NCache permite que você tenha código .NET no lado do servidor que você não pode fazer com Redis. E, você sabe, se você estiver no Azure, Redis está disponível apenas como um cache como serviço, enquanto que intencionalmente não escolhemos esse modelo. Porque, no cache como serviço, o cache é uma caixa preta. Portanto, você não tem nenhum dos recursos do lado do servidor sobre os quais acabamos de falar. E com o modelo VM você tem controle total.
A maioria de nossos clientes são empresas de alto nível que realmente não querem abrir mão de seu controle. É como banco de dados SQL versus servidor SQL. Então com NCache, você sabe, você vai controlar todo o seu ambiente e é como você viu, é bem simples de fazer. Mas você obtém todos esses recursos do lado do servidor com NCache, o que você não faz porque com Redis porque você não tem acesso.
Portanto, decida-se novamente, mas no mínimo use um cache distribuído em sua arquitetura. Certifique-se de que está pronto para escalar. Esse é todo o objetivo. Muito obrigado.