Campo 27 do Código de Boston
Dimensionamento de aplicativos .NET com cache distribuído
Por Iqbal Khan
Presidente e Evangelista de Tecnologia
Seus aplicativos .NET podem enfrentar gargalos de banco de dados ou armazenamento devido ao crescimento na carga de transações. Saiba como remover gargalos e dimensionar seus aplicativos .NET usando cache distribuído. 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
Meu nome é Iqbal Khan. Eu sou um evangelista de tecnologia na Alachisoft. Somos uma empresa de software com sede na área da baía de São Francisco. Estou pessoalmente baseado em Tampa, mas temos este produto chamado NCache. É um cache distribuído .NET. Hoje vou falar sobre como você pode escalar aplicativos .NET com cache distribuído. Isso não é uma conversa sobre NCache, é sobre o problema de escalabilidade e como você pode resolvê-lo com cache distribuído. O que você deveria fazer? Como você deve usá-lo? Quais são algumas das melhores práticas? Se você tiver alguma dúvida, sinta-se à vontade para me parar. Assim, podemos ter uma discussão mais interativa. Deixe-me começar.
O que é escalabilidade?
Então, vamos tirar algumas definições do caminho. O número um é a escalabilidade. Escalabilidade não é desempenho. Você pode ter um aplicativo que funciona muito bem com cinco usuários, mas só é escalável se funcionar da mesma maneira com 5,000 ou 50,000 ou 500,000 usuários. Portanto, escalabilidade é realmente alto desempenho sob cargas de pico. Se o seu aplicativo não estiver funcionando bem com 5 usuários, você precisará participar de outras palestras.
Escalabilidade Linear e Escalabilidade Não Linear
A escalabilidade linear é mais um conceito de implantação de aplicativos. Ao implantar seu aplicativo, se você puder adicionar mais servidores à implantação e, adicionando mais servidores, se puder aumentar a capacidade de transação de maneira linear, a arquitetura do aplicativo será linearmente escalável, caso contrário, não será linear.
O que isso significa é que, após um certo número de servidores, adicionar mais servidores realmente piora as coisas, o que significa que há alguns gargalos em algum lugar em seu aplicativo que não estão sendo resolvidos apenas adicionando mais servidores. Você definitivamente não quer escalabilidade não linear e definitivamente quer escalabilidade linear em seu aplicativo.
Que tipo de aplicativos precisam de escalabilidade?
Que tipo de aplicativos precisam de escalabilidade? Esses são aplicativos ASP.NET. Estes são serviços da web. Estes são back-end de IOT, que são principalmente serviços da web. Estes são aplicativos de processamento de big data, que não são tão comuns em .NET, cada vez mais deles estão sendo feitos em Java, mas mesmo assim esses são os aplicativos que também precisam de escalabilidade e qualquer outro aplicativo de servidor. Por exemplo, você pode estar trabalhando para um grande banco que tem milhões de clientes e eles, você sabe, os clientes ligam para fazer alterações de endereço ou talvez eles queiram que um novo cartão seja emitido ou talvez estejam transferindo fundos de um conta para o outro e todas essas transações precisam ser processadas dentro de um prazo predeterminado para fins de conformidade. Portanto, você terá que lidar novamente com milhões de solicitações dentro de um período de tempo que talvez não seja capaz de fazer em um único computador. Então, você precisa ser capaz de escalar mesmo nesse caso. Então, se você tem algum desses aplicativos que precisam de escalabilidade, então esta é uma conversa certa, a que você veio.
O problema de escalabilidade
Então, vamos definir o problema de escalabilidade também. Qual é o problema de escalabilidade? Bem, a camada do aplicativo é dimensionada de maneira linear. Você pode ter um aplicativo da Web ASP.NET ou serviços da Web. Você terá um balanceador de carga na frente dele que roteará o tráfego uniformemente para todos os servidores. Você pode adicionar mais servidores, sem problemas. Tudo funciona perfeitamente bem. Eu estava conversando com alguém mais cedo sobre o banco de dados se tornar um gargalo e eles não estavam concordando comigo. Então, acho que esta é uma boa oportunidade para ter essa discussão.
Assim, o próprio banco de dados executa super-rápido. Não há problema com desempenho. Os bancos de dados são muito inteligentes, eles fazem muito cache de memória em seu próprio servidor, mas a escalabilidade é algo que eles, por design, não podem alcançar porque você pode adicionar, por exemplo, 10, 20, 30, 40, 50 servidores neste nível. Temos clientes com 50 ou mais servidores em sua camada de aplicativo porque eles têm muitos usuários. Imagine que você é um grande banco ou uma companhia aérea. Você tem milhões de pessoas que estão acessando seu site. Você fez essa grande promoção para uma passagem para o Havaí ou algo assim. Todo mundo vai vir, eles vão fazer a busca de voos, eles querem comprar as passagens. Você pode adicionar mais servidores aqui sem problemas. O banco de dados estava funcionando super-rápido e o software é ótimo, mas o banco de dados de design não é um banco de dados distribuído. Ele é mantido em um só lugar. Talvez você possa ter um cluster de dois servidores, ativo-ativo, ativo-passivo, mas eles são mais para confiabilidade do que para escalabilidade, na verdade.
Então, você não pode realmente ter 10 servidores aqui, a menos que seja um NoSQL database, então você pode. Mas, para um banco de dados relacional qualquer um deles pode ser SQL server, Oracle, Db2, MySQL, eles são super rápidos. Eles podem até estar fazendo muito processamento na memória, mas se tornarão o gargalo à medida que você precisa dimensionar cada vez mais. E basicamente, quando você tem mil ou mais usuários simultâneos ou simultâneos, você começa a notar problemas de desempenho e à medida que cresce mais de 1,000 para 5,000, 5,000 para 10,000, é aí que você começa a ver mais. Então, o que vimos é que, quando você tem 1000 usuários, pode ou não usar o cache, mas à medida que cresce para 5,000, 10,000, 15,000 usuários, você definitivamente sente a dor e acaba com essa escalabilidade gargalos.
Agora, bancos de dados relacionais ou bancos de dados legados de mainframe têm esse problema. É um dos motivos NoSQL databases movimento começou foi por causa disso. Embora, também tenha outros benefícios e tenhamos um produto. Deixe-me vir rapidamente para fins de referência. Então, temos um produto de cache, mas também temos um NoSQL banco de dados de documentos. Assim como o documento DB, é um banco de dados de código aberto.
então, NoSQL database definitivamente não tem os problemas de escalabilidade. Mas, nem sempre é a resposta. Por que é que? Porque para ser uma resposta, um NoSQL database quer que você armazene todos os dados nele. Portanto, a menos que você armazene seus dados em um NoSQL database o que significa que você para de usar o banco de dados relacional para pelo menos essa parte dos dados, isso não resolverá seu problema. Então, em muitos casos, você pode mover alguns dados, muitos dados para um NoSQL database e é isso que está impulsionando o NoSQL movimento. Mas, bancos de dados relacionais, dados de mainframe legados, eles vieram para ficar. Eles não são algo que você pode simplesmente desejar por motivos técnicos e comerciais. Então, quaisquer que sejam os problemas de escalabilidade que você tenha que resolver, você tem que resolvê-los com bancos de dados relacionais na imagem. É por isso NoSQL database nem sempre é a resposta.
A solução: cache distribuído na memória
E a maneira como você resolve esse problema é uma nova prática recomendada que surgiu nos últimos cinco a dez anos, que é o cache distribuído na memória. Algumas pessoas também chamam isso de grade de dados na memória. A Microsoft costumava chamar a malha de dados. Embora, eles continuem mudando suas definições. Mas é um armazenamento de valor-chave distribuído na memória e é uma parte essencial de sua arquitetura agora. Se você quer um aplicativo escalável, você precisa programar, você precisa desenvolver seus aplicativos com um cache distribuído em mente. Assim, você pode ter certeza de que o aplicativo nunca se tornará um gargalo.
Agora, o que é um cache distribuído? São essencialmente dois ou mais servidores de baixo custo. Estes não são servidores de banco de dados high-end, são caixas do tipo servidor web. Normalmente, uma configuração de CPU dupla e 8 núcleos é bastante típica. 16 GB de RAM é praticamente a média. Vemos 16 a 32 giga é como o ponto ideal da memória. Mais de 64 giga, nem recomendamos aos nossos clientes. Dizemos adicionar outra caixa em vez de tornar esta caixa mais forte. Porque, se você adicionar mais de 64 gigas, um aplicativo .NET terá essa coisa chamada coletor de lixo, que consome muito poder de processamento. Portanto, quanto mais memória você tiver, mais rápido a CPU precisa ser para que o coletor de lixo possa coletar toda essa memória.
Portanto, é melhor ter mais servidores do que ter poucos servidores realmente sofisticados. Mínimo de 2, claro, porque você quer confiabilidade. Caso algum servidor fique inativo, mas depois dessa proporção de 4 para 1 ou 5 para 1, então, normalmente você teria, digamos, 2, 3, 4 ou 5 servidores na camada de aplicativo. O mais comum que vemos é entre 4 e 10 e, claro, há muitos clientes que usam mais de 10, mas 4 e 10 é praticamente o que vemos como esse ponto ideal. E, para isso, você usa um cluster de 2 servidores. À medida que você cresce mais de 10 ou 12, você adiciona um terceiro ou quarto e assim por diante. E, como um cache distribuído é um armazenamento de valor de chave, ele é distribuído. Ele replica dados em vários servidores de maneira inteligente, para que você obtenha confiabilidade, mas ao mesmo tempo não gaste muito tempo replicando. Por exemplo, se todos os dados tivessem que ser replicados para todos os servidores, seria muito processamento extra que você não precisaria. Então, é esse tipo de replicação inteligente que ele precisa fazer. Às vezes, você precisa ter replicação dessa maneira, mas esses são casos especializados. Então, um cache distribuído quando você tem isso no lugar, você vai até ele cerca de 80% do tempo. Todas as leituras serão feitas a partir dele e todas as atualizações e algumas das leituras serão feitas no banco de dados e também no cache. Portanto, se você conseguir prender cerca de 80% do tráfego do seu banco de dados no cache, de repente seu banco de dados ficará muito leve. Não tem muito o que fazer. Então, o que quer que tenha que fazer, ele fará muito mais rápido. Assim, o desempenho melhorará, bem como a escalabilidade.
Este cache de distribuição na memória, seja NCache, seja isso Redis no lado .NET, no lado Java há mais players, qualquer produto que você escolher cache distribuído é uma boa prática agora. Você tem que incorporar isso em sua arquitetura.
Alguma dúvida sobre isso até agora, antes de prosseguir? Então, sim, um cache lógico pode abranger vários servidores. No caso de NCache você pode ter vários caches nos mesmos servidores. Assim, cada cache se torna seu próprio contêiner para fins de isolamento, mas qualquer cache pode abranger todos os cinco servidores. Quando digo span, significa que alguns dados estão em um servidor, alguns em outros, você sabe, e então a replicação é uma parte separada dele que pode ou não ser feita dependendo de suas preferências. Mas, sim, todos os servidores são usados para armazenar esse cache e o cache tem que ser coerente. Tem que estar sempre correto ou você pode dizer que tem que estar eventualmente correto, mas bem perto de estar sempre correto. O que quer que você armazene no cache, se você atualizar, não importa onde estão os dados, provavelmente nem sabe onde estão os dados. Tudo o que você sabe é que este cluster tem meus dados e sempre que busco, posso tê-los armazenado neste servidor e estou tentando lê-los aqui imediatamente depois e devo conseguir obter a mesma cópia. Se eu puder fazer isso, isso se tornará um cache consistente ou coerente. Portanto, essa integridade de dados para atualizações sempre garante.
Essa é a sua preferência e vou entrar em mais detalhes em termos de como você realmente usa o cache. Então, uma coisa que você deve... quero dizer, o principal objetivo de até agora é convencê-lo de que se você quer escalabilidade você precisa ter isso como parte de sua arquitetura.
Usos comuns do cache distribuído
Então, agora que, digamos, concordamos que você precisa de um cache distribuído, a primeira pergunta que vem à mente é como você o usa? Onde você usa? para que você usa isso? Quais dados são mantidos nele e todas as questões relacionadas a esses dados.
Cache de dados do aplicativo
Portanto, existem três casos de uso de alto nível. O número um é, o Application Data Caching, que é o que eu estava falando, que é você ter dados no banco de dados, você os busca e os armazena em cache. Então, no cache de dados do aplicativo o objetivo é... mas acabei de mencionar que você não quer ir tanto para o banco de dados, você quer reduzir o tráfego do banco de dados para que seu aplicativo seja dimensionado. Mas, os dados agora existem em dois lugares. Ele existe no cache e existe no banco de dados. Então, sempre que os dados existem em dois lugares, qual é a primeira preocupação que vem à mente? Sincronização entre os dois. Então, é consistente? Porque, se os dados não forem consistentes, você ficará limitado a usar o cache para dados somente leitura. Na verdade, a maioria das pessoas quando você pergunta, para que você usa um cache? A reação automática são dados somente leitura. Você sabe, eu não me sinto confortável usando o cache para qualquer dado que vai realmente mudar, você sabe, em tempo real ou em tempo de execução. Mas, se você não pode usar o cache para dados transacionais, que eu uso o termo para dados que mudam com frequência, esses dados provavelmente representam 80% a 90% dos seus dados. Então, isso significa que 80% a 90% das vezes você não pode nem usar o cache e se você não pode nem usar o cache, então ele se torna como um NoSQL database. Nem sempre é a resposta, você sabe. E, você quer que seja a resposta, então você sabe, então um bom cache distribuído tem que lhe dar a confiança de que o que você armazenar em cache será consistente com o banco de dados. Se não for, então esse cache não é o cache certo para você. Então, essa é a primeira coisa, esse é o primeiro caso de uso.
Cache específico do ASP.NET
O segundo caso de uso é se você tiver aplicativos ASP.NET.
- Cache de sessão ASP.NET
Você pode armazenar suas sessões no cache. Você sabe, sessões são algo que quase todos os aplicativos ASP.NET têm. Eles são mantidos no modo In-Proc ou no modo SQL Server. O SQL Server não é o lugar certo para manter sessões por dois motivos, um é claro que, o primeiro motivo que é quanto mais você mantém dados no banco de dados, mais um gargalo de escalabilidade você tem. A segunda é que as sessões são mantidas como blobs e os bancos de dados relacionais não foram realmente projetados para blobs. Eles foram projetados para dados mais estruturados que você pode indexar e pesquisar. Considerando que, em um cache distribuído o valor da chave, o valor é sempre um blob. Portanto, essas sessões se encaixam muito bem com um cache distribuído.
- ASP.NET View State Cache
O segundo tipo de dados ASP.NET é, se você não estiver usando a estrutura MVC, que muitos dos aplicativos ASP.NET existentes ainda não são, então você tem essa coisa chamada Ver estado e, um estado de visualização nada mais é que uma string criptografada que é mantida e enviada do servidor da web para o navegador, apenas para voltar ao servidor da web e pode ficar muito grande. Pode ser 100s de kilobytes facilmente e por isso consome muita largura de banda extra. Leva mais tempo para viajar. Quando você multiplica isso por milhões de solicitações que está processando, seu custo de consumo de largura de banda também aumenta bastante. Portanto, é um caso ideal para armazenar em cache no lado do servidor e enviar apenas uma pequena chave. Então, na próxima vez em que o View State deve ser usado, a chave é enviada de volta e o View State é buscado no cache.
- Cache de saída ASP.NET
O terceiro exemplo de cache específico do ASP.NET é a saída de página. Faz parte do ASP.NET framework é chamado de cache de saída que permite armazenar em cache a saída de uma página se ela não for alterada e você pode usar um cache distribuído para armazená-la em cache em vez de mantê-la em cada servidor da Web separadamente, o que se torna várias cópias que precisam ser sincronizadas. Portanto, esses três casos de uso ou três exemplos são para o caso de uso de cache específico do ASP.NET.
Agora, ao contrário do cache de dados do aplicativo aqui, a natureza do problema é muito diferente. Aqui os dados existem apenas no cache. Quero dizer, todos esses dados não são mais armazenados em nenhum outro lugar. Portanto, não está sendo armazenado no banco de dados. Portanto, você não tem mais esse problema de sincronização entre o banco de dados e o cache. Mas, você tem outro problema agora. Se você tiver um cache na memória, esse será o único armazenamento de seus dados. Qual é a maior preocupação? O que poderia dar errado com isso? Ele desaparece. Sim, pode ir embora. Se algum servidor cair e os servidores caírem, incluindo o Windows. Então, quando um servidor cai, você perde dados e especialmente alguns, quero dizer, para View State e Session State, quero dizer cache de saída, mesmo se você perdê-lo, basta reexecutar a página, mas esses dois. Por exemplo, Estado da Sessão, você acabou de ter esse cliente de companhia aérea que fez todo tipo de pesquisa de voos e ele está prestes a fazer o pedido e o servidor trava e sua sessão é perdida, ele precisa fazer o login real. Você sabe, você pode perder esse cliente. Então, você definitivamente não quer perder. Então, você não quer que esses dados desapareçam. Então, nisso, a sincronização foi o grande problema aqui é a confiabilidade.
Assim, a confiabilidade é tratada por meio da replicação. Qualquer cache que não faça replicação você não poderá armazenar sessões nele. A coisa boa sobre o cache específico do ASP.NET é que não há necessidade de programação. Ele se encaixa completamente dentro do ASP.NET framework. Infelizmente você tem que programar para o cache de dados do aplicativo. No lado do Java, você não precisa ou, na verdade, são mais padrões surgindo. Existe um padrão chamado JCache que, se você programar isso, qualquer um dos caches de terceiros apenas se conectará a ele e você não precisará se prender a nenhum cache. Ainda mais, se você usa um mecanismo de mapeamento OR como o Hibernate ou no caso do .NET NHibernate, você pode conectar um cache. Entity Framework até o núcleo do EF ou até antes do núcleo do EF, ele não permitia que um cache de terceiros se conectasse automaticamente. Embora tivéssemos implementado um provedor ADO .NET para EF6. Isso era mais um cache de nível ADO.NET, então, você estava armazenando em cache as consultas, o que é melhor do que não armazenar em cache, mas não é tão poderoso quanto o cache no nível de entidade, onde você também pode acompanhar as atualizações.
Entity Framework ou EFCore Caching
O novo EF7 ou EF Core tem uma arquitetura muito mais flexível. Ele permite que você conecte um cache de terceiros. Portanto, quando você migrar para o EF Core, poderá conectar um cache distribuído como NCache sem nenhuma programação. Então, você estava apenas fazendo sua programação padrão e plug-ins de cache. Mas fora isso você precisa. Mas, mesmo nesse plugin você não pode usar todos os recursos que falarei. No ASP.NET específico, pelo menos, esta é a vitória mais fácil. Quando você traz um cache, já que não há programação envolvida, você só precisa fazer alguns testes básicos de sanidade e seu aplicativo de repente vê um grande aumento no desempenho e na escalabilidade.
Alguma dúvida, antes de prosseguir? Em termos de aplicação ou em termos de cache? Em termos de cache. Um cache é como um banco de dados. Assim como você faz chamadas para o banco de dados e tem tratamento de exceção. Se algo der errado no cache, o cache lançará uma exceção, você a pegará e terá que tomar as ações apropriadas. No entanto, ao contrário de um banco de dados em que uma atualização pode falhar na integridade dos dados porque você pode ter restrições de verificação ou outras restrições de integridade referencial, nenhuma dessas restrições existe no cache. Um cache aceitará todos os dados que você fornecer. A única vez que uma atualização de cache ou operação falhará é quando algo der errado com o sistema. Sim, algo catastrófico. Portanto, você não precisa se preocupar com o cache não atualizando suas coisas em uma operação normal.
Segurança
Então, isso depende de qual produto de cache você usa. NCache tem todos esses recursos integrados. Você pode ativar segurança, portanto, todo usuário que usa o cache tem que ser autenticado/autorizado. Ele também tem muitas outras seguranças, como criptografia embutida. Portanto, se o aplicativo que você possui é muito sensível, você pode criptografar os dados antes que eles sejam armazenados em cache e tudo isso é feito automaticamente pelo cache sem que você faça nenhum esforço extra. Porque, como eu disse, um dos maiores usuários de NCache é a indústria de serviços financeiros. Porque eles têm muito banco online. Muitos negócios eletrônicos acontecem lá e seus dados são muito sensíveis. Então, isso depende de qual produto você escolher.
Compartilhamento de dados de tempo de execução por meio de eventos
O terceiro caso de uso é compartilhamento de dados de tempo de execução por meio de eventos. Assim como você usa filas de mensagens, MSMQ é um, RabbitMQ é outro. Eles têm muito mais recursos em termos de mensagens para um ambiente distribuído em mais de um local. Se o seu aplicativo está todo em um datacenter e você precisa fazer Pub / Sub tipo de compartilhamento de dados, um cache distribuído é muito mais escalável do que qualquer outra fila de mensagens. Pode não ter tantos recursos quanto eles, mas você pode não precisar de todos esses recursos. Mas, é muito mais rápido e muito mais escalável e isso é verdade para NCache isso também é verdade para outros caches distribuídos que fornecem esse recurso. Porque, novamente, todo esse cluster se torna um barramento de mensagens. Então, você sabe, se você está fazendo muita atividade, os eventos se propagam muito rapidamente porque eles são mais de um servidor para lidar com esses eventos e você pode adicionar mais servidores à medida que a carga aumenta.
Então, muitos desses aplicativos de servidor hoje em dia têm fluxos de trabalho integrados, você sabe. Onde um aplicativo faz algo e, uma vez feito, outros aplicativos fazem outra coisa. Então é aí que entra o Pub/Sub ou o conceito de produtor/consumidor. Há um recurso de notificação de eventos. NCache tem esse recurso chamado consulta contínua que é um recurso muito poderoso, que também está no lado Java, mas nenhum dos outros caches .NET o possui.
Portanto, o compartilhamento de dados em tempo de execução também é algo que você deve considerar fortemente fazer por meio de um cache distribuído, torna sua vida muito mais simples do que incorporar vários outros produtos. Mesmo aqui, a natureza do problema geralmente é a mesma, que é que os dados que você está tentando compartilhar existem apenas no cache. Ele pode existir no banco de dados, mas de uma forma diferente, porque você o construiu, você o produziu, você sabe, você reuniu muitos dados e, nesta forma final ou intermediária, você está compartilhando com alguém senão. Então, se você perder esses dados, terá que refazer tudo. Portanto, embora não seja tão ruim quanto as sessões, ainda tem muitas implicações no desempenho. Então, você não quer perder esses dados. Então, novamente aqui a preocupação é garantir que o cache seja confiável.
Portanto, esses são os três casos de uso de alto nível que um cache distribuído fornece. Como eu disse, um cache distribuído é essencialmente um banco de dados distribuído na memória, um armazenamento de valor-chave.
Demonstração prática
Antes de entrar em mais detalhes sobre como você pode fazer isso, vou mostrar rapidamente como é um cache distribuído. Assim, que você possa ver como será se você fosse usá-lo em sua aplicação. claro que vou usar NCache como o exemplo. NCache é um cache de código aberto. Portanto, você pode usá-lo sem comprá-lo se não tiver dinheiro ou orçamento. Se o seu projeto for mais sensível aos negócios, é claro que compre a Enterprise Edition. Então, configurei algumas VMs no Azure que vou usar. Vou usar um cluster de cache de 2 nós, portanto, tenho 'demo1' e 'demo2' como meus servidores de cache e 'demo-client' é minha caixa de servidor de aplicativos. Então, essa é a sua caixa de servidor ASP.NET. Então, um NCache cliente é o seu servidor de aplicativos realmente.
Estou logado, digamos, cliente de demonstração. Então, a primeira coisa que vou fazer é criar um novo cache. Então, vou usar essa ferramenta chamada NCache Gerente. Então, é uma ferramenta de estilo explorador. Vou apenas dizer para criar um novo cache clusterizado. Dentro NCache todos os caches são nomeados.
Vou escolher uma estratégia de armazenamento ou replicação.
Vou seguir em frente e especificar meu primeiro servidor de cache aqui. Especifique meu segundo.
Vou continuar e direi aqui quanta memória meu servidor deve consumir. No seu caso, vai ser muito mais. Acabei de especificar um show.
Portanto, se essa memória for consumida, você poderá especificar políticas de despejo. Então, digamos, pelo menos a política usada recentemente significa despejar alguns dos itens que são usados menos recentemente.
Então, eu acabei de conseguir isso. Vou seguir em frente e adicionar um nó cliente, que é minha caixa e vou em frente e iniciar o cache.
Então, em qual máquina você está configurando isso? Este é um Azure. Então, esses dois são meus demo1 e demo2. Então, na verdade estou logado nesta caixa e estou usando NCache manager aqui e estou criando um cluster de demo1 e demo2 aqui.
Então, agora que comecei isso, posso ir em frente e posso ver as estatísticas. Então, eu posso ver alguma atividade do contador PerfMon. Também posso lançar esta ferramenta de monitoramento de NCache que me permite ver as coisas e, em seguida, vou executar rapidamente esta ferramenta chamada Stress Test Tool. Ele permite que você teste rapidamente o cache em seu ambiente para ver como ele funcionará.
Então, essa ferramenta é como seu aplicativo. Você pode usá-lo para simular diferentes tipos de carga, diferentes tipos de operações. Por exemplo, estou fazendo cerca de 600 alguns pedidos por segundo aqui e cerca de 700 a 800 cada.
Deixe-me executar mais uma instância da Ferramenta de Teste de Estresse, bem aqui. Então, você verá que essa carga apenas dobrará. Então, à medida que eu continuo adicionando mais e mais instâncias do aplicativo, a carga no cache aumentará até o ponto em que esses dois servidores atingirão o máximo e você adicionará um terceiro.
E você pode fazer tudo isso em tempo de execução sem parar nada. Então, de repente sua infra-estrutura... Basta pensar nisso, se seu banco de dados começou a engasgar, você pode realmente adicionar outro servidor e sair desse problema? Você não pode. Porque, pela natureza disso e não se trata de nenhum banco de dados específico, são todos bancos de dados relacionais. Mas, no caso de um cache basta adicionar outro servidor e agora o cache está funcionando.
Então, é assim que um cache se parece. É tão fácil de usar e configurar como você pode ver. Quero dizer, a única coisa que eu não fiz foi instalar. Que era apenas um instalador do Windows que, você sabe, não demora muito. Então, além disso, para descobrir um cluster de dois nós, levei cerca de cinco minutos.
E, agora que tenho tudo isso configurado, posso especificar esse nome de cache nos aplicativos em execução nesta caixa. Então, se eu tivesse mais caixas de clientes, continuaria adicionando-as aqui.
No seu caso para esses dois você provavelmente tem 8 ou 10 desses. Então, você adicionaria todos eles e, depois de fazer esse cache de demonstração, o cache de demonstração estará disponível lá e você apenas atualizará sua coisa.
Então, agora que sabemos como é um cache, deixe-me passar rapidamente para o próximo tópico. Então, como eu disse, a maneira mais fácil de usar o cache é usá-lo para sessões. Como faço isso? Então, eu tenho o aplicativo ASP.NET. Eu entraria e abriria o web.config e faria duas coisas. Primeiro eu vou e adiciono o assembly.
...
<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=1448e8d1123e9096" />
</assemblies>
</compilation>
...No caso de NCache esse é o assembly que implementa o Provedor de estado de sessão ASP.NET. Então, é assim NCache se conecta ao ASP.NET framework. Qualquer cache de terceiros teria que fazer isso. Então, você apenas adiciona essa linha nos assemblies e, em segundo lugar, basta ir para a tag de sessões e especificar isso específico para o cache distribuído que você escolher.
...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
<providers>
<add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
</providers>
</sessionState>
...No caso de NCache você acabou de copiar isso e há algumas coisas que você precisa ter certeza. Primeiro você precisa ter certeza de que o modo é 'personalizado'. Então, porque personalizado significa armazenamento de terceiros. E, em seguida, 'timeout' certifique-se de que é o que você quer que seja e tudo o mais que você pode manter como padrão e apenas especifique um nome de cache aqui, ali mesmo. Então, deve ser apenas 'demoCache'. Assim que você fizer essa alteração e executar o aplicativo novamente ou, na verdade, assim que você salvar isso, esse processo de trabalho do ASP.NET será reciclado. Vai pegar NCache configuração e de repente você verá que cada sessão será uma contagem. Então, todos aqueles, você sabe, que contam que estávamos vendo em NCache neste PerfMon aqui.
Portanto, seriam 540 sessões armazenadas e, claro, à medida que você adiciona mais sessões, a contagem aumenta.
Portanto, com esse pequeno esforço, você pode imediatamente dar um grande impulso ao seu aplicativo. A mesma coisa acontece com o estado de exibição. Com o cache de saída, há um pouco mais de configuração envolvida, mas o estado de exibição e a sessão você pode fazê-los em questão de minutos, sem nenhum esforço e, de repente, os aplicativos usam um enorme impulso.
Visão geral do cache de dados do aplicativo (API)
Então, agora, vamos passar para o cache de dados do aplicativo, que é o assunto principal desta palestra. Portanto, se você precisar usar o cache para armazenamento em cache de dados do aplicativo, precisará programar para sua API. Isso porque ainda não há API padrão. Então, o que fizemos foi escolher nossa API para estar o mais próximo possível do objeto de cache ASP.NET.
Conexão de cacheCache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");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");NCache existe desde 2005, então, são quase 11 anos e meio agora. Mas, parece muito semelhante ao objeto de cache ASP.NET. Há algumas coisas extras, então digamos que você se conecte ao cache por um nome de cache. Você obtém um identificador de cache. Então esse identificador de cache é o que você usa para fazer cache.Obter. Get contém Add, Insert, Remove e há uma versão Async dele, o que significa que não espere que o cache seja atualizado e, é claro, quando você chamar o Async, poderá especificar um retorno de chamada. Assim, seu retorno de chamada é chamado caso algo dê errado.
Deixe-me mostrar como isso se parece em um visual, como em um aplicativo adequado. Então, se você tivesse um … Este é um aplicativo de console padrão. Você precisaria referenciar o Assembly do seu cache. No caso de NCache, são apenas esses dois conjuntos, Alachisoft.NCache.Tempo de execução, Alachisoft.NCache.Rede. Você especifica os mesmos namespaces aqui e, em seguida, no início do aplicativo que, no caso do ASP.NET, provavelmente estará no global.asax no método Init ou no método de início do aplicativo. Mas, digamos aqui, você se conecta com o cache com base no nome do cache e no nome do cache, como você sabe, é assim, pelo menos em NCache é assim que o cache é reconhecido e você obtém um identificador de cache. Então você cria seus objetos e faz um cache.Adicionar. Você especifica a chave. Esta não é uma boa chave. deveria ter mais exclusividade nele. Mas, digamos, que você especifica a chave e aqui está o seu valor o objeto real.
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");
...Expiração de dados
E, neste caso NCache está fazendo essa coisa chamada expiração absoluta. Então deixe-me, vamos a isso. Então, falamos sobre o cache de dados do aplicativo querendo manter o cache atualizado. Portanto, se você não puder manter o cache atualizado, você o forçará a usá-lo para dados somente leitura. Então, como você mantém o cache atualizado? Há mais de uma maneira. A primeira maneira que praticamente todo cache possui é chamada de expiração absoluta. É aqui que você especifica por quanto tempo deseja manter isso no cache. Então, você diz para o cache eu me sinto confortável apenas por um minuto que eu não acho que esses dados deveriam ficar no cache por mais de um minuto porque, eu acho que se ele fosse mantido no cache por mais de um minuto outra pessoa vai atualizá-lo e o cache ficará obsoleto. Então, você está fazendo um palpite sobre quanto tempo o cache deve ter seus dados. E, claro, todos os dados que você armazena em cache, você deve ter algum tipo de expiração para eles. Praticamente... quero dizer, alguns dados que você pode presumir que nunca expirarão, então, você pode dizer sem expiração. Mas, 99% dos dados ou algo mais de 90% dos dados precisam ter expirações. Portanto, a expiração absoluta é o que mantém o cache atualizado com base em um palpite.
Há outra expiração chamada expiração deslizante. Sua finalidade é totalmente diferente. Embora use a mesma expiração de chamada de nome. A expiração deslizante diz expirar isso se ninguém tocar nesse objeto por tanto tempo, digamos por 10 minutos, por 20 minutos. E, isso é usado para mais dados transitórios. Então, isso é usado para mais dados específicos do ASP.NET, onde você está apenas limpando. Você está dizendo, você sabe, ninguém mais precisa disso. Portanto, se um usuário não usa mais a sessão por 20 minutos, você está dizendo que esse usuário saiu de qualquer maneira, portanto, remova a sessão. Então, isso é uma expiração de limpeza. Em seguida, expiração absoluta, que é um propósito de sincronização. A finalidade da expiração absoluta é a sincronização. E novamente você pode fazer isso, você pode expirar coisas em 10 segundos, 15 segundos, 1 minuto, 5 minutos, 10 minutos. A expiração mais comum provavelmente será de um minuto ou dois minutos.
Mas, há um problema com a expiração. É que você está fazendo um palpite. Você está dizendo que não há problema em armazená-lo em cache por tanto tempo. Mas, não há nenhuma garantia. Em alguns casos pode haver, mas em muitos casos não há garantia. E se houver outro aplicativo que também esteja acessando o mesmo banco de dados e eles atualizarem esses dados. Pode haver alguns scripts em execução. Então, sempre que algo assim acontece, as expirações não são suficientes. E é aí que você precisa que o cache tenha essa capacidade de monitorar as alterações no banco de dados.
Se você puder especificar uma associação entre o que estiver no cache versus qualquer dado correspondente no banco de dados e puder dizer ao cache, por favor, monitore esse conjunto de dados. Se esse conjunto de dados for alterado, vá em frente e remova esse item do cache.
Dependência de banco de dados
Deixe-me mostrar-lhe como isso é feito. Então, há um recurso chamado Dependência SQL no ADO.NET que NCache usa. Que permite NCache para se tornar um cliente do seu banco de dados. E, isso pode ser um banco de dados SQL, isso pode ser Oracle. E então NCache informa ao banco de dados para notificá-lo quando esse conjunto de dados for alterado e esse conjunto de dados for uma instrução SQL que você especificou. Na maioria das vezes, corresponderá a uma ou mais linhas em uma tabela que foram usadas para construir esse objeto que você armazenou em cache. Então, por exemplo, aqui, então, se eu fosse para a dependência do SQL, novamente a mesma coisa. Você tem um identificador de cache e, quando estiver adicionando, isso cache.Adicionar, você está especificando agora, no caso de NCache essa coisa chamada item de cache que é uma espécie de estrutura que contém o valor mais alguns outros metadados. Um dos metadados que contém é chamado de dependência de cache SQL, que é uma NCache classe que mapeia para a dependência de cache ADO.NET SQL na extremidade do servidor. Você passa uma string de conexão e uma instrução SQL.
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, você diz algo como 'Selecione algumas colunas dos Produtos onde o ID do produto é qualquer que seja o valor'. Então, este é um produto para o qual você está mapeando isso. Então, você está dizendo para NCache use esta instrução SQL, use esta cadeia de conexão e monitore esse conjunto de dados ou peça ao servidor SQL para monitorar esse conjunto de dados. Na verdade, este código está sendo executado aqui, certo. Porque, é aí que o NCache é.
Então, isso conversou com o cluster de cache e o servidor de cache, na verdade, faz a chamada ADO.NET e o servidor de cache agora fala com o banco de dados e se torna um cliente. E, o servidor de cache é aquele que recebe a notificação. E, servidor de cache é aquele que realmente remove esse item do cache, se o banco de dados notificar que esses dados foram alterados. Então, ao ter esse recurso integrado, você de repente tem a flexibilidade de manter dados no cache que você nem pode prever quando eles podem mudar, você sabe. Mas, você sabe que isso pode mudar de maneira imprevisível, portanto, você pode usar especificar a dependência do SQL.
Este é um recurso realmente poderoso. Esse é o recurso que permite que um cache permita armazenar dados transacionais em cache. Mesmo quando você não tem controle sobre as atualizações o tempo todo e por causa disso você armazenará em cache todos os tipos de dados, pois esse cache se tornará realmente útil. E isso pode ser feito de várias maneiras, se o banco de dados subjacente suportar a notificação do banco de dados, como é o caso do SQL Server e do Oracle, ele usará a dependência do SQL ou o recurso de dependência do Oracle, caso contrário, o NCache pelo menos tem um mecanismo de pesquisa embutido onde também pode permitir que você o especifique. … Existe um mecanismo onde você especifica uma tabela especial NCache monitora-o e todas as linhas que mudam nele, há um item de cache correspondente que ele remove.
E, uma terceira opção é que você realmente faz chamadas de cache de dentro de um procedimento CLR. Assim, sempre que um dado muda, há um gatilho de banco de dados que chama o procedimento, que chama o cache. E isso pode adicionar dados, atualizar dados ou remover dados do cache. A única coisa com o procedimento CLR é que você não quer fazer... quero dizer, você quer fazer chamadas Async. Porque, o que quer que você tenha chamado, é na verdade que seu banco de dados agora se tornou um cliente do cache como o reverso, certo. Então, está tentando atualizar algo que entrará aqui e poderá ser replicado. Então, tudo isso está acontecendo dentro de uma transação de banco de dados e, como você sabe, as transações de banco de dados expiram rapidamente. Portanto, ao fazer chamadas assíncronas, você pode fazer imediatamente a chamada de cache e, em seguida, retornar o controle.
Portanto, essas são as três maneiras de garantir que um cache seja mantido sincronizado com seu banco de dados relacional. Claro que a mesma lógica se aplica aos não relacionais. E se seus dados estiverem em uma nuvem, em algum lugar? Ou está no mainframe. Você sabe, você tem uma chamada de método da web para ir buscá-la sempre. Então, em caso de NCache pelo menos, você pode ter um recurso de dependência personalizado onde seu código é registrado no cluster de cache, NCache chama a cada, digamos, 15 segundos e diz vá em frente e verifique sua fonte de dados e veja se esses dados foram alterados. Se tiver, dispare um evento e, em seguida, a mesma lógica entra em ação.
Então novamente mantenha o cache atualizado é a coisa mais importante em um cache distribuído. Se você não puder manter o cache atualizado, seu uso será muito limitado.
Read-Through e Write-Through
Há outro recurso chamado Read-Through e Write-Through. Read-Through é um recurso que é novamente um recurso muito útil e muito poderoso. É essencialmente novamente o seu código que é executado no servidor de cache. Cadê? Aqui. Então, digamos, você implementa uma interface de leitura no caso de NCache. Agora read-through/write-through é um conceito que é implementado por NCache. Também é implementado por muitos dos players Java, mas no lado .NET NCache é o único que tem. Portanto, a interface de leitura é essencialmente o seu código. Ele tem um método Init, um método Dispose, então Connect and Disconnect e depois o método Load.
...
// 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;
}
...Ele fornece uma chave e, com base na chave, você deve descobrir para onde ir e obter os dados. E você não apenas retorna os dados, mas também retorna alguns dos metadados, como expirações e outras coisas com eles. Qual o valor da leitura? Então, novamente esse código é algo que você implementa e você registra no... Então, é esse código que roda aqui no servidor de cache. Então, falamos sobre uma dependência personalizada. Portanto, se você tiver uma fonte de dados personalizada, esse é um código que é executado no servidor de cache e a leitura também é algo que é executado no servidor de cache.
Para que serve a leitura? Por que você deve usar uma leitura? Há dois ou três benefícios. Número um, você está consolidando todo o seu código de persistência em um só lugar. Então, se você tem vários aplicativos usando o cache, digamos, você tem vários aplicativos, você sabe, eles não precisam implementar esse código repetidamente. Portanto, ele é mantido dentro do próprio servidor de cache. Esse é o primeiro benefício. O benefício número dois é que quando você expira algo, digamos, você expira algo por causa de expirações ou por causa da sincronização do banco de dados, em vez de remover esse item do cache, por que não apenas recarregá-lo. Porque, se você removê-lo, da próxima vez que o aplicativo o desejar, ele irá recarregá-lo de qualquer maneira. Então, você pode ter a leitura mapeada com isso e dizer onde o cache diz ok se este item expirar ou se ele ficar... se for sincronização automática e eu precisar removê-la, eu chamarei a leitura. Então, por que é bom chamar a leitura? Quero dizer, qual é o problema? Por que não apenas recarregá-lo pelo aplicativo? Bem, se você tem um aplicativo de alto tráfego, é provável que muitos usuários solicitem os mesmos dados. Você tem centenas de milhares desses itens e todos eles continuam expirando em seu próprio tempo. Assim, para cada vez que um item expira, você teria centenas, senão milhares, de solicitações no banco de dados para o mesmo item. E todos irão atualizar o cache novamente. Portanto, muito tráfego desnecessário está indo para o banco de dados. Que, se você tivesse uma leitura, nunca sairia do cache. Ele sempre ficará no cache e em algum momento será atualizado. Assim, o tráfego para o banco de dados nunca ocorre.
O segundo recurso é o write-through, que funciona exatamente como read-through, exceto, é claro, que é para escrita. Então, deixe-me mostrar isso. Por exemplo, aqui novamente, você tem o Init, você tem o Dispose, mas agora você tem um Write e fornece o objeto real e, em seguida, o write pode ser adicionar, atualizar ou remover, certo. Então, todos os três são chamados de gravação. Portanto, com base em qualquer tipo de operação, você atualiza seu banco de dados ou sua fonte de dados.
#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
bool result = false;
OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
Customer value = (Customer)operation.ProviderCacheItem.Value;
if (value.GetType().Equals(typeof(Customer)))
{
result = sqlDatasource.SaveCustomer((Customer)value);
}
if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
return operationResult;
}
public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
throw new Exception("The method or operation is not implemented.");
}Agora, write-through tem outro benefício. Ele tem o mesmo benefício que o read-through em termos de semelhança de código. O segundo benefício que o write-through tem é chamado write-behind. Que é isso, você pode atualizar. Portanto, há um recurso chamado write-behind onde você pode atualizar o cache imediatamente de maneira síncrona, mas as atualizações do banco de dados acontecem de maneira assíncrona. Por que isso é uma coisa boa? Bem, porque esse banco de dados é lento. Então, se você sabe, se você está confiante de que a atualização do banco de dados será feita em tempo hábil... é previsível porque não apenas enfileirar. Ele fica na fila e o cache realmente executa essa operação em segundo plano. Essa fila também é replicada para mais de um servidor. Portanto, se algum servidor cair, a fila não será perdida.
Acho que tudo que você tem que ver no contexto de escalabilidade. O que quer que seja rápido, mesmo que seja um banco de dados na memória, está tudo em um servidor. Então, quanto mais atualizações são enviadas, mais leituras são enviadas para ele, quanto mais carga é colocada no banco de dados, mais lento ele se torna. Assim como um único ponto de falha. É isso. Essa é a verdadeira razão pela qual tudo isso existe e, então, dentro do contexto de tudo isso existente, você obtém todos os benefícios adicionais. Se você tivesse um recurso write-behind, de repente seu aplicativo só precisa atualizar o cache de maneira síncrona. Porque, uma vez atualizado o cache, o cache cuidará da atualização do banco de dados de forma assíncrona. E essa fila tem sua própria otimização. Ele pode fazer atualizações em massa, ele pode replicar. Então, write-behind tem o desempenho, a parte da velocidade que você falou é mais relevante para write-through e write-behind do que para a leitura.
A leitura também é algo que, você sabe, pode ser mais rápido em alguns casos do que o aplicativo acessando, mas no write-behind é definitivamente sempre mais rápido.
Alguma pergunta? Tenho apenas alguns minutos restantes. Vou falar de mais um recurso e depois vou até o final. Então, as pessoas que estão acostumadas a fazer o cache de memória In-Proc autônomo, como o objeto de cache ASP.NET, quando eles mudam para um cache distribuído, muitos de nossos clientes nos ligam e dizem, você sabe, você estava prometendo que o cache realmente melhorar meu desempenho. Meu desempenho realmente caiu. Por que é que? Alguém pode adivinhar? Por que isso realmente diminui, assim que você muda para um cache distribuído versus um cache In-Proc. Latência da rede. A latência da rede é uma delas. Um problema maior é a serialização e desserialização, que é um custo enorme.
Cache do cliente ou cache próximo
Então, o que parte do cache distribuído está fazendo, incluindo NCache, eles implementam essa coisa chamada cache do cliente, alguns chamam de cache próximo. É um subconjunto desse cache, que é mantido no servidor de aplicativos. Pode até ser In-Proc ou pode ser OutProc. Mas, muitas vezes é In-Proc. Portanto, ele oferece o mesmo benefício de um cache In-Proc autônomo, exceto que é sincronizado com isso.
E, este é um subconjunto menor, então digamos, isso pode ser 16 giga cada servidor, isso pode ser apenas um giga. E, é uma janela em movimento, certo? Portanto, o que você está armazenando em cache é mantido e, à medida que você avança, os itens mais antigos expiram ou são despejados e os novos dados são armazenados em cache.
Portanto, um cache de cliente oferece o desempenho real. Ele mantém os dados em um formulário de objeto dentro do processo de aplicação. Então, se você está buscando centenas de vezes ou dezenas de vezes, na primeira vez, é claro, você precisa buscá-lo no cache distribuído. Talvez, a primeira vez que você vai buscá-lo no banco de dados. Ele vai para o cache distribuído e depois para o cache do cliente, mas, uma vez feito, todas as leituras adicionais estão sendo feitas em seu próprio heap, o que é super rápido. Então, este é um recurso que é realmente poderoso. Você definitivamente quer tirar proveito disso.
Então, há algumas coisas que você precisa ter certeza. Um cache distribuído, assim como um banco de dados é executado em seu datacenter em seu ambiente de produção. Portanto, ele deve atender a alguns dos requisitos de arquitetura. Deve ter alta disponibilidade. Deve fornecer confiabilidade e escalabilidade de dados. Então, ele deve fazer replicação inteligente.
Não vou entrar em detalhes disso. Você pode olhar para ele. Você pode fazer a pesquisa online. Por exemplo, se você tiver vários datacenters, espera que seu banco de dados seja replicado, por que não o cache? Você sabe. Por que o cache também não deveria estar disponível de forma sincronizada em vários… Então, sim, um bom cache deveria estar.
Opções de cache distribuído do .NET
Se você estiver fazendo aplicativos .NET, neste momento, você sabe, existem basicamente duas opções que você tem para armazenar em cache. Um é Redis que a Microsoft colocou no Azure. O outro é NCache. No lado do Java, como eu disse, há vários jogadores que são muito bons.
Então, eu só quero fazer uma comparação de alto nível.
NCache é o cache .NET mais antigo. Está no mercado desde 2005. É .NET nativo. Também é de código aberto, assim como Redis. Também está disponível no Azure ou na Amazon. Redis … Então, existem duas versões de Redis, desenvolvido por Redis Labs, que só roda em Linux. Na verdade, a Microsoft usa essa versão no Azure. E, a versão que a Microsoft portou para o Windows, eles nem a usam. Na verdade, ouvimos muitas reclamações de clientes. Não é muito estável. Mas, fora do Azure, a única versão que você tem para Windows é a que a Microsoft portou, o MS Open Tech. Mas, fora isso, se você for para Redis eles só vão te dar a versão Linux. No próprio Azure existem duas diferenças entre NCache e Azure que é isso NCache na verdade, fornece um servidor de cache como uma VM. Então, você pode executar todo esse código do lado do servidor, monitorar as coisas. Redis fornece cache como um serviço. Então, o cache é uma caixa preta. Você só tem uma API muito simples que você chama. E a limitação disso é que você não obtém todos os recursos sobre os quais acabamos de falar. Como você faz a sincronização do banco de dados? Leitura através de escrita. Na verdade, nem entrei na pesquisa SQL, porque não tínhamos tempo. Então, essas são as duas maneiras que você pode fazer isso. Se você quiser saber mais sobre isso você pode vir ao nosso site e temos uma documento de comparação detalhado. Então, se eu fosse entrar Redis vs NCache aqui, você pode ver um documento completo. Você também pode baixá-lo. É uma comparação de recurso por recurso com base na documentação deles e na nossa e então você pode ver qual atende a sua necessidade. Alguma pergunta? Esse é o fim da minha conversa. Obrigada.
Existe alguma dependência .NET Core Framework ou você pode usá-lo com .NET 4.0? Boa pergunta. Então, NCache servidor suporta .NET frameworks. É 4.0 ou posterior. o NCache Cliente por padrão é .NET framework é claro. Estamos prestes a lançar o .NET…. Então, nós apoiamos ASP.NET Core. Então o .NET Core que pode rodar no Linux, ainda não suportamos porque tem limitações. Mas o .NET Core que roda em ASP.NET framework, abaixo apenas no Windows, especialmente ASP.NET Core NCache vai apoiá-lo. Muito obrigado rapazes.