Campo de código de Orlando
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
A conversa de hoje não é sobre NCache, trata-se de cache distribuído. vou me referir a NCache como exemplo, mas os conceitos são gerais, então eles se aplicam a todos os caches.
O que é Escalabilidade
Ok! Vamos tirar algumas definições do caminho primeiro. A primeira definição é Escalabilidade. A escalabilidade não é o desempenho do aplicativo. Se você tiver cinco usuários e seu aplicativo tiver um desempenho super rápido, seu aplicativo não será escalável até que possa ter o mesmo bom desempenho com cinco mil usuários, cinquenta mil ou quinhentos mil. Portanto, escalabilidade é sobre alto desempenho sob cargas de pico. As pessoas às vezes confundem desempenho com escalabilidade. Seu aplicativo pode não ter um bom desempenho com cinco usuários, caso em que o cache não o ajudaria, você tem outros problemas para resolver.
Escalabilidade Linear
Escalabilidade Linear é, se sua aplicação for arquitetada de tal forma que você possa adicionar mais servidores e adicionando mais servidores você pode aumentar a capacidade de transação. Novamente, a escalabilidade que estamos definindo em termos de capacidade de transação em termos de quantos usuários quantas transações por segundo seu aplicativo pode manipular. Portanto, se seu aplicativo pode lidar com mais transações linearmente à medida que você adiciona mais servidores, então seu escalável linear e nosso objetivo é ser uma escala linear para ter uma escalabilidade linear em nosso aplicativo.
Escalabilidade Não Linear
E, definitivamente, não queremos escalabilidade não linear, que é que seu aplicativo seja arquitetado de tal forma que, depois de um certo ponto, não importa se você adicionar mais servidores, seu aplicativo não aumentará, na verdade, provavelmente derrubar. Isso significa que existem alguns gargalos em algum lugar que não foram resolvidos.
Quais aplicativos precisam de escalabilidade?
Então, por que queremos escalabilidade e quais aplicativos precisam de escalabilidade?
Normalmente, esses são aplicativos que são aplicativos do lado do servidor. Estes são ASP.NET agora ASP.NET core, Web Services, back-ends IOT, processamento de big data. Embora o processamento de big data não seja comum no lado .NET, é mais um fenômeno Java, mas deve ser capaz de fazê-lo com .NET também, mas os aplicativos de processamento de big data também precisam de escalabilidade e quaisquer outros aplicativos de servidor. Por exemplo, você pode ser um banco e ter milhões de clientes e eles ligarem e mudarem de endereço ou talvez emitirem ou pedirem um novo cartão ou talvez eles transfiram fundos e você precise processar todas essas solicitações em lote no à noite e há alguns requisitos de conformidade que você precisa fazer antes do próximo dia útil. Portanto, à medida que você obtém mais e mais deles, até mesmo seus outros aplicativos de processamento em lote precisam ser escaláveis. Então, não são apenas esses aplicativos. Quaisquer outros aplicativos que precisem apenas processar muitas transações em um tempo compactado e esse tempo compactado nesses casos são transações por segundo e esse tempo compactado nesse caso pode estar dentro desse requisito de conformidade. Então, se você tem algum desses aplicativos que são de alto tráfego ou altas transações, então você veio ao assunto certo.
Problema de Escalabilidade
Então, onde está o problema de escalabilidade? Por que estamos tendo essa conversa? Definitivamente, não é na camada de aplicativo que sua camada de aplicativo é dimensionada muito bem, você tem um balanceador de carga e pode adicionar mais e mais servidores. Tudo parece muito bom. O problema realmente está em seu banco de dados, seu armazenamento de dados. E com isso quero dizer bancos de dados relacionais ou dados legados de mainframe. E você não pode dimensioná-los da mesma maneira que pode dimensionar a camada do aplicativo. A razão é porque os dados neste não são distribuídos. A natureza do banco de dados é que ele tem que ser tudo junto. E, o mesmo acontece com mainframe. Assim, o banco de dados pode ser muito rápido. Pode estar fazendo cache de memória no servidor, mas não está dimensionando e NoSQL databases.
Embora uma das razões pelas quais as pessoas usam NoSQL é para escalabilidade de transações, o outro é para escalabilidade de dados em termos, digamos, você tem terabytes e terabytes de dados que NoSQL é muito mais adequado para isso. E, esse terceiro motivo, as pessoas o usam porque os documentos JSON oferecem essa flexibilidade de esquema. Mas, NoSQL databases nem sempre são capazes de ajudá-lo e o motivo é porque eles exigem que você mova os dados de bancos de dados relacionais para um NoSQL database. E se você não puder fazer isso por vários motivos, tanto técnicos quanto comerciais. Alguns dos dados precisam permanecer em seus bancos de dados relacionais e em seus dados de mainframe legados. Embora, NoSQL databases são ótimos e temos um NoSQL database que lançamos no ano passado, chamado NosDB, como mencionei, mas eles não resolverão seu problema, a menos que você possa inserir dados neles. Então, se você tem que trabalhar com bancos de dados relacionais, você tem que resolver o problema de escalabilidade que eles representam e é aí que um cache distribuído realmente entra.
Implantação de cache distribuído
Um cache distribuído essencialmente é um armazenamento distribuído na memória.
Logicamente falando, é apenas entre a camada de aplicativo e a camada de dados. Fisicamente, pode ser um monte de VMs separadas ou pode estar na mesma caixa que o aplicativo ou algumas delas podem estar aqui, algumas podem estar aqui e essas são as coisas sobre as quais falaremos. Mas, logicamente, está entre a camada do aplicativo e a camada do banco de dados. E o argumento fundamental é que, se você armazenar dados em cache, não acessará o banco de dados com tanta frequência. Porque você não vai no banco de dados ele não pega toda aquela carga, então não se torna um gargalo. Se 80% do tempo você pode ir para a camada de cache e a camada de cache não tem o gargalo que um banco de dados tem porque também é distribuído como um NoSQL database uma camada de cache também está distribuindo. É uma chave/valor. Na verdade, outra palavra para um cache distribuído é um in-memory NoSQL key value store porque tudo que você coloca no cache de distribuição tem uma chave e tem um valor que é seu objeto. Então, fazendo isso 80% do tempo, você está indo aqui 20% do tempo, você está indo para o banco de dados. Esses 20% são principalmente atualizações.
Há algumas leituras, é claro, e essas atualizações também estão sendo executadas mais rapidamente porque não há concorrência com transações de leitura e isso não é mais um gargalo. Por quê? Porque um cache distribuído formará um cluster de dois ou mais servidores. Não são caixas caras, não são caixas do tipo servidor de banco de dados. Essas são configurações típicas de servidor da Web, como uma caixa de quatro ou oito núcleos, apenas muita memória. Lotes significa 16 a 32 giga é o que recomendamos aos nossos clientes. Alguns de nossos clientes vão mais de 32, mas quase nunca recomendamos ir mais de 64. É melhor adicionar outra caixa do que ter mais aqui. Porque, se você adicionar mais memória, o poder de processamento precisará ser atualizado. Por quê? Porque um aplicativo .NET tem essa coisa chamada coleta de lixo e quanto mais memória você tem para coletar, mais coletor de lixo ou o GC tem que trabalhar e a CPU se torna um gargalo nesse caso e seu aplicativo começa a ter problemas. Portanto, o ponto ideal é de 16 a 32 GB de memória nessas VMs ou caixa física e a maioria de nossos clientes usa VMs aqui. E, cerca de 8 núcleos como configuração de hardware e geralmente duas placas de rede, uma placa de rede é para o clustering e outra para os clientes conversarem com ela. A palavra cliente significa seu servidor de aplicativos, portanto, não são seus clientes. É o seu servidor de aplicativos que é o cliente de cache.
Portanto, um mínimo de dois servidores de cache e, em seguida, uma proporção de quatro para um ou cinco para um entre a camada de aplicativo e a camada de armazenamento em cache. E, essa proporção é baseada principalmente no que vimos ao longo dos anos e estamos neste espaço há mais de dez anos, que se você está adicionando mais servidores aqui para adicionar mais atividade do que acima de quatro para um ou a proporção de cinco para um lhe dará uma capacidade muito boa. E, claro, você adiciona mais servidores por um dos três motivos. Ou você precisa de mais armazenamento porque precisa de memória, como acabamos de falar, ou precisa de mais capacidade de transação porque tinha dois servidores para começar e continuou adicionando caixas aqui até o descarte atingir o limite. Em um banco de dados relacional, se isso acontecer, você ficará preso. Você está encharcado. Nesse caso, tudo o que você faz é adicionar uma terceira caixa até que a capacidade da terceira caixa atinja o máximo e então você adiciona uma quarta e assim por diante. Então, você pode ter quantas caixas aqui você quiser. Nós temos clientes, que em média têm cerca de cinco a dez caixas aqui e alguns de nossos clientes têm 40 a 50 caixas aqui na camada de aplicação e então eles têm de acordo. Portanto, para uma caixa de dez ou para uma camada de aplicativo de dez servidores, você teria cerca de três servidores na camada de armazenamento em cache. Então, é assim que você faz o seu planejamento.
Portanto, o objetivo da palestra até agora é convencê-lo de que, ao ter uma camada de cache, você não terá mais um gargalo de escalabilidade. Portanto, seja qual for o produto, seja qual for a solução de armazenamento em cache que você usar, você deve incorporar uma camada de armazenamento em cache em seu aplicativo. Portanto, você deve arquitetar seu aplicativo para ter um cache em sua imagem e dessa forma você nunca terá gargalos.
Casos de uso de cache distribuído
Então, agora que estamos convencidos de que você deve usar o cache como desenvolvedor .NET, a próxima pergunta que vem à mente é onde você deve usá-lo? Como você deve usá-lo?
E, o primeiro caso de uso é o cache de dados de aplicativos que eu tenho falado até agora, que é você ter dados de aplicativos em um banco de dados e armazená-los aqui, então você não precisa ir ao banco de dados, esta mesma coisa .
Cache de dados do aplicativo
A única coisa a ter em mente sobre este caso de uso é que os dados agora existem em dois lugares, um é o mestre que é o banco de dados e um é o cache que não é o outro lugar. Então, se seus dados existem em dois lugares, o que vai dar errado? Se você tiver duas cópias dele, a maior preocupação é se o cache será atualizado, se o cache terá a mesma versão de dados que o banco de dados, porque se o cache não tiver a mesma versão de dados, você será forçado a armazenar em cache os dados somente leitura. E os dados somente leitura representam cerca de 10 a 15% do total de dados. Então, você não está realmente se beneficiando bem. Você está se beneficiando, mas não está se beneficiando na medida em que deveria para realmente tornar seu aplicativo escalável.
Então, na verdade é tanto que se você perguntar a uma pessoa comum para que serve um cache. Eles diriam que vou colocar meus dados somente leitura nele. Todo mundo tem medo de armazenar dados transacionais em cache. Seus clientes, suas contas ou dados de atividades que mudam a cada 30 segundos, a cada minuto, a cada cinco minutos ou de forma imprevisível. Então, as pessoas têm medo de armazenar isso em cache por esse motivo, porque existem duas cópias dele e se o cache não souber que você o alterou no banco de dados. Então, vamos manter isso em mente enquanto continuamos.
Cache específico do ASP.NET
O segundo caso de uso é, se você tiver um aplicativo ASP.NET, o mais conhecido é o estado da sessão. E isso também é qualquer coisa neste, o primeiro exemplo é o estado da sessão. As sessões são algo que, por padrão, você tem duas opções de armazenamento. Um é o InProc, o outro é o SQL, que a Microsoft fornece. Em um local, há também um servidor de estado, mas todas as três opções têm problemas de escalabilidade. O servidor SQL tem problemas de desempenho. A mesma razão pela qual não teremos cache para começar. Quando você armazena sessões no SQL, elas são armazenadas como blobs. A relação é SQL como todos os bancos de dados relacionais não foram projetados para armazenamento de blobs, é para dados estruturados. Portanto, não executa. Há muitos problemas. A maioria dos nossos clientes quando vão para NCache, o primeiro caso de uso é o estado da sessão. Isso porque isso obtém seu benefício imediato. E, a coisa realmente legal sobre o estado da sessão é que não há programação porque há uma estrutura que a Microsoft fornece que permite um cache de terceiros como NCache para conectar e tudo aqui é armazenado no cache.
O outro aspecto do ASP.NET é se você não tiver o framework MVC, se você estiver no framework pré MVC que muitos aplicativos ASP.NET ainda são, então existe uma coisa chamada estado de visualização. E, para aqueles que não sabem o que é o estado de visualização, é uma string criptografada que é enviada pelo seu servidor web ao navegador apenas para ser trazida de volta em um post back. Então, podem ser centenas de kilobytes de força criptografada que vão e voltam. E, quando você multiplica isso por milhões de transações que seu aplicativo vai processar, é muita largura de banda no mínimo. E a largura de banda não é gratuita por ser muito cara.
E o segundo é claro, mas quando você tem que enviar uma carga tão pesada para o seu desempenho, seu tempo de resposta é mais lento. Então, seria muito melhor se você pudesse apenas armazenar em cache o estado de exibição no servidor e enviar uma chave pequena, então quando o post back acontecer, a chave volta e o estado de exibição é obtido do cache e apresentado para a página. Então, esse é o segundo caso de uso. Novamente, da mesma forma, não há programação envolvida, basta conectar um cache de terceiros como NCache.
O terceiro caso de uso é o Cache de saída ASP.NET. Esse cache é a saída da página. Se a saída da página não for alterada, a Microsoft já possui uma estrutura que a armazena em cache em um InProc local autônomo. É melhor colocar um terceiro cache distribuído no lugar dele, para que em um web farm na primeira vez que uma saída de página seja armazenada em cache, ela esteja disponível para todo o web farm em vez de cada servidor web armazenar em cache sua própria cópia.
Portanto, esses são os três casos de uso para aplicativos ASP.NET, além do cache de dados do aplicativo.
Agora a natureza do problema aqui é completamente diferente aqui. Neste você tinha duas cópias dos dados. Aqui, o cache é o repositório principal. Portanto, você não está mais armazenando sessões no banco de dados. Você não está mais armazenando o estado de visualização em nenhum outro lugar. Portanto, o cache é o armazenamento principal e é um armazenamento na memória. Então, quando uma loja na memória é uma loja principal, o que pode dar errado? a memória é volátil! Sim. Então, não há persistência. Portanto, um bom cache distribuído deve replicar dados em vários servidores para fornecer confiabilidade de dados, para que você não perca essa sessão. Porque você pode ser uma companhia aérea e fez essa promoção especial de fim de semana para o Havaí e tem duas ou três vezes mais tráfego no seu site e são pessoas que fizeram todo tipo de pesquisa e estão prestes a aperte o botão enviar e eles perdem a sessão. Você pode perder esse cliente com milhares de dólares em vendas para cada cliente. Então, você definitivamente não quer perder a sessão. Portanto, não coloque sessões em um cache, a menos que faça replicação.
Compartilhamento de dados em tempo de execução
O terceiro caso de uso é um compartilhamento de dados em tempo de execução. Isso é algo que muita gente não sabia há muito tempo. As pessoas usam filas de mensagens para compartilhar os eventos em vários aplicativos. Mas, um cache distribuído oferece um mecanismo de evento focado em dados muito simples e poderoso, onde, pense nisso agora como um barramento de serviço ou como um barramento de mensagens, então esses são seus aplicativos que podem conversar entre si através disso. Então, em vez de usar MSMQ ou RabbitMQ, que têm seus próprios benefícios, um cache não está aqui para substituí-los. Mas, se sua necessidade é mais em torno de dados ou se sua necessidade de mensagens é mais em torno de dados e dentro do mesmo data center, um cache distribuído oferece uma interface mais simples, mas mais importante, é mais escalável. Então, se você tem um aplicativo de transação mais alto e novamente, toda essa conversa é sobre escalabilidade.
Portanto, embora você possa fazer todas essas coisas com essas filas de mensagens regulares. Quando você entra em um ambiente de transação muito alto, eles não são distribuídos da mesma forma que um cache distribuído. Portanto, um cache distribuído permitirá que você faça tudo isso. Digamos que o tipo Pub/Sub de um compartilhamento de dados, há notificações de eventos, há um recurso de consulta contínua que NCache tem o que também os caches Java têm, que Redis não, com o qual você pode simplesmente compartilhar dados entre aplicativos de uma forma muito perfeita. E, aqui também o problema é semelhante ao da aplicação do cache específico do ASP.NET, porque embora esses dados provavelmente existam em um banco de dados, mas não na forma que você está compartilhando.
Então, você provavelmente o transformou em algum formulário antes de tentar compartilhá-lo para que o formulário transformado seja mantido no cache. Portanto, você não deseja perder esses dados, portanto, um cache deve replicar os dados. Na verdade, mesmo para cache de dados de aplicativos, embora tecnicamente, você poderia, se perder alguns dados porque um servidor de cache caiu e você não replicou. Você pode recarregar tecnicamente esses dados do banco de dados. Não há problema, exceto que há um impacto no desempenho porque, digamos, se foram 16 giga de dados que você perdeu, agora você tem que passar por 16 giga de acertos de banco de dados que você não quer fazer. Portanto, a maioria de nossos clientes, mesmo para armazenamento em cache de dados de aplicativos, opta por replicar porque a memória é muito barata. Eles não querem nem levar esse golpe no desempenho. Com esses dois, é claro, você tem que ter, mas nesse eles é meio que bom ter.
Demonstração prática
Ok, antes de avançarmos sobre como fazer isso, quero mostrar primeiro como é um cache. vou usar NCache como o exemplo aqui.
Configurando um ambiente
Então, eu tenho no azure três VMs demo1, demo2 e demo-client. demo1 e 2 serão minhas VMs de servidor de cache e demo-client é minha VM de servidor de aplicativos. No seu caso, digamos que você terá duas VMs de cache e, em seguida, quatro a cinco, quatro a uma ou cinco a uma proporção das VMs cliente.
Então, estou logado no cliente de demonstração e vou usar esta ferramenta que NCache tem chamado NCache Gerente. Então, eu comecei aqui. Eu vou vir aqui e dizer para criar um novo cache clusterizado.
Criar um cache clusterizado
Todos os caches em NCache são nomeados, então vou chamá-lo de democache, não vou entrar em detalhes do que cada um deles significa, falarei sobre isso daqui a pouco, mas escolherei um topologia de réplica particionada. No caso de NCache, uma topologia significa como os dados são armazenados e replicados? Uma topologia de réplica particionada é algo que... se eu voltasse se viesse aqui, pense nisso como um cluster de cache de dois nós que colocaria para criar.
Se for uma réplica particionada, cada servidor terá uma partição. Então, haverá um total de duas partições. No caso de NCache, todo o cache tem cerca de mil buckets, então cerca de metade deles irá para a partição um, metade deles irá para a partição dois.
O backup de cada partição é feito em um servidor diferente que é chamado de réplica. A réplica em caso de NCache é passivo, o que significa que nenhum cliente fala com as réplicas, apenas a partição fala com as réplicas. E a réplica se torna ativa somente quando sua partição primária ou quando a partição fica inativa.
O que significa, digamos, que se este servidor fosse desativado, digamos, se tivéssemos um cluster de três nós e uma partição, digamos que o servidor três caiu, a partição três está inativa agora. Portanto, a réplica três se tornará automaticamente a partição três, para que você não perca nenhum dado. Portanto, as réplicas particionadas oferecem essas estratégias de armazenamento e replicação. Essencialmente, informa que os dados precisam ser replicados. Há uma replicação síncrona e assíncrona também. Então, de qualquer forma, vou voltar a isso, mas eu queria apenas mostrar o que isso significa. Então, vou escolher uma replicação assíncrona entre a partição e as réplicas. Então vou especificar meu servidor de cache, então o primeiro é demo1, o segundo é demo2. Agora, tudo o que estou dizendo em caso de NCache, você pode criar um script completo, para que possa ser automatizado. Vou deixar todo o padrão. Essa é a porta TCP na qual os clusters de cache se formaram. Vou especificar quanta memória quero que o cache use neste servidor e o cache não usará mais do que essa memória. Então, o que eu especificar aqui é isso vezes dois porque. Há uma partição e há uma réplica.
Então, este é o tamanho de uma partição. Então, no seu caso vai ser muito mais do que isso claro porque, se você tem 16 gigas em um servidor de cache você deve deixar cerca de 2 a 2.5 gigas para sistema operacional e outros processos e alocar o resto. Então, digamos, de 16 giga você tem 13 giga e meia sobrando, mas 13 e meio dividido por 2 seria um tamanho de partição e então NCache garantirá que ele não use mais do que essa memória. Assim, quando essa quantidade de memória é consumida, o cache é considerado cheio em caso de NCache. E depois NCache tem uma das duas opções. Um, você pode dizer NCache rejeitará quaisquer novas adições de dados até que alguns dos dados expirem automaticamente ou você possa fazer o que chama de despejo. Então, NCache oferece três algoritmos de despejo LRU, LFU e FIFO prioritário. Então, você pode dizer neste caso, despeje 5% do cache.
Agora quero falar um pouco sobre isso no contexto de, digamos que você está armazenando em cada um dos caso de uso aqui. Se você estiver fazendo o cache de dados do aplicativo, o despejo está perfeitamente correto. Nao há problema. Você acabou de usar a memória que tinha e despejou alguns dos menos usados recentemente e, em seguida, abre espaço para novos dados. Então, torna-se como uma janela em movimento, certo? Assim, à medida que você usa mais e mais dados, o mais antigo é removido e o novo. Então, esse é o mais usado. Mas, e se for uma sessão? Se o cache estiver sendo usado para armazenar sessões, você não deseja remoções. Por que você não quer o despejo? Porque a sessão ainda pode estar ativa. Pode não ter passado por esses 20 minutos ou qualquer que seja o seu tempo limite. Se for esse o caso e você ainda despejar a sessão, você está forçando o mesmo problema sobre o qual acabamos de falar, que é que um usuário não fez logout, mas você está chutando. Então, o que você precisa fazer é fazer seu planejamento de capacidade. No caso de NCache, você pode fazer isso com muita facilidade, pode ver quanta memória uma sessão média está consumindo e, em seguida, fazer seu planejamento de capacidade. Extrapolar quanta memória será usada. Faça a capacidade de que esse outro armazenamento de sessão nunca seja despejado. O armazenamento de dados do aplicativo ou o cache de dados do aplicativo podem ser despejados, sem problemas. Mas, o cache de sessão não deve ser despejado. Ele só deve expirar quando o usuário não usar mais a sessão.
Então, vou apenas dizer terminar e tenho um cluster de cache de dois nós. Eu virei aqui e adicionarei um nó cliente. No meu caso eu só tenho um nó cliente como eu disse. Acho que provavelmente não tenho o cache, então começamos. Eu preciso desse serviço para que o NCache gerente pode falar com isso e fazer a configuração. Ok! Agora que fiz isso, vou vir aqui e dizer para iniciar o cache. Então agora, iniciando o cache, NCache está construindo um cluster entre essas duas caixas, para aquele TCP.
Simule o estresse e monitore as estatísticas de cache
Então, você não entra nos detalhes de quais caixas têm quais dados e se o cluster. Você só sabe que existe um democache. Sempre que você se conectar a esse cache, seu aplicativo se conectará automaticamente a todos os servidores no caso de réplicas particionadas. Então, NCache cuida de todos os detalhes e eu vou vir aqui e dizer ver estatísticas e estes são alguns contadores PerfMon para que você possa ver o que NCache vai fazer, mas uma vez que você começar a usá-lo. Eu também vou iniciar esta ferramenta chamada NCache monitor. E é como uma ferramenta de estilo de painel. E, em caso de NCache, você tem essa opção de usar uma ferramenta de teste de estresse que permite simular muito rapidamente o uso do seu aplicativo sem nenhuma programação.
Então, por exemplo, eu vou dizer democache de ferramenta de teste de estresse, então ele vai fazer um get one put e coisas assim. E de repente, agora você verá que essa ferramenta está conversando com os dois servidores de cache e está fazendo cerca de 700 solicitações por segundo em cada caixa, cerca de 7 a 800 até mil. Digamos que eu queira aumentar a carga. Então, quero lançar mais uma ferramenta de teste de estresse.
Isso é como você faria com seu aplicativo. Quero dizer, quando você quiser testá-lo, você usará seu aplicativo, executará seu aplicativo com alguma ferramenta de teste de estresse e continuará adicionando mais e mais estresse e verá se todo o sistema funciona. Então, agora você está apenas testando o componente de cache dele. A maioria de nossos clientes o que eles fazem quando avaliam NCache, eles fazem esse benchmarking. Então, uma vez que eles configuraram tudo em seu ambiente, mesmo que tenhamos publicado nossos benchmarks, eles não o fazem. Quero dizer, eles verificam tudo em seu próprio ambiente. Então, à medida que você adiciona mais e mais disso, verá que essa carga acabou de dobrar.
Deixe-me ir mais uma ferramenta de teste de estresse. Você vai ver que continua subindo. Ali mesmo, veja! Assim, posso continuar adicionando mais e mais ferramentas de teste de estresse, até que eu possa maximizar a CPU do meu cliente. Então, cheguei a cerca de 50% no meu servidor de aplicativos. Então, posso definitivamente adicionar mais ferramentas de testes de estresse. Depois de maximizar esse cliente, adicionarei mais um cliente. Então, é assim que eu posso. Então, mesmo agora, por exemplo, estamos fazendo cerca de 5,000 solicitações por segundo com apenas três ferramentas de teste de estresse. Então, com isso e depois você também pode monitorar, por exemplo, aqui todas essas coisas. Então, com isso, você pode realmente ver como é um cache. E agora, vamos falar mais sobre a perspectiva do desenvolvedor.
Cache específico do ASP.NET
Então, agora que você sabe como é um cache, vamos ver como usar esse cache em seu aplicativo. Então, para ASP.NET, como eu disse, a primeira coisa que você deve fazer é usar o cache para sessões. Por quê? Porque é o mais fácil. Não há programação, não há esforço, você pode fazer isso. Acabei de mostrar o quão rápido você pode configurar um cache com interesse de NCache, digamos que se eu viesse aqui e entrasse em algum código de exemplo já deveria tê-lo aberto, mas não o faço. Então, aqui está um aplicativo ASP.NET para você usar NCache com ASP.NET para sessões. Você tem que ir e modificar o web.config. Então, eu tenho o web.config. A primeira coisa que você precisa fazer é adicionar essa linha de montagem na montagem. NCache, este provedor de armazenamento de sessão é NCache assembly que implementou a interface do provedor de armazenamento de sessão ASP.NET. Então, é isso que permite NCache para conectar. Então, você pode simplesmente copiar a linha aqui e então você chega à tag de estado da sessão, que está bem aqui. No caso de NCache, basta copiar essa tag. Certifique-se de que este modo é personalizado porque é isso que permite que o cache de terceiros se conecte. O tempo limite é o que você deseja e a única coisa que você precisa em caso de NCache é certificar-se de que o nome do cache seja especificado.
Assim, uma vez instalado NCache então nos servidores de cache você instala a parte do servidor, no servidor de aplicativos você instala a parte do cliente do NCache, você cria o cache como acabamos de fazer e atualiza isso e pronto. Esse é todo o esforço que você precisa para começar a usar NCache e então cada sessão é um objeto no cache. Ao fazer isso nesse contador PerfMon, você verá quantas sessões está vendo. O que acontece normalmente, nossos clientes criam três caches. Então, acabamos de fazer um cache aqui, certo? Assim, nossos clientes farão três caches. Um dos caches é para sessões. Portanto, eles têm um cache separado para sessões. Um dos caches e dois caches são para dados do aplicativo. Um deles é o que eles chamam de dados de referência. O outro são os dados transacionais. Dados transacionais são algo que muda com muita frequência. E, a razão pela qual eles fazem isso é por causa de alguns dos outros recursos que vou abordar. Mas, nas mesmas VMs, você pode ter mais de um cache criado. Então, isso é tudo que você precisa fazer para o armazenamento do estado da sessão, é muito fácil, sem necessidade de programação e então você está pronto para ir.
Cache de dados do aplicativo
Mas, se você quiser fazer cache de dados de aplicativos, infelizmente no espaço .NET o núcleo EF agora finalmente fornece uma arquitetura onde você pode conectar um cache de terceiros.
NCache também o suporta. Mas, até o EF6 incluindo o EF6, a arquitetura realmente não suportava a conexão de um cache de terceiros. O NHibernate por muito tempo apoiou essa arquitetura. Assim, para o NHibernate NCache pode se conectar sem qualquer programação. Portanto, mesmo o cache de dados do aplicativo com recursos mínimos, você pode simplesmente fazer sem fazer nenhuma chamada de API. Mas, na maioria das vezes, você tem que estar mentalmente preparado para o cache de dados do aplicativo, você terá que fazer programação. Mas é uma API muito simples. Essa API se parece muito com um objeto de cache ASP.NET. Você se conecta ao cache com um nome de cache.
Deixe-me mostrar rapidamente como é isso. Deixe-me abrir… Encontrei alguns problemas de VM do Azure. Eu começo essas outras coisas outras neste tudo aberto. Então, digamos que eu tenha esse aplicativo de console realmente básico. A primeira coisa que você precisa fazer é vincular dois dos NCache montagens, uma é NCache.Runtime, o outro é NCache.Rede. NCache.Web é a API real que você está chamando. Então você vincula esses dois ou usa esses dois namespaces novamente NCache.Runtime e depois .Web.Caching. No início do seu aplicativo, você se conecta ao cache com base em um nome e obtém um identificador de cache, assim como no banco de dados. É claro que, em um aplicativo ASP.NET, você provavelmente fará isso no global.ASAX no início do aplicativo ou no método InIt. Então você apenas cria seu objeto e faz Cache.Add. O Cache.Add usará uma chave, algum tipo de string. Esta não é uma boa chave, sua chave precisa ser muito mais específica e então aqui está seu objeto e pronto. Você faz essa ligação e nos bastidores agora isso está acontecendo. Digamos que, se você tivesse essa topologia de réplica particionada, o que acontecerá é que seu aplicativo está conectado. Assim, cada caixa está conectada a todos os servidores de cache. Então, você acabou de fazer um Cache.Add certo? Então, Cache.Add irá olhar para o mapa de distribuição que é como o mapa do bucket. Cada bucket tem um intervalo de valores de chave em termos de um intervalo de valores de chave de hash em termos de quais chaves podem entrar nesse bucket. Então, ele vai usar esse mapa de bucket para saber com qual servidor ele deve ir e conversar porque está conectado a todos eles, certo?
E vamos dizer que você estava adicionando o item número três aqui. Ele irá adicionar o item número três aqui e se você tiver habilitado a replicação assíncrona, o aplicativo voltará e o aplicativo será concluído. O cache agora, esta partição sabe que precisa replicar isso aqui. Então, ele irá replicar de forma assíncrona, em uma operação em massa, isso para a outra caixa e você terá imediatamente esse item em dois lugares. Então, foi isso que o Cache.Add fez nos bastidores.
Ok, estou indo e voltando porque queria apenas dar uma visão geral, mas um cache parece, como criá-lo, como é uma API.
Recursos de cache de dados do aplicativo
Agora, vamos ver quais são os problemas que você precisa resolver ao usar o cache para armazenamento em cache de dados do aplicativo.
Mantenha o cache atualizado
Falamos sobre isso manter o cache atualizado, certo? Então, como você mantém o cache atualizado? Como você garante que um cache está atualizado?
O mais comum e o que todos apoiam, incluindo Redis é expiração. A expiração absoluta. Então, quando você está adicionando algo ao cache, digamos, mesmo aqui você especifica uma expiração aqui, ou seja, digamos que você está dizendo expirar isso após um minuto. Quando você diz isso em caso de NCache, NCache criará índices no servidor e monitoraremos esses dados e expiraremos após um minuto. Então, na verdade é isso, ele realmente especifica um valor absoluto de data e hora que era um minuto a partir de agora. NCache sabe que nesse valor de dia ele precisa expirar esse item. Então, é assim que o cache automaticamente se encarrega de garantir que os dados sejam removidos. E, o que isso significa realmente? Isso significa que você está dizendo ao cache que eu realmente não me sinto confortável em manter esses dados por mais de um minuto ou mais de cinco minutos porque acho que alguém vai alterá-los no banco de dados. Portanto, é seguro mantê-lo no cache por tanto tempo. Há outra expiração chamada expiração deslizante que parece a mesma, mas sua finalidade é totalmente diferente. A expiração deslizante é usada principalmente para limpeza. Portanto, se você tiver sessões, use a expiração deslizante para limpar depois que ninguém estiver usando esta sessão. Assim, quando alguém se desconectar após 20 minutos de inatividade, a sessão será considerada expirada. Assim, ele será removido automaticamente.
Usando dependências de banco de dadosMas isso não tem nada a ver com manter o cache atualizado. A expiração absoluta é aquela que mantém o cache atualizado. Mas, há um grande problema com a expiração absoluta. E o problema é que você está supondo que é seguro manter os dados para isso no cache por tanto tempo e essa suposição nem sempre é precisa. Então, o que você faz nesse caso? Então, nesse caso, você precisa ter a capacidade de o cache se sincronizar. Se notar uma mudança no banco de dados, isso significa que o cache precisa saber qual é o seu banco de dados. Isso significa que o cache deve ter um relacionamento entre o item armazenado em cache e algo em algum dado no banco de dados que você deve informar ao cache e é aí que existe essa coisa chamada dependência de cache SQL no ADO.NET que NCache usa, que é a dependência do SQL e isso também é chamado de dependência do Oracle, que na verdade funciona de uma forma muito simples. Mas, é um recurso realmente poderoso. E, nós viemos aqui. Vou usar apenas a dependência SQL. Então, quando você está adicionando algo ao cache, você faz o mesmo Cache.Add, certo? Você tem uma chave de cache. Agora, em vez do valor, você especifica o item de cache que é NCache's própria estrutura de dados e nela contém o valor, mas também contém essa coisa chamada dependência de cache do SQL.
Essa dependência de cache SQL é NCache's própria classe, mas mapeia para a dependência de cache ADO.NET SQL. Observe, ele tem uma string de conexão aqui e depois tem uma instrução SQL. Portanto, a instrução SQL neste caso está mapeando para uma linha na tabela de produtos. Então, o que realmente está acontecendo aqui? Quero dizer, você está realmente executando este código aqui. Seu banco de dados está aqui, então você está pedindo ao cluster de cache para agora se conectar ao banco de dados com base na string de conexão que você acabou de passar, com base nessa string de conexão e você está passando o servidor SQL e está dizendo por favor conectar com meu banco de dados do servidor SQL. E monitore o servidor SQL para notificá-lo, sendo você o servidor de cache, se houver alguma alteração nesse conjunto de dados. Isso significa que esta linha é atualizada ou excluída. Se isso acontecer, o servidor SQL envia uma notificação de banco de dados para o cliente que neste caso é o servidor de cache. Um desses. E, então, o que o servidor de cache faz? O servidor de cache remove esse item do cache. Remover significa que, como não está mais no cache, seu aplicativo é forçado a obtê-lo do banco de dados que possui a cópia mais recente agora. Portanto, embora a expiração seja um palpite, isso não é um palpite. Esta é uma sincronização previsível real, onde garante que o cache esteja sempre consistente com o banco de dados.
Agora, em caso de NCache, há três maneiras diferentes de fazer isso. Uma é a dependência SQL que usa eventos de banco de dados, que é como tempo real. O outro é NCaches própria dependência de banco de dados que ele usa polling e isso é para os bancos de dados que não possuem mecanismo de notificação de eventos ou mesmo para o servidor SQL, se você acha que tem muitas dependências SQL e para cada dependência SQL uma dependência de cache SQL é criada em SQL server que é uma estrutura de dados extra. Pense se você tivesse centenas de milhares deles criados, seu servidor SQL iria engasgar. Então talvez não seja uma boa ideia se você tiver muitas dependências de SQL ter essa forma de sincronização. Então talvez a dependência de banco de dados seja muito melhor onde em uma chamada ela pode sincronizar milhares de linhas porque possui uma tabela de pesquisa que ela monitora.
E há uma terceira maneira que é apenas escrever um procedimento armazenado CLR e chamá-lo pelo seu gatilho. Portanto, se você tiver um gatilho de atualização, inserção, atualização ou exclusão, chame esse procedimento CLR. E o procedimento CLR pega os dados dessa linha, constrói o objeto .NET que seu aplicativo está usando e o armazena no cache. Agora, é aqui que uma API assíncrona é muito útil porque você não deseja esperar na transação do banco de dados para que um cache seja atualizado. Ele apenas retarda as transações do banco de dados que tendem a expirar muito rapidamente. Portanto, é realmente aconselhável que, se você for implementar esse mecanismo, use os métodos assíncronos para atualizar os dados.
Então, essas são as três maneiras de sincronizar o cache. Este recurso é realmente importante porque permite que você tenha certeza de que o cache estará sempre atualizado, sem o qual você está apenas fazendo um palpite. E, da mesma forma, você pode sincronizar o cache com bancos de dados não relacionais. Há um recurso de dependência personalizado que NCache tem qual é o seu código que NCache chamadas que você pode ir e monitorar seu armazenamento de dados personalizado. Sua fonte de dados personalizada pode ser um armazenamento em nuvem. Pode ser o que for, é apenas um código que você pode ir e verificar. Portanto, manter o cache atualizado é realmente importante e essas são as maneiras de garantir isso.
Leitura e escrita
Portanto, o próximo recurso é leitura e gravação.
A leitura é basicamente, é novamente o seu código. Agora, todos esses recursos dos quais estou falando NCache tem mas não são NCache só. Todos os caches Java os possuem. Redis pode ou não tê-los. Então, é isso que você precisa fazer se você quiser fazer um detalhamento, se você quiser saber se o que Redis tem ou não, no caso de NCache basta vir aqui e ir para as comparações e há um Redis contra NCache comparação de recursos. Isso é baseado em sua documentação e documentação de caches. Então, você pode realmente fazer o download disso e passar por todos esses recursos. Portanto, a leitura basicamente é o seu código que fica no servidor de cache. Então, parece com isso. Então, é isso que você implementa. Então, deixe-me mostrar essa interface para que a interface de leitura se pareça com... Então, aqui está uma interface de leitura aqui, certo? Cursor de mão em NCache e há um InIt que se conecta à sua fonte de dados, descarte e há um método de carregamento. Então, load lhe dá uma chave e você devolve um objeto baseado em quaisquer dados que você tenha. E, então, você pode especificar quando deve expirar e outras coisas. A mesma coisa acontece com write-through é que você tem InIt e descarte e, em seguida, há uma gravação na fonte. Portanto, a gravação pode ser adicionar, atualizar ou excluir. Onde você usa a escrita de leitura e por que eles são tão importantes?
Read-through, antes de mais nada, assim do jeito que funciona, deixa você ter um Cache.Get e o cache não tem os dados. O Cache chamará sua leitura para obtê-la do banco de dados. Esse é um benefício. O segundo benefício é que você pode combinar leitura com expiração e sincronização de banco de dados. Então, em vez de remover isso do cache, você o recarrega. O write-through funciona da mesma maneira, exceto que há um write-behind, o que significa que você só atualiza o cache quando o cache atualiza seu banco de dados. Assim, suas atualizações também se tornam super-rápidas. Portanto, sempre que o desempenho do banco de dados se tornar um gargalo, você terá um cache para salvá-lo. Depois de implementar o read-through, write-through, você pode consolidar todo o código de persistência ou a maior parte dele na camada de cache e pode se beneficiar desses dois recursos sobre os quais acabamos de falar.
Agrupamento de dados e pesquisa de dados
Assim, uma vez que você está mantendo o cache atualizado e também está fazendo a leitura e gravação, agora você está começando a armazenar em cache muitos dados. Portanto, o cache não é mais apenas um armazenamento de valor de chave. Quero dizer, não é conveniente buscar tudo como uma chave.
Você tem que ser capaz de pesquisar. Você tem que ser capaz de fazer pesquisa SQL. Então, você tem que ser capaz de fazer o que está acostumado a fazer com o banco de dados.
Se um cache não permitir que você faça uma pesquisa SQL então se torna muito limitante e da mesma forma porque você não pode fazer junções em um cache porque é um cache distribuído, existem outros recursos de agrupamento e subagrupamento e tags que permitem agrupar dados e buscar tudo em uma chamada.
Então, novamente, facilitar a localização de dados no cache é realmente importante se você for armazenar muitos dados em cache. Então, essas características são muito importantes.
Recursos de cache distribuído
Vou passar rapidamente por alguns, um recurso que eu realmente queria tocar é chamado de cache próximo ou cache do cliente.
Assim que as pessoas que estão acostumadas a fazer o cache InProc autônomo, quando mudam para um cache distribuído de repente, seu desempenho cai porque estão atravessando a rede. Eles precisam passar pela serialização e, de repente, o desempenho não é mais rápido. Muitos de nossos clientes reclamam, bem, eu esperava que meu desempenho aumentasse, na verdade caiu. E o motivo é porque você não pode competir com o cache InProc autônomo que tem o objeto armazenado em seu heap. Portanto, se você tiver um recurso de cache do cliente que essencialmente é exatamente um cache local que mantém esse objeto local, mas está conectado ao cache clusterizado.
Novamente, esta é uma característica que NCache tem e a maioria dos caches Java tem que realmente lhe dará o mesmo desempenho rápido sem perder a coisa.
Escolha NCache, você pode ir ao nosso site e baixá-lo é um cache de código aberto. Então, você pode baixar o cache de código aberto ou o Enterprise Edition e, como eu disse, você pode obter todas as comparações entre NCache e Redis naquilo.