DDS 2017 London

Dimensionamento de aplicativos .NET com cache distribuído

Por Iqbal Khan
Presidente e Evangelista de Tecnologia

Se você está aumentando o volume de transações de dados, o volume da sessão ou o tamanho do objeto, esta palestra é para você. Saiba como aumentar o desempenho do aplicativo usando um cache distribuído entre seus aplicativos e seu banco de dados. Esta conversa abrange:

Visão geral rápida dos gargalos de escalabilidade em aplicativos .NET
Descrição do cache distribuído e como ele resolve problemas de desempenho
Onde você pode usar o cache distribuído em seus aplicativos
Alguns recursos importantes em um cache distribuído
Exemplos práticos usando um cache distribuído

Visão geral

Olá a todos, meu nome é Iqbal Khan. Eu sou um Evangelista de Tecnologia na Alachisoft. Nós somos os fabricantes de NCache. Quantas pessoas já ouviram falar NCache antes? Bom, bom número. O tópico de hoje é dimensionar aplicativos .NET com cache distribuído. Não se trata NCache, trata-se do problema geral de escalabilidade que os aplicativos .NET enfrentam e como resolver esse problema.

Prefiro uma discussão mais interativa. Então, em vez de esperar até o final para fazer perguntas, por favor, levante a mão se tiver uma pergunta enquanto estou falando. Vou passar por uma combinação de código arquitetônico e código real e também mostrarei a você NCache como um exemplo de como é um cache.

O que é escalabilidade?

Então, vamos tirar algumas definições do caminho. Tenho certeza que a maioria de vocês já sabe disso, mas o que é escalabilidade? A escalabilidade não é o desempenho do aplicativo. É o desempenho do aplicativo sob cargas de pico. Portanto, se você tiver um aplicativo com desempenho super rápido com 5 usuários, ele não é necessariamente escalável, a menos que tenha um desempenho super rápido com 5,000 ou 50,000 ou 500,000 usuários. É claro que se o seu aplicativo não tiver um desempenho rápido com 5 usuários, você terá outros problemas além da escalabilidade.

Escalabilidade Linear vs. Escalabilidade Não Linear

A escalabilidade linear é mais uma arquitetura de implantação. Seu aplicativo está arquitetado de forma que você possa continuar adicionando mais servidores em um ambiente com balanceamento de carga e, à medida que você adiciona mais servidores, aumenta a capacidade de transação. A propósito, quando uso a palavra escalabilidade, quero dizer escalabilidade de transação, não os dados de escalabilidade. Não estamos falando de grandes quantidades de dados. Não estamos falando de terabytes ou petabytes de dados. Estamos falando de muita atividade. Portanto, se seu aplicativo for arquitetado de forma que você possa adicionar mais servidores e, à medida que adiciona mais servidores, sua capacidade aumenta de forma linear, então você é linearmente escalável.

Se não, então você tem mais uma curva logarítmica, para aqueles que ainda se lembram do cálculo da faculdade e o problema com essa curva é que você verá um aumento, mas depois de um certo ponto adicionar mais servidores na verdade não tem benefício, na verdade, diminui o desempenho porque existem alguns gargalos em seu aplicativo que simplesmente não desaparecem. Então, você definitivamente não quer ser não linear.

Quais aplicativos precisam de escalabilidade?

Então, quais aplicativos precisam de escalabilidade? Estes são geralmente aplicativos de servidor, é claro. Aplicativos Web, ASP.NET, agora ASP.NET Core Além disso. Serviços web. Novamente, você pode fazer isso através do WCF. Você poderia fazer isso ASP.NET web API ou ASP.NET Core API web. E, ou seja, os serviços da Web geralmente são o back-end da Internet das Coisas, que é um espaço emergente bastante rápido nos dias de hoje.

Esses também são aplicativos de processamento de big data. Então, se você tem muitos dados, é aí que vem a parte de dados da escalabilidade, mas mesmo assim não se trata dos dados, mas da rapidez com que você pode processá-los. Portanto, se você tiver um aplicativo de processamento de big data, ele precisa ser dimensionado. A maioria dos aplicativos de processamento de big data geralmente não está em .NET. Eles estão mais no lado Java e meu foco é mais no aplicativo .NET. Mas, conceitualmente falando, as aplicações de processamento de big data também são algo que precisa de escalabilidade.

E, finalmente, quaisquer outros aplicativos de servidor. Você pode ser uma instituição financeira, você pode ser um grande banco, você tem milhões de clientes, eles ligam, mudam de endereço, emitem um novo cartão, ou qualquer outra coisa e você precisa processar, talvez eles queiram transferir fundos e você precise processar todas essas solicitações dentro de um determinado prazo para fins de conformidade. Então, você tem muitos desses processos em lote de back-end em andamento e eles precisam processar mais e mais transações dentro de um período de tempo muito pequeno, pequeno em termos de apenas algumas horas que você recebe todas as noites. Portanto, qualquer aplicativo de servidor. Portanto, se você possui algum desses aplicativos e eles precisam de escalabilidade, você está no lugar certo hoje.

O problema de escalabilidade

Então, qual é o problema de escalabilidade? Bem, a camada do aplicativo não é o problema. Na maioria desses aplicativos que mencionei, a camada do aplicativo parece funcionar perfeitamente bem. Você pode adicionar mais servidores. Você geralmente tem um ambiente com balanceamento de carga. Se você tiver um aplicativo ASP.NET, digamos, você terá um balanceador de carga no topo e terá um grupo de servidores para os quais o balanceador de carga envia o tráfego e conforme você precisa de mais tráfego, conforme precisa lidar mais usuários, basta adicionar mais servidores. Então, é muito simples.

Mas o problema é que seu banco de dados é se isso é relacional ou se são dados de mainframe eles se tornam o gargalo. E, relacional não significa qualquer banco de dados específico. Pode ser SQL Server, pode ser Oracle, MySQL, Db2, qualquer um desses. Todos os bancos de dados relacionais têm essa fraqueza inerente que eles não podem escalar. Então, é exatamente por isso NoSQL movimento começou e de fato temos até um produto no espaço .NET chamado NosDB que é um código aberto NoSQL database mas o NoSQL databases nem sempre são a resposta. Quero dizer, eles definitivamente resolvem o problema de escalabilidade. Tecnicamente falando, se você usar um NoSQL database você não terá gargalos de escalabilidade. Mas, o problema é que, por uma combinação de razões técnicas e comerciais, você não pode mover todos os seus dados fora do mainframe relacional ou legado para NoSQL.

Assim, o NoSQL é mais do que chamamos de novos dados, você sabe. Os dados de negócios tradicionais ainda residem em bancos de dados relacionais por vários motivos. Então, o que isso significa é que você precisa resolver esse problema enquanto vive com bancos de dados relacionais. Você não pode dizer que vou apenas remover o banco de dados relacional da minha imagem. Na verdade, mesmo nenhum de nossos clientes muda completamente para um NoSQL. Eles movem alguns dos dados para NoSQL. Jogadores ainda maiores como o MongoDB, eles têm a mesma história que as pessoas que se mudam para NoSQL database mover alguns dados para NoSQL e ainda mantêm os dados tradicionais no banco de dados relacional.

Implantação de Cache Distribuído (NCache)

Então, você precisa resolver o problema com bancos de dados relacionais na imagem e é aí que um cache distribuído Na verdade, ele oferece o mesmo benefício muitas vezes NoSQL database. Na verdade, se você pensar bem, é um NoSQL armazenamento de valor-chave na memória. Então, você sabe, se você olhou para NoSQL databases, há o banco de dados de documentos JSON, há o armazenamento de valores de chave e há o banco de dados de gráficos e há os outros tipos. Então, o key value armazena, se for um... A única coisa que um cache de distribuição é que ele não faz persistência, fica tudo na memória. É o armazenamento de valor chave. E, ele é distribuído em vários servidores, portanto, oferece o mesmo benefício, é dimensionado porque você pode adicionar mais servidores. Então, pense nisso como a camada de aplicativo aqui. Bem aqui está a camada do aplicativo e, geralmente, um balanceador de carga aqui em algum lugar. E, à medida que você adiciona mais servidores nessa camada, o banco de dados ficará cada vez mais sob estresse, a menos que você coloque uma camada de cache no meio.

A camada de cache é dimensionada exatamente como a camada de aplicativo. Não tem gargalos, porque você continua adicionando mais e mais caixas. Os dados são distribuídos em vários servidores. Estes são servidores de baixo custo por sinal. Estes não são servidores de banco de dados de alto nível. Na verdade, nossos clientes… A configuração típica é de cerca de 16 gigabytes de RAM, cerca de 8 núcleos, como uma caixa de servidor web típica, mas apenas mais memória. 16 giga, 16 a 32 giga, nós nem recomendamos ir mais de 32 giga. Na verdade 64 giga é praticamente o máximo que vamos recomendar aos nossos clientes. Diremos, adicione mais servidores. Por que é que? Porque, se você aumentar muito a memória, o .NET tem essa coisa chamada coleta de lixo. E a coleta de lixo exige muito poder de processamento. Então, quanto mais memória você tem, mais coleta de lixo ela precisa fazer e mais rápido sua CPU tem que se tornar e então seu cache não está se tornando cada vez mais como um banco de dados e está se tornando mais caro e tudo mais. Então, é melhor ter mais servidores do que ter alguns servidores de ponta.

Assim, um cache distribuído forma essencialmente um cluster de servidores. Geralmente, é um cluster baseado em TCP e esse cluster significa que todos os servidores do cluster conhecem uns aos outros e agrupam os recursos em uma capacidade lógica. Ter o cluster significa que quando você precisar aumentar a capacidade, basta adicionar outro servidor ao cluster. Ou, quando você precisa diminuir a capacidade, você descarta um servidor. E, quando você tem essa camada de cache, é um armazenamento na memória porque você não precisa persistir os dados. Não é uma loja permanente. O armazenamento permanente ainda é o banco de dados e, por ser um armazenamento na memória, também precisa fornecer replicação de dados.

O objetivo em toda esta imagem é essencialmente ir à cache cerca de 80% do tempo. Então, se você pudesse imaginar, se você fosse ao cache 80% do tempo, seu banco de dados estaria totalmente livre de estresse, você sabe. Você poderia realmente aumentar a escalabilidade um pouco.

Pergunta: A aplicação ainda não precisa falar muito com o banco de dados?

Não, na verdade. Então, depende dos dados. Mas, a maioria dos dados de aplicativos se enquadra na categoria de dados de referência ou dados transacionais que não mudam a cada poucos segundos. Ele muda talvez a cada poucos minutos. Então, para todos esses dados, você faz muito mais leituras do que gravações. Então, a primeira leitura vai para o banco de dados e até que existem recursos como NCache tem um recurso onde você pode pré-carregar o cache com dados. Então, você pode aquecer o cache com todos os dados que você acha que vai ter e então mesmo que o tráfego não esteja sendo atingido, o banco de dados não está sendo atingido. Mas, depende dos dados. Por exemplo, se você tiver outro tipo de dados, digamos, se você armazenar sessões nele, então para cada leitura há uma gravação. Então, depende e eu vou repassar esses detalhes, mas essa é uma boa pergunta.

Bem, a razão pela qual você não seria, porque o cache carrega os dados e os mantém no cache. Portanto, o tráfego entre o cache e o banco de dados é muito pouco frequente. Novamente como eu disse 80% das vezes as leituras são feitas e o cache tem os dados. Portanto, quando você o armazena em cache, o armazena em cache por um determinado período de tempo e, durante esse período, o cache não vai para o banco de dados todas as vezes. Mas, o aplicativo está chegando sempre ao cache. Então, mesmo que você tenha muito tráfego, tudo está chegando ao cache e, de repente, o banco de dados fica muito leve.

Na verdade, há particionamento para cada caixa que armazena dados diferentes e também há alguma redundância embutida para confiabilidade, mas entrarei em mais detalhes.

Portanto, esta imagem (Fig-1) pretende convencê-lo de que, no ambiente de alta escalabilidade de hoje, o cache distribuído é como a melhor prática de fato. Portanto, se você projetar seu aplicativo, lembre-se de um cache. Não importa qual cache. Essa é uma discussão separada. A primeira discussão é que você precisa projetar o aplicativo de forma que vá para um cache distribuído. Se você fizer isso e puder se sentir confiante de que, quando a empresa precisar que seu aplicativo funcione, o aplicativo não vai engasgar.

E, se você não planejar com antecedência, a desvantagem de não conseguir escalar é que esse problema acontece quando o negócio está realmente indo bem. Imagine se você é uma companhia aérea e acabou de fazer uma promoção de fim de semana para algum local de férias e milhões de novos usuários estão acessando um site para pesquisar voos e talvez comprar passagens. Se o desempenho do seu site começar a diminuir a cada clique foi de um minuto, você perderá clientes. E se for ainda pior e seu aplicativo começar a falhar porque o banco de dados acabou de ser bloqueado, você perderá muitos negócios. Então, você precisa planejar com antecedência. Mesmo que você não esteja enfrentando esse problema hoje e, novamente, não se trata de desempenho.

Muitas pessoas pensam, use cache porque vai melhorar o desempenho. Ele melhora o desempenho, mas os bancos de dados são muito rápidos hoje em dia. Se você tiver apenas esses cinco usuários. Eu não ouvi ninguém reclamar sobre o banco de dados estar lento. Então, o problema não é o desempenho. O problema é a escalabilidade, porque há apenas um servidor de banco de dados e você pode adicionar mais servidores na camada do aplicativo e, de repente, o banco de dados se torna um gargalo.

Pergunta: Devemos usar VMs ou caixas físicas para clusters de cache?

Muito boa pergunta. Eu ia falar sobre isso e esqueci e é bom que você pergunte. Então, essas podem ser caixas físicas. Ainda temos clientes que possuem caixas físicas mas cada vez mais clientes nossos estão migrando para VMs e agora a nova tendência são os containers. Portanto, no mínimo, você terá VMs. Portanto, todo servidor de cache é uma VM. Portanto, você tem no mínimo duas VMs de servidor de cache. Como eu disse 16 a 32 giga cada. Claro que você não quer ter os dois VMS na mesma caixa física. Porque, então, você perde esse benefício de alta disponibilidade. Porque, se essa caixa travar, ambos os VMS desaparecerão.

Mais uma pergunta. Então, os dados físicos são armazenados na memória?

Em memória. Exatamente exatamente. É tudo armazenamento na memória. E, por ser uma loja temporária, você armazena por alguns minutos, algumas horas, alguns dias, algumas semanas, sabe, você não armazena permanentemente. A loja permanente ainda é a base de dados. Seja lá o que é. Isso pode ser, como eu disse, pode ser um mainframe legado, pode ser relacional, pode ser NoSQL.

Mesmo com NoSQL database, você deve usar um cache distribuído. Porque NoSQL não é tão rápido quanto um cache distribuído e porque temos os dois produtos que conhecemos. Fazemos os benchmarks. Ainda é 10 vezes mais rápido.

Eu não estou familiarizado com NoSQL database, então eu estava me perguntando, por que ele tem um desempenho melhor do que um banco de dados relacional?

Ele escala mais porque também distribui em vários servidores. Assim, assim como um cache distribuído pode ter 5, 10, 15, 20 servidores, você pode fazer o mesmo com um NoSQL database. Você não pode ter 20 servidores para SQL. Você pode ter talvez 2, para ativo-passivo ou ativo-ativo, mas é isso. Você sabe, você não pode realmente escalar. Então, é por razões de escalabilidade.

Portanto, são as VMs ou agora os contêineres estão se tornando cada vez mais populares para gerenciamento e isso pode ser local ou na nuvem, em qualquer ambiente.

Usos comuns do cache distribuído

Então, espero que esta imagem (Figura-1) os convença de que vocês precisam usar o cache. Então, agora você está convencido, digamos. A próxima pergunta que vem é, bem como eu uso isso? Onde eu uso, sabe? Portanto, há três lugares comuns em que você usa o cache.

Cache de dados do aplicativo

O número um é o que eu tenho falado até agora, que são os dados do aplicativo, que era essa imagem exata. Você armazena dados em cache aqui, para que não precise ir ao banco de dados. A única coisa a ter em mente em armazenamento de dados do aplicativo é que agora os dados existem em dois lugares. Um é o cache, um é o banco de dados. Quando os dados existem em dois lugares, o que poderia estar errado? Sincronização. Então, esse é um problema tão grande que a maioria das pessoas tem medo de usar o cache, para qualquer coisa que não seja dados somente leitura. Se você perguntar a uma pessoa comum, você já pensou em usar o cache ou está fazendo algum cache? Às vezes, as pessoas criam essas tabelas de hash ou algumas no armazenamento de memória, colocam apenas dados somente leitura. Dados que nunca mudam na totalidade do aplicativo ou em um período de tempo realmente muito confortável. Bem, os dados somente leitura ou os dados de referência são apenas 10-15% do total de dados. Portanto, isso oferece muitos benefícios, mas o benefício real é se você puder armazenar em cache todos os dados. Isso significa que você realmente precisa ser capaz de lidar com…

Um bom cache distribuído deve lidar com a sincronização. Portanto, deve garantir que o cache esteja sempre atualizado. Então, você tem essa confiança no cache de que tudo o que você está lendo do cache é a cópia mais recente desses dados.

E, se você não tiver essa confiança de que ficará restrito a dados somente leitura, o que praticamente minimiza ou reduz o valor do cache.

Cache específico do ASP.NET

Então, o segundo benefício é o Cache específico do ASP.NET. Eu não estou entrando em ASP.NET Core neste momento, mas vou meio que tocar nisso brevemente. Mas, cache do ASP.NET, há três lugares onde você faz isso e dois pelo menos agora. Se você tiver a estrutura MVC, não terá o estado de exibição, mas as sessões de cada aplicativo ASP.NET têm sessões e as sessões devem ser armazenadas em algum lugar. Por padrão, eles são armazenados na memória, que é In-Proc, que está dentro do processo de trabalho do aplicativo ASP.NET ou do servidor SQL. O servidor de estado não está disponível na nuvem, está apenas no local e todos eles têm problemas. Alguns têm problemas de escalabilidade. Na verdade, todos têm problemas de escalabilidade. Alguns também têm problemas de desempenho. Como o banco de dados SQL também tem problemas de desempenho.

Portanto, um ótimo caso de uso para cache distribuído é apenas colocar essas sessões no cache. Você sabe, essas sessões são armazenadas… se você as armazena em SQL, elas são armazenadas como blobs. E os bancos de dados relacionais não são projetados para armazenamento de blobs. Mas, NoSQL ou armazenamentos de valores-chave, o valor é o blob. Então, ele se encaixa muito bem em um cache distribuído. Claro que você também tem que resolver... mais e mais pessoas estão indo para vários bancos de dados ou vários datacenters para recuperação de desastres ou para balanceamento de carga, balanceamento de carga geográfico. Então, você também precisa resolver esse problema.

Um estado de exibição é algo que não está mais no ASP.NET, mas se você é anterior - acho que o ASP.NET 5. Se você está no ASP.NET 4, então o estado de exibição ou pré MVC, o estado de exibição existia. Ele ainda existe na maioria dos aplicativos ASP.NET que foram desenvolvidos durante todo esse tempo.

Para aqueles de vocês que não sabem o que é um estado de visualização, um estado de visualização é uma string criptografada que é enviada pelo servidor da Web para o navegador, apenas para voltar quando um post back acontece. Então, essa string pode ter centenas de kilobytes e ela viaja para o navegador, é armazenada no navegador e depois volta. Multiplique isso por milhões de transações que seu aplicativo precisa processar e tem dois problemas, um que consome muita largura de banda, o que não é uma largura de banda barata, você tem que pagar pela largura de banda. Em segundo lugar, diminui o tempo de resposta porque é uma carga pesada que está viajando. Portanto, é um caso ideal para armazenar em cache isso no servidor e apenas enviar uma pequena chave e, quando ela voltar da próxima vez, o estado de exibição é obtido do cache e exibido na página. Novamente, o estado de exibição é apenas uma questão se você não estiver usando o framework MVC e definitivamente nem está lá no ASP.NET Core porque ASP.NET Core é MVC.

O cache de saída ASP.NET também é algo que faz parte do ASP..NET framework, não no ASP.NET Core onde praticamente armazena em cache as saídas da página. Então, se sua página não mudar na próxima requisição, por que executá-la novamente? Então, o ASP.NET faz cache da página, então da próxima vez que a requisição vier com os mesmos parâmetros, mesmo tudo, uma saída da última execução será servida para a página.

Então, esse framework já existe e é realmente bom usar um cache distribuído para ele, de modo que, em um ambiente multi-servidor, uma vez armazenado em cache, esteja disponível imediatamente para todos os servidores. ASP.NET Core tem apenas sessões para cache e não há estado de exibição e não há cache de saída. Mas, há outra coisa chamada cache de resposta. Então, ASP.NET Core tem meio que padronizado agora com os aplicativos da Web em geral, onde o cache de conteúdo acontece fora do servidor. Então, isso também é um bom candidato para armazenamento em cache. Então, ASP.NET Core tem isso um conceito de middleware de cache de resposta. Então, há um middleware embutido que você pode usar e então você pode fazer um middleware de terceiros. Como NCache fornecerá um muito em breve.

Então, de qualquer forma, para o cache do ASP.NET e isso é importante ter em mente agora é que você não está mais armazenando esses dados no cache. Então, diferentemente dos dados do aplicativo onde os dados existem em dois lugares, agora os dados existem apenas em um lugar e esse é o cache e é um cache na memória. Então, quando a loja na memória é sua única loja, o que pode dar errado? Sim. Quero dizer, se aquela caixa cair, você está encharcado. Porque a memória é volátil. Não é persistente. Então, a maneira de lidar com isso, é claro, é fazer a replicação. Ter esses dados em mais de um servidor. Mas, novamente, dois problemas muito diferentes para resolver. Um bom cache distribuído deve fazer replicação inteligente. Se você deseja armazenar sessões ASP.NET com confiança, por exemplo. Caso contrário, o que vai acontecer? Vamos voltar a isso, você sabe, companhia aérea. Acabei de acessar esse site. Vou comprar $ 5,000 em ingressos. Eu fiz toda a minha pesquisa de voos, todos os tipos de combinações e estou prestes a... Entrei com minhas informações de pagamento e estou prestes a enviar e, de repente, enviei de volta para a página de inicialização, seja o que for, porque minha sessão é perdido. Porque quando eu cliquei em enviar, ele foi para o servidor web, esse servidor web não estava lá, ele travou e a sessão foi embora. Então, definitivamente não é uma boa foto.

O terceiro caso de uso é um compartilhamento de dados em tempo de execução através de eventos. Isso é algo que muitas pessoas não sabem, agora está se tornando cada vez mais popular que um cache distribuído, uma vez que você o tenha em seu ambiente, é uma plataforma realmente poderosa para compartilhamento de dados entre vários aplicativos por meio de um Pub / Sub modelo ou outro compartilhamento de dados orientado a eventos.

Por exemplo, você pode ter vários aplicativos que precisam compartilhar dados. Um aplicativo produz algo, coloca no cache, dispara alguns eventos, existem assinantes para esse evento. Então, existem outras instâncias de aplicativos ou outros aplicativos, muitas vezes você tem algum tipo de fluxo de trabalho acontecendo nos aplicativos. Que algo seja feito primeiro e depois com base nessa outra coisa seja feita. E, nesse caso, há esses assinantes desses eventos. Esses aplicativos serão notificados.

Pense agora nesta foto (Figura 1) aqui. Não veja isso como um cache entre o aplicativo e o banco de dados. Pense nisso como um barramento de mensagens e esses aplicativos estão todos conectados ao barramento de mensagens. Um aplicativo deste servidor coloca dados no cache, dispara um evento. Outros aplicativos talvez em alguns desses servidores sejam notificados e imediatamente consumirão os dados. Maneira muito poderosa.

Algumas pessoas usam filas de mensagens. Pois muitas dessas filas de mensagens têm um propósito definido. Um cache distribuído não está aqui para substituí-los completamente, mas um subconjunto dos casos. Quando todo o compartilhamento de dados está dentro desse mesmo datacenter, não é um ambiente muito distribuído e é um ambiente de alto tráfego. Uma fila de mensagens não é escalável, ao contrário de um cache distribuído. Porque uma fila de mensagens não possui um cluster como este. Você realmente não pode adicionar mais. Portanto, se você tivesse milhões de transações acontecendo e parte disso também fosse informação de mensagem, as filas de mensagens não poderiam lidar com essa carga, mas um cache poderia.

Então, um compartilhamento de dados em tempo de execução é uma maneira realmente poderosa e vou tocar nisso. Novamente, no compartilhamento de dados em tempo de execução, os dados geralmente existem apenas no cache. Embora, uma forma diferente dele possa existir no banco de dados. Porque, ele foi lido do banco de dados, transformado através de alguma outra forma e depois colocado no cache para compartilhamento.

Portanto, alguns dos recursos são comuns em todos os caches. Alguns são apenas NCache no lado .NET, mas tudo o que é NCache no lado do .NET não é um recurso proprietário do .NET. Porque você vê os mesmos recursos no lado do Java e em todos os caches do Java. Assim, Java é muito mais avançado ou muito mais maduro de um mercado porque, Java tem sido a tecnologia do lado do servidor por mais tempo do que .NET. Então, você vê isso... No lado do Java. No lado .NET, você o verá em alguns dos caches, não em todos. Por exemplo, AppFabric, acho que não tinha. Redis tem um pouco disso não tudo. NCache tem um full blown como os caches Java.

Então, esses são os três casos de uso. Alguma dúvida sobre isso, antes de me aprofundar em cada um deles?

Demonstração prática

Antes de entrar em qualquer um desses, deixe-me mostrar primeiro como é um cache? claro que vou usar NCache como o exemplo, mas o objetivo é dar a você uma ideia de como um cache realmente se parece. Por exemplo, tenho três VMs no Azure. Eles estão correndo. Demo1 e demo2 são minhas VMs de servidor de cache. Então, eu vou ter um cluster de cache de 2 nós.

O cliente de demonstração é meu servidor de aplicativos. Portanto, é uma VM cliente de cache.

Criar um cache clusterizado

Estou logado na VM do cliente de demonstração aqui. Vou seguir em frente e criar um cache clusterizado. No caso de NCache, vou usar essa ferramenta chamada NCache Novos Negócios, que é uma ferramenta gráfica. Eu vou vir aqui e dizer, deixe-me primeiro ter certeza de que o cache já não existe. Ok, não, Ok, eu vou vir aqui e dizer para criar um novo cache clusterizado.

No caso de NCache todos os caches são nomeados. Então, meu cache é chamado demoCache. Vou deixar todo o padrão. Não vou entrar em detalhes disso. Vou manter... vou falar apenas sobre as partes que são importantes.

A primeira coisa que você escolherá é o que chamamos de topologia de cache em NCache e foi aí que um de vocês fez a pergunta sobre particionamento. Os dados são realmente distribuídos ou os mesmos dados existem em todos os servidores. Assim, a réplica de partição é uma topologia que NCache da-te.

Por exemplo, vou pular isso rapidamente e falar rapidamente sobre o que é essa topologia? Então, uma topologia de réplica de partição... Então, essa é uma topologia particionada, essa é uma réplica de partição.

Em um particionamento cada servidor tem 1º dos dados. Então, se você tem, digamos, no caso de NCache, quando você cria um cache clusterizado, ele cria mil buckets. Então, se você tem um cluster de dois servidores, cada servidor 500. Se você tem três, então cada servidor é um terço de mil.

Então, esses baldes são essencialmente como baldes de tabela de hash. Cada bucket é atribuído a um intervalo de valores de chave. Portanto, há uma função de mapa de hash que transforma suas chaves em valores de hash e elas se enquadram em quaisquer buckets em que devem se encaixar com base nas chaves. Portanto, uma réplica particionada tem uma partição em cada servidor. Vamos dizer, se você viesse aqui. Digamos, aqui está um cluster de três servidores, então, as três partições e cada partição tem um backup ou uma réplica em um servidor diferente.

No caso de NCache a réplica não está ativa. É passivo. Portanto, apenas a partição fala com as réplicas. O aplicativo fala com as partições. Então, digamos que cada cliente de cache, cada servidor de aplicativos se conecte a todos os servidores de cache. Ele se conecta e obtém todas as informações de associação do cluster. O mapa de distribuição é esse mapa de bucket. Então, ele obtém o mapa do balde que informa onde está cada balde? Com base nisso ele sabe, ok, se eu precisar adicionar o item número três, eu preciso ir para o servidor 2. Porque, é onde mora a partição 2, que deveria ter chave para o item número 3. Então, vai direto para esse servidor e ele pode fazer isso.

E, então, se um servidor cair, então, digamos, a partição 3 cairá, então a réplica 3 ficará imediatamente ativa. Então, vai se tornar uma partição agora. Ele se transformará de uma réplica em uma partição. Porque, você não sabe, você quer continuar. O cache precisa ser executado, o aplicativo precisa continuar. É alta disponibilidade, certo. Então, e então essa partição três percebe que existem apenas dois servidores, então, ela precisa se fundir nessas duas partições e meio que desaparecer, desaparecer. Então, ele se funde nas outras duas partições e, uma vez feito isso, uma réplica para a partição dois é criada aqui.

Então, novamente, apenas para dar uma visão geral do que essa topologia significa e é assim que a distribuição acontece para garantir que, à medida que você adiciona mais servidores, tenha mais e mais armazenamento e também é assim que a replicação acontece para que todos os dados existam em dois servidores . Portanto, não há perda de dados se algum servidor cair.

Novamente, a teoria da alta disponibilidade diz que dois servidores não serão desativados simultaneamente. As chances de dois servidores ficarem inativos simultaneamente são astronomicamente baixas em comparação com qualquer servidor inativo. Claro, como eu disse, se dois servidores estão na mesma fonte de alimentação, essa fonte de alimentação cai, então estou assumindo que tudo é redundante. Então duas coisas não falharão ao mesmo tempo. Então, é por isso que ter apenas duas cópias é mais que suficiente.

Vamos voltar. Então, essa foi a réplica da partição. Então eu vou escolher uma replicação assíncrona.

Portanto, existem dois modos. A maioria dos caches distribuídos faz isso chamado consistência eventual. O que significa que, por causa da distribuição, se você tiver que fazer uma sincronização imediata, tudo ficará mais lento. Mas a maioria dos dados que você pode pagar, meio que os enfileira e tem atualizações assíncronas. Então, o assíncrono é o que tomará como padrão aqui.

Vou escolher o cliente de demonstração ou demo 1 é o primeiro servidor. Vou escolher demo 2 como um segundo servidor.

Eu vou vir aqui eu vou só pegar os padrões.

Vou especificar quanta memória cada servidor deve usar.

Claro que no seu caso será muito mais. Então, digamos, se você tiver 16 GB de memória em cada caixa, você precisa alocar alguns para a partição e alguns para a réplica. Então, digamos, 2 a 3 GB devem ser deixados para o sistema operacional e outros processos e cerca de 13 GB são deixados. Então, por 7.5 ou 6.5 GB, um para partição e outro para réplica. E, porque você especifica esse tamanho para garantir que o cache não consuma mais do que isso. Por ser um armazenamento em memória, a memória é sempre limitada e nessa caixa pode haver outros aplicativos em execução. Então, você quer limitar a quantidade de memória que o cache deve usar e uma vez que o cache tenha usado essa memória…

Então, a próxima página seria. Digamos que você tenha usado toda essa memória. Então, agora o cache está cheio. Então, só duas coisas podem acontecer. Primeiro, ele remove alguns dos dados mais antigos ou outros ou, em segundo lugar, rejeita as novas inserções. Então, você tem que escolher esses dois. Claro que você quer fazer seu planejamento de capacidade, onde os dados que estão, se os dados do aplicativo, não há problema em despejar, pois você sempre pode recarregá-los do banco de dados. Não há problema em despejar sessões. Portanto, você deseja fazer seu planejamento de capacidade de forma que essas sessões nunca sejam despejadas. Agora você tem memória suficiente, RAM suficiente e servidores suficientes para sempre ter memória para sessões. E você deseja expirar as sessões, não despejar o tema. Evict significa que as sessões ainda não expiraram, mas não há mais memória, então, você está meio que despejando à força. Expiração em caso de NCache significa que você especificou que uma sessão é válida apenas por, digamos, 20 minutos de inatividade. Depois disso, a sessão deve ser limpa. Então, isso é expiração. Portanto, a expiração está correta, não há problema, mas o despejo é algo que você não deve fazer na sessão, não há problema em fazê-lo nos dados do aplicativo.

Então, o que você faz em caso de NCache, você cria um cache para as sessões e um cache para os dados do aplicativo. Então, é assim que você separa os dois. Então, digamos que eu acabei de criar esse cache. Então, é um cache de dois nós. Vou seguir em frente e adicionar um nó cliente que é minha caixa o cliente de demonstração e agora vou iniciar o cache.

Simule o estresse e monitore as estatísticas de cache

Então, como você pode ver, é bastante simples. É uma espécie de interface estilo Explorer. De um lugar você pode ir em frente e criar cache multi-servidor, gerenciá-lo, monitorá-lo e, uma vez feito isso, o que acontece é, digamos, agora que fez isso, vou ver alguns contadores PerfMon e vou execute esta ferramenta chamada ferramenta de teste de estresse que vem com NCache, que permite que você simule rapidamente o uso do aplicativo.

Então, digamos que eu fiz isso e agora está começando a... Então, está fazendo cerca de 500 a 800 transações por servidor. Então, isso é cerca de 2 vezes, essa é a carga. Eu quero aumentar a carga. Então, eu quero adicionar mais uma ferramenta de teste de estresse. Nossos clientes usam isso bastante porque quase todo mundo quer ver como o cache se comporta em seu ambiente. Você sabe, nós temos todos os benchmarks publicados e tudo mais, mas eles querem ver isso em seu ambiente. Então, eles em vez de programar e aplicar para fazer isso, isso pode simular muito rapidamente. Então, digamos, eu executei dois deles e agora a carga aumentou. Então, eu posso continuar adicionando mais e mais deles até que eu maximize esses dois servidores. Então, é aí que vem a escalabilidade.

Esses dois servidores estão funcionando super-rápido agora. Mas, à medida que eu aumento a carga, depois de um certo ponto eles atingem o máximo, que é o que acontece com um banco de dados. A única diferença é que você pode vir aqui e adicionar outro nó. Então, se você tivesse uma terceira VM, basta vir aqui e adicionar isso aqui e assim que fizer isso de repente a carga será distribuída e temos aquela imagem onde, você sabe, onde eu mostrei onde você começou os dois servidores e agora esses dois ficaram no máximo, você deseja adicionar um terceiro. Então, basta pegar outra VM e adicioná-la e agora ela se torna um servidor de três e NCache irá reajustar tudo automaticamente, vamos reparticionar ou redishomenagem o mapa do balde. Então, há um terceiro servidor adicionado em tempo de execução. Então, de repente você não tem esse problema de capacidade.

Sim, então, o que você faz é instalar o NCache software de servidor, em todas essas VMs. No caso da nuvem, você geralmente tem uma imagem de VM pré-configurada da qual cria as instâncias e, portanto, apenas inicia uma nova VM, ela tem NCache software em execução e basta adicioná-lo a este cluster.

Mas, novamente, o ponto principal é que, ao contrário de um banco de dados em que, uma vez que você atinge esse estado máximo, você é lavado, você sabe. O que você faz? Você sabe, tudo bem, eu quero comprar um mais caro. Bem, então você tem que comprar outra caixa e trazê-la para baixo e é um pesadelo. Aqui você acabou de adicionar outra caixa.

utilização NCache com sessões ASP.NET

Então, eu vou para aquele próximo agora. Então, agora que sabemos como é um cache. Então, agora vemos que... no caso de NCache, todos os caches são nomeados. Portanto, desde que você saiba o nome do cache, basta conectar-se ao cache. Então, como você se conecta ao cache para sessões? Isso é o mais fácil. Mais uma vez, a maioria dos nossos clientes, a primeira coisa que fazem com NCache eles usam para sessões. Por quê? Porque não há necessidade de programação. A única coisa que você precisa ter certeza no caso de sessões é que quaisquer objetos que você está colocando na sessão são todos serializáveis. Se você já está armazenando a sessão no SQL, já garantiu isso. Se você estiver armazenando sessões no modo In-Proc, talvez não tenha garantido isso. Então, você sabe, esse é o único teste que você tem que fazer. Mas, depois disso é bem simples.

Vou mostrar aqui uma pequena amostra. Assim, por exemplo, há uma amostra aqui chamada amostra do provedor de armazenamento de sessão. Então, eu tenho um aplicativo ASP.NET. Vou para o web.config. Suponha que eu esteja nesta caixa de servidor de aplicativos, você sabe. Se você ver essa foto aqui. Na verdade, deixe-me, voltar aqui. Então, aqui está o servidor de cache certo, mas meu aplicativo está sendo executado nesta caixa. Então, nesta caixa, criei dois clusters de servidores e adicionei um cliente a isso, certo. Então, agora o que aconteceu nesse cliente é que, no caso de NCache, opa não aqui. Ok, em caso de NCache ele realmente cria na pasta config há um client.ncconf, então ele cria uma entrada. Então, é assim que o aplicativo sabe a qual servidor se conectar.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <ncache-server connection-retries="3" retry-connection-delay="0" retry-interval="1" command-retries="3" command-retry-interval="0.1" client-request-timeout="90" connection-timeout="5" port="9800" local-server-ip="10.2.0.5" enable-keep-alive="False" keep-alive-interval="0"/>
    <cache id="demoCache" client-cache-id="clientCache" client-cache-syncmode="optimistic" skip-client-cache-if-unavailable="True" reconnect-client-cache-interval="10" default-readthru-provider="" default-writethru-provider="" load-balance="False" enable-client-logs="False" log-level="error">
      <server name="10.2.0.5"/>
      <server name="10.2.0.6"/>
    </cache>
  </configuration>

Novamente, essas são apenas a lista inicial de servidores. Não é a lista final. Por quê? Porque, para um ambiente de alta disponibilidade, e se você adicionasse esse terceiro servidor em tempo de execução? Isso não está nesta lista, certo? Então, vamos dizer que foi o ponto oito (0.8), algo. Portanto, esta é apenas a lista inicial. Uma vez que o aplicativo conhece qualquer um deles, ele se conecta a isso. A primeira coisa que acontece com o aplicativo, uma vez que ele se conecta, ele recebe as informações de associação de cluster e também sempre que essa associação de cluster é alterada e você adiciona outro servidor e a associação de cluster atualizada é enviada ao cliente e tudo é mantido na memória. Está tudo escondido do seu aplicativo. É tudo administrado pelo NCache parte do cliente, mas é assim que o aplicativo sabe como se conectar ao seu cache.

Então, no caso de sessões, é só vir aqui. Então, nas sessões, o que você faz é primeiro adicionar 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=CFF5926ED6A53769" /></assemblies>
</compilation>
...

No caso de NCache você apenas... este assembly implementa o interface do provedor de estado da sessão que faz parte do ASP.NET framework e fazendo isso NCache torna-se um terceiro, um armazenamento personalizado. E assim, isso é apenas um copiar e colar e, em seguida, as alterações reais na tag de estado da sessão. Então, o que você faz aqui você garante que o modo seja personalizado.

...
<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>
...

Então, os modos são, há o In-Proc, o servidor de estado, o SQL e há o personalizado. Portanto, há quatro modos que você tem. Portanto, se o modo for personalizado, você também deseja certificar-se de que o tempo limite seja o que você deseja que o tempo limite da sessão seja e, em seguida, copie os detalhes do provedor. O que é, no caso de NCache é esta linha e a única coisa que eles têm que mudar é o nome do cache. Então, por exemplo, aqui o nome do cache já está alterado. Você faz essa mudança, isso é tudo. E, assim que você fizer essa alteração, o ASP.NET reiniciará seu processo de trabalho de qualquer maneira e você verá que cada sessão será salva como um objeto no cache e você verá imediatamente um grande aumento de desempenho. Porque agora você não os está salvando no SQL.

Então, a maneira mais rápida de se beneficiar de um cache distribuído como NCache é apenas, colocá-lo para sessões. Porque, para o cache de dados do objeto para aplicativos, há mais trabalho. Claro que você sabe, você quer fazer isso e é nisso que vou abordar, mas o primeiro caso de uso é a especificação ASP.NET.

Alguma pergunta sobre isso? Então, o que vimos, por exemplo, alguns de nossos clientes de ponta têm cerca de 50 a 100 servidores na camada de aplicativo. Para isso, digamos, manter uma proporção de 1 para 5 é o que costuma acontecer. Portanto, para uma configuração de 100 servidores, eles terão 20 servidores de cache. Mais de 50, são muito poucos, sabe, você realmente tem que ter muito tráfego para ter mais de 50 servidores em um ambiente com balanceamento de carga. A maioria dos clientes tem entre 4 e 12 servidores. E recomendamos ter uma proporção, como eu disse, de 4 para 1 ou 5 para 1, dependendo da natureza da aplicação. Às vezes, pode até ser mais de 5 para 1, mas quero dizer que isso é como o caso de uso médio. Portanto, se você tiver 5 para 1 e tiver 12 servidores na camada de aplicativo, terá uma camada de cache de três servidores. Então, não há muitas conexões, sim.

Teoricamente, sim. Se você continuar adicionando mais e mais servidores, terá muitos redundantes. Mas, os casos de uso de que estamos falando, não cai. O processamento de big data pode ter 50 ou 100 servidores, mas não há clientes nesse caso e um processamento de big data é apenas do servidor. Porque, tudo está rodando no próprio servidor. Mas, no caso de uma aplicação web ou aplicação de serviços web, o que chamamos de e-commerce, o modelo de negócios online. Quero dizer, isso é muito bonito. Eu acho que você pode supor que na maioria dos casos você terá menos de 20 servidores e uma porcentagem muito pequena de clientes terá mais de 20 e mais de 50 é muito pequeno.

Sim, definitivamente. Então, por exemplo, se eu viesse aqui eu só vou... se eu viesse aqui. não estou usando o Pacote NuGet aqui mas eu poderia vir aqui e ir no NuGet e eu poderia dizer aqui NCache, por exemplo, e você receberá um NCache sdk, NCache Serviços de sessão para empresas e profissionais e também há um código-fonte aberto, também há o NHibernate. Então, há um monte de NuGets. Então, um típico… para as sessões, você incluirá apenas este pacote NuGet de sessão. Para o cache de dados do aplicativo, basta incluir o SDK e isso incluirá tudo o que você precisa.

Visão geral do cache de dados do aplicativo (API)

então, cache de dados do aplicativo é algo onde você tem que programar. Então, você vê o cache como um banco de dados. Você se conecta ao cache. No caso de NCache temos esse método chamado Inicializar cache.

Conexão de cache

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

Buscando dados

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

Gravando dados

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

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

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

Você pode ter alguns outros métodos para outros caches e há um nome de cache no caso de NCache como falamos e isso lhe dá um identificador de cache.

Então, vamos a uma aplicação. Novamente, vamos entrar em... Este é um aplicativo de console simples. O que você faz é que, se você incluiu o pacote NuGet, tudo isso será feito para você. Você faria referência a alguns NCache montagens. Portanto, há apenas dois assemblies que você precisa fazer referência, NCache.Tempo de execução e NCache.Rede. NCache.Rede é a API pública real em caso de NCache. Em seguida, em seu aplicativo, você inclui o namespace. Então, você tem o NCache.Tempo de execução e NCache.Web.Caching como os namespaces.

Então, no início do aplicativo, você obtém o nome do cache do, digamos, App.config e, em seguida, inicializa o cache e obtém um identificador de cache. Então, aqui está o identificador de cache que você precisa usar em todos os lugares do aplicativo.

Agora, vamos entrar nesse identificador de cache. Então, você pode fazer cache.Adicionar, especifique a chave. Key é como eu disse, geralmente uma string. Objeto é o seu objeto real, seja lá o que for. É qualquer objeto .NET, NCache irá realmente serializá-lo e enviá-lo para o cluster. Então, tudo isso está acontecendo no lado do cliente, no servidor de aplicativos.

// Alachisoft (R) NCache Sample Code.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Web.Caching;
using System;
using System.Configuration;

namespace Alachisoft.NCache.Samples
{
    /// <summary>
    /// Class that provides the functionality of the sample
    /// </summary>
    public class BasicOperations
    {
        private static ICache _cache;

        /// <summary>
        /// Executing this method will perform all the operations of the sample
        /// </summary>
        public static void Run()
        {
            // Initialize cache
            InitializeCache();

            // Create a simple customer object
            Customer customer = CreateNewCustomer();
            string key = GetKey(customer);

            // Adding item synchronously
            AddObjectToCache(key, customer);

            // Get the object from cache
            customer = GetObjectFromCache(key);

            // Modify the object and update in cache
            UpdateObjectInCache(key, customer);

            // Remove the existing object from cache
            RemoveObjectFromCache(key);

            // Dispose the cache once done
            _cache.Dispose();
        }

        /// <summary>
        /// This method initializes the cache
        /// </summary>
        private static void InitializeCache()
        {
            string cache = ConfigurationManager.AppSettings["CacheID"];

            if (String.IsNullOrEmpty(cache))
            {
                Console.WriteLine("The CacheID cannot be null or empty.");
                return;
            }

            // Initialize an instance of the cache to begin performing operations:
            _cache = NCache.Web.Caching.NCache.InitializeCache(cache);

            // Print output on console
            Console.WriteLine(string.Format("\nCache '{0}' is initialized.", cache));
        }

        /// <summary>
        /// This method adds object in the cache using synchronous api
        /// </summary>
        /// <param name="key"> String key to be added in cache </param>
        /// <param name="customer"> Instance of Customer that will be added to cache </param>
        private static void AddObjectToCache(string key, Customer customer)
        {
            TimeSpan expirationInterval = new TimeSpan(0, 1, 0);

            Expiration expiration = new Expiration(ExpirationType.Absolute);
            expiration.ExpireAfter = expirationInterval;

            //Populating cache item
            CacheItem item = new CacheItem(customer);
            item.Expiration = expiration;

            // Adding cacheitem to cache with an absolute expiration of 1 minute
            _cache.Add(key, item);

            // Print output on console
            Console.WriteLine("\nObject is added to cache.");
        }

E, depois de ter feito isso, você também pode fazer _cache.Obter e obter esse mesmo objeto de volta. Então, se você visse isso em termos de API, aqui está cache.Obter, Obter, Contém, Adicionar, Inserir, Remover e todos os três possuem uma versão assíncrona, o que basicamente significa que o aplicativo não espera a atualização do cache, o controle volta imediatamente. Mas, a chave geralmente é uma string. Geralmente é algo assim. Você tem o nome do tipo. No caso de NCache depende. Se você usou esse recurso chamado cache do cliente. Então, eu vou pular para isso.

Cache do cliente (próximo ao cache)

Assim, por padrão, você assumirá que sempre que fizer um cache.Obter, você está realmente indo para a camada de cache. Mas, há uma coisa interessante que a maioria das pessoas não percebe, que é que, se você estiver usando um cache In-Proc, como objeto de cache ASP.NET e decidiu mudar para algo como NCache porque dissemos que melhorará seu desempenho e escalabilidade. Bem, é meio que melhorar a escalabilidade, mas de repente seu desempenho vai cair, temos muitos clientes que nos ligam e dizem, você sabe, meu aplicativo ficou mais lento desde que conectei NCache. Então, por que eu realmente preciso disso, você sabe. Não é realmente bom, é um-você sabe. Então, então temos que explicar a eles que quando você faz um cache In-Proc, não há serialização, não há comunicação entre processos entre a aplicação e o cache, seja na mesma caixa ou em uma caixa separada, geralmente é um caixa separada, certo. Então, se o objeto for mantido em seu heap em uma forma de objeto, é super rápido, certo. Basta ir e obter uma referência. Nada pode igualar esse desempenho. Mas, a razão pela qual você muda para um cache distribuído é porque esse modelo In-Proc tem muitas limitações. Não pode escalar. Você não pode adicionar mais e mais dados, é apenas um processo e se você tiver mais de um processo a duplicação não é sincronizada. Então, há muitos outros problemas, por isso você muda para um cache distribuído, mas perde esse benefício, certo. Então, o que fizemos foi criar uma coisa chamada cache de cliente que no lado Java é chamada de cache próximo e no lado .NET pelo tempo e o cache é o único que o possui.

Então, o que isso realmente faz, na verdade, cria um cache local In-Proc dentro do aplicativo. Então, ele mantém esse objeto em um formulário de objeto em seu heap. Assim, você obtém o mesmo desempenho ao qual está acostumado no cache In-Proc autônomo. A única diferença é que esse cache sabe que faz parte de um cache clusterizado. Portanto, o que quer que esteja mantendo em sua cópia local, ele tem um link para a camada de armazenamento em cache. Ele disse à camada de cache que, você sabe, eu tenho esse objeto, por favor, notifique-me se alguém alterar esse objeto. Então, se houver, digamos, se esse cliente tiver o item número um outro cliente e, claro, esse item número um também está nessa camada de cache. Outro cliente chega e atualiza esse item número um. A camada de cache sabe que esses caches de cliente têm o item número um, então, eles notificam isso por meio de eventos, você sabe. No caso de NCache são eventos bem rápidos. Estes não são eventos .NET, são comunicação em nível de soquete. Assim, o cache do cliente se atualiza imediatamente. Então, estamos falando de talvez um atraso de milissegundos.

Então, dessa forma, você fica confiante de que, o que quer que esteja recebendo, está tudo ou na maioria das vezes correto. Há tecnicamente uma pequena probabilidade de que talvez seja uma cópia mais antiga. No caso de NCache, se você estiver muito preocupado com isso, poderá usar o que chamamos de modo de sincronização pessimista, onde toda vez que você busca algo, sabe, NCache verifica internamente a camada de cache para ver se ela tem uma cópia mais recente. Caso contrário, ele os fornece a partir dos dados do cache do cliente, caso contrário, ele os obtém da camada de cache. Mas, você não precisa disso para a maioria dos casos. Na maioria dos casos, você está bem em arriscar tanto. Portanto, isso oferece o aumento de desempenho do cache In-Proc. Mas, novamente, seu aplicativo não sabe que tudo isso está acontecendo.

No caso de NCache seu aplicativo sabe. O aplicativo pensa que está apenas conversando com a camada de cache. Há apenas um cache com o qual ele está falando. Chama-se meu cache ou algo assim. É o cache de demonstração e, o cache de demonstração pode ter um cache de cliente conectado através de configuração em caso de NCache. Alguma pergunta sobre isso?

API JCache (JSR 107)

Então, quero dizer, é assim que um cache típico se parece. É muito fácil fazer essa programação. O que está acontecendo agora no lado do Java, novamente continuo elogiando-os porque eles são muito mais avançados nisso. Eles têm uma API padrão inteira chamada JCache. Então, a API JCache é um recurso muito... tem todos os recursos que acabei de falar ou estou falando. Portanto, JCache é um padrão que todo cache Java deve implementar se quiser ser compatível com a indústria.

API IDistributedCache

No lado .NET ainda não existe isso. Há um objeto de cache ASP.NET que até recentemente não era conectável. Portanto, se você programar para o cache ASP.NET, não poderá conectar NCache no lugar dele. Portanto, você não pode conectar um cache de terceiros. É apenas um cache autônomo. No .NET 4.0, eles iniciaram um cache .NET que nunca funcionou. Agora em ASP.NET core eles têm um iDistributedCache interface. O que é novamente, um método de entrada muito básico.

Assim, o problema com a API padrão seria que você não poderá aproveitar todos os recursos que um bom cache deve oferecer. Você está realmente limitado à entrada básica de obtenção. Mas, novamente, a maioria de nossos clientes encapsula a camada de cache de qualquer maneira. Então, mesmo que eles estejam fazendo todo o NCache chamadas, o aplicativo inteiro não é exposto a ele. Então, de qualquer forma, aqui está a aparência da API.

Recursos de cache de dados do aplicativo

Agora, vamos entrar em alguns dos recursos que são importantes. Então, a maioria deles... vá em frente. Apenas uma pergunta simples. Existe diferença entre inserir e adicionar? Sim, inserir significa adicionar ou atualizar. Se os dados já existirem, atualize-os, se não existirem, adicione-os. A adição falhará se os dados já existirem. E, novamente, essa é uma API de cache ASP.NET à qual meio que nos apegamos, porque queremos estar o mais próximo possível do padrão no momento. Não, não é. Quero dizer, nós o mantivemos. O objeto de cache ASP.NET agora desapareceu porque agora, como eu disse, no ASP..NET Core não está mais lá, o ASP.NET ainda o tem, mas o ASP.NET Core não faz.

Expirações absolutas

Então, a primeira coisa que você tem que ter em mente é manter o cache fresco que falamos, né. Como você faz essa técnica número um é Expirations. Expirations se parece com isso, vamos voltar a isso. Então, vamos dizer que, eu tenho... Vocês podem ver isso? Você pode ver isso? OK. Digamos que eu tenha uma chave e um valor ou algum objeto. Quero adicioná-lo ao cache e especificarei uma expiração de 1 minuto. Então, isso é chamado de expiração absoluta.

public static void AddObjectToCache(string key, Customer customer)
    {
        DateTime expirationInterval = new DateTime();
        expirationInterval.AddMinutes(1);
        //Adding item with an absolute expiration of 1 minute
        _cache.Add(key, customer, expirationInterval, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Console.WriteLine("\nObject is added to cache");
    }

A expiração absoluta significa que após 1 minuto expirar isso não importa o quê. Isso significa que estou dizendo ao cache, eu realmente não me sinto confortável em cachear isso por mais de um minuto. Porque, estou fazendo um palpite de que é seguro manter isso no cache por um minuto.

Expirações deslizantes

A expiração deslizante, por outro lado, tem um propósito totalmente diferente. É para limpeza de coisas como sessões. Não tem nada a ver com sincronização ou manter o cache atualizado. Portanto, a expressão absoluta é algo que quase todos os caches têm. Na verdade, mesmo o ASP.NET Core IDistributed Cache Interface tem a expressão absoluta.

Sincronizar Cache com Banco de Dados

Mas, o que há de errado com a expressão ser a única maneira de fazer cache ou manter o cache atualizado? É que você está supondo que esses dados não vão mudar. E se isso acontecer? E se existem outras aplicações, existem outros scripts, que estão modificando os dados que em qualquer Enterprise, geralmente há mais de um local de onde os dados estão sendo atualizados. Portanto, se você não puder prever com que frequência os dados serão atualizados, as expressões são apenas um ponto de partida. Você tem que ir para a próxima etapa, que é sincronizar o cache com o banco de dados. Então, você basicamente, ao sincronizar o cache com o banco de dados no caso de NCache usamos esse recurso que faz parte do ADO.NET .NET chamado dependência SQL.

Dependência SQL essencialmente, deixe-me mostrar como isso se parece. Então, no caso de uma dependência SQL estou fazendo esse mesmo cache.Add, né. Eu vou ter a chave e em vez de ter o valor eu vou ter um item de cache que é nossa própria estrutura dentro da qual colocamos o objeto real e agora temos isso e então especificamos essa coisa chamada dependência SQL, dependência do servidor SQL que é esta variável que essencialmente cria a 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);
    }

Este código está sendo executado na caixa do cliente, bem aqui.

Ele fala com o servidor de cache. Ele diz ao servidor de cache para usar o recurso de dependência ADO.NET SQL para se conectar ao meu banco de dados. Então, ele realmente me dá uma string de conexão para o banco de dados. Então, agora o aplicativo está dizendo ao cache, aqui está meu banco de dados para este item em cache, aqui está a instrução SQL que representa os dados correspondentes no banco de dados.

Integração do Entity Framework / Entity Framework

Boa pergunta. No caso do Entity Framework a implementação que temos para o Entity Framework nós implementamos isso dentro. Nós mesmo com o Entity Framework existem duas maneiras de usar um cache. Ou você, no caso do EF Core agora a nova arquitetura permite que o cache de terceiros se conecte, mas até o EF6, não havia como conectar um cache. Então, você teria que fazer essas chamadas de API de qualquer maneira. Então, digamos que você tenha uma coleção de entidades de volta e, enquanto as armazena em cache, pode especificar a dependência SQL. Você entendeu o que eu quis dizer?

No caso de NCache você está dizendo NCache aqui está minha instrução SQL. NCache usaremos o ADO .NET para conectar ao seu banco de dados e usaremos o recurso de dependência do ADO.NET SQL para monitorar esse conjunto de dados. Então, NCache está dizendo ao servidor SQL, por favor, notifique-me se este conjunto de dados for alterado. Em seguida, o SQL Server envia uma notificação de banco de dados para NCache Porque NCache não é um cliente do banco de dados e então NCache agora sabe que esses dados foram alterados no banco de dados. Então, mesmo que você tenha EF, é meio que contornando isso e agora que NCache sabe que esses dados foram alterados NCache tem duas opções. Um pode remover esse item do cache e quando você removê-lo, você sabe, da próxima vez que alguém precisar dele, eles não o encontrarão no cache, então eles terão que buscá-lo no banco de dados. Então, de certa forma você está tornando-o fresco ou NCache pode recarregar esses dados do próprio banco de dados para você e isso não é possível a menos que você use outro recurso chamado read-through, eu chegarei a isso.

Portanto, a dependência SQL basicamente garante que, se você não puder prever quando os dados podem mudar, basta dizer NCache ou seu cache, por favor, monitore o banco de dados para mim.

A dependência SQL tem uma limitação de que você não pode ter junções nelas. Então, é uma coisa de mesa única. Existem outras maneiras de monitorar. Por exemplo, em caso de NCache há um recurso chamado Dependência personalizada, que é o seu código. NCache chama seu código e diz: vá e monitore sua fonte de dados e veja se os dados foram alterados. Então, isso é como uma votação. Então, NCache irá pesquisar sua dependência personalizada e, em seguida, pode ser uma estrutura complexa.

Sim, exatamente. Na verdade, quando você faz a dependência SQL o cache não está conversando com o banco de dados com tanta frequência, porque ele só... Então, o banco de dados é aquele que inicia a comunicação porque tem um evento. É uma arquitetura orientada a eventos. Assim, o banco de dados envia um evento sempre que os dados são alterados.

Na verdade, o servidor SQL tem esse recurso onde ele monitora o conjunto de dados e, em seguida, dispara notificações de banco de dados para os clientes. Então, NCache torna-se um cliente de banco de dados.

Portanto, uma opção era remover esse item do cache. O outro é apenas recarregá-lo. Bem, recarregar significa que o NCache tem que ter um jeito de saber como ir buscar esses dados e isso significa que existe esse recurso chamado read-through que é o seu código que você escreve e registra no servidor de cache, o cluster de cache. Mostrarei rapidamente como é esse código.

Cache de leitura

Não, na verdade é apenas o seu código personalizado. Então, até você pode fazer as chamadas ORM dentro desse código também. Então, todo esse código se parece com isso. Então, há uma interface IReadThruProvider, bem aqui.

...
// 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;
}
...

Portanto, há a interface IReadThruProvider. Tem três métodos. Há um Init que é chamado apenas quando o cache é iniciado. Portanto, ele deve se conectar à sua fonte de dados. Há um descarte que está no final e há uma carga. Então, load lhe dá uma chave e você deve devolver um item de cache.

Portanto, com base nessa chave, seu código precisa saber para onde ir, pois já está conectado à sua fonte de dados. Então, se você usa ORM, se você faz chamadas EF chamadas NHibernate, chamadas ADO.NET, esse é todo o seu código e então você carrega isso, digamos, você carrega esse objeto do banco de dados e você coloque-o e você coloca expirações ou quaisquer outros metadados que você queira com ele e você o passa de volta NCache. NCache o armazenará em cache, antes de devolvê-lo ao aplicativo.

Então, todo o propósito da leitura... deixe-me chegar a esta leitura em si. A leitura é uma maneira de o cache poder carregar dados do seu banco de dados. Então, na verdade, você está movendo parte do seu código de persistência para a camada de armazenamento em cache. E, se você tiver vários aplicativos que desejam compartilhar um cache, é perfeito ter um mecanismo de leitura e gravação. Porque você está consolidando, você está fazendo os aplicativos, meio que menos código, sabe. Assim, eles terão menos código porque cada vez mais código de persistência está indo para a camada de cache. Esse é um benefício. Você sabe, encapsulamento e consolidação.

O segundo benefício da leitura é o que acabamos de falar sobre recarregar. Assim, o recarregamento acontece em dois casos. Um na sincronização do banco de dados, o outro na expiração. A expiração também é um ótimo caso se você tem um aplicativo de tráfego muito alto que, digamos, você tem algum tipo de tabela de pesquisa ou tabela de preços que muda e você tem milhares de solicitações chegando a isso, se você não tiver o recarregue o recurso, então, quando os dados expirarem, milhares dessas solicitações irão e atingirão o banco de dados. E todos eles carregarão o mesmo objeto no cache. O que é finalmente muito tráfego para o banco de dados. Você multiplica isso por milhares de itens que você pode ter seu banco de dados verá muito tráfego desnecessário.

Na verdade, um de nossos clientes é um cliente de E-Commerce realmente sofisticado no ramo de flores nos EUA, teve esse problema. Então, quando eles implementaram o recurso de recarregamento, de repente, todo o problema desapareceu porque agora esse item nunca é removido do cache. Assim, as cópias antigas são mantidas até certo ponto e a nova cópia é atualizada em cima dela. Assim, o aplicativo nunca precisa ir para o banco de dados. Então, porque mesmo na exploração ele apenas atualiza a nova cópia. Então, é muito... Então, esses são os dois benefícios de leitura que você pode combinar com essa sincronização.

Cache Write-Through

O outro aspecto é o write-through, que funciona exatamente como o read-through, exceto que é para escrita e uma escrita pode ser adicionar, inserir ou excluir ou remover. Novamente, da mesma forma que você tem Init, você tem Dispose e agora você tem WriteToDataSource. Diz qual é a operação e também tem os dados e você vai e atualiza o banco de dados. Portanto, write-through significa que você atualiza o cache, o cache atualiza o banco de dados.

Então, qual é o benefício da escrita? Bem, um benefício é o mesmo que a leitura. Você consolida toda a persistência. Em segundo lugar, o benefício é o write-behind. Porque as atualizações do banco de dados não são tão rápidas quanto, você sabe, e se você confia que a atualização do banco de dados será bem-sucedida, apenas atualize o cache e deixe o cache atualizar o banco de dados de forma assíncrona. Claro que você pode ser notificado se algo falhar, mas você pode seguir em frente e fazer outras coisas e isso também melhora o desempenho de atualização do seu aplicativo. Portanto, agora você não precisa esperar que as atualizações do banco de dados sejam concluídas porque elas estão todas enfileiradas. Então, essa é a parte write-behind. E a fila write-behind é novamente replicada para mais de um servidor. Portanto, se algum servidor cair, nenhuma de suas operações será perdida, em caso de NCache.

Mas esse é o seu código. Quero dizer NCache chama de seu. Então, tudo isso é o seu código. Então, NCache liga para você e você descobre o que a escrita significa ou o que a leitura significa.

Portanto, leitura e gravação são outro recurso muito poderoso que você pode combinar com expiração e sincronização. Portanto, você precisa garantir que o cache permaneça atualizado e, em seguida, garantir que você use a leitura e a gravação. Agora que você começa a fazer isso, pode armazenar em cache muitos dados. E agora esse cache está começando a se parecer com o banco de dados. Isso significa que você não pode realmente obter, você sabe, a chave não é suficiente agora. Você precisa ser capaz de fazer a pesquisa. Você precisa ser capaz de buscar as coisas de uma forma mais inteligente. Então, é aí que você deve poder fazer consultas do tipo SQL no cache. Por exemplo, algo como clientes selecionados, em que cliente ponto Cidade é igual a Londres. Ele fornece uma coleção de todos os objetos do cliente que correspondem a esse critério. E, o cache indexa esses objetos com base, digamos, no atributo city. Então, é assim que ele permite que você pesquise.

Então, se você não conseguir fazer isso, seu aplicativo se tornará mais complexo porque você só poderá pesquisar coisas em chaves e, sabe, você está acostumado a fazer muitas outras coisas com o banco de dados que você não pode fazer com o cache.

Não há junções em um cache, mas você pode fazer agrupamentos. E, isso serve para esse propósito que você pode obter dados e, em seguida, agrupá-los e, em seguida, com base nesses grupos, você pode me dizer tudo o que pertence a esses grupos, subgrupos, tags, tags de nome. Portanto, há outras coisas que você pode fazer para agrupar coisas logicamente e os próprios dados que você está armazenando em cache podem vir por meio de junções. É só que o cache não pode ser... o cache não é motor de busca base. Então, se você tiver dados de junção, basta agrupá-los.

Dependências de cache

Então, há um recurso e, novamente, porque há muito disso que eu realmente não posso cobrir neste momento. Então, há um recurso chamado dependência de cache que vem do objeto de cache ASP.NET a propósito, NCache também implementou o que permite … Você diz ao cache que este item depende deste item. Se este item for atualizado ou removido, este será removido automaticamente. Então, ao criar esses relacionamentos, você pode ter esse um-para-muitos, digamos, se você tivesse um relacionamento um-para-muitos, onde o lado muitos não pode existir sem um lado. Digamos que seja um cliente e um pedido. Portanto, se você remover o cliente, também deseja remover o pedido. Então, você pode deixar o cache lidar com isso para você. Da mesma forma, quando você armazena em cache, digamos, você tem uma coleção de objetos, você pode armazenar em cache a coleção inteira como um objeto ou pode dividi-los em um único objeto. Se você dividi-los, você deseja fazer as dependências de cache. Portanto, se qualquer objeto for removido, essa coleção não será mais válida.

Sim, então, esse é todo um tópico sobre o qual eu tenho uma palestra, que você pode vir ao nosso site. Deixe-me apenas mostrar-lhe rapidamente. Então, há toda uma conversa sobre isso. Eu acho que é Manipulando Dados Relacionais em um Cache. Então, isso passa por todo o um-para-muitos, um-para-um, muitos-para-muitos, que passa por coleções que todas essas coisas que você acabou de falar. Basta ir e dar uma olhada nisso. Eu só vou passar rapidamente porque não temos tempo de sobra.

Então, eu meio que tentei explicar por que você deve usar um cache e como usá-lo e maximizar o benefício por meio dele. vou pular o compartilhamento de dados em tempo de execução parte, acho que cobri o suficiente. Você pode ir ao nosso site e ler mais sobre isso. Falei sobre o cache do cliente, falei sobre a alta disponibilidade por meio de particionamento e tudo mais.

Replicação WAN de Cache Distribuído

Há também vários datacenters. Você sabe, você espera que seu banco de dados seja capaz de lidar com vários datacenters, então, por que não o cache, você sabe. Então novamente, NCache fornece esse recurso. No lado Java você tem caches que fazem isso. No lado .NET NCache é o único. Assim, você pode ter um datacenter ativo-passivo ou ativo-ativo e os caches são sincronizados. Novamente, você não pode ter um cluster abrangendo a WAN, porque o desempenho simplesmente morre. Você precisa fazer uma replicação ou sincronização assíncrona na WAN porque quando você tem dois datacenters, eles podem não estar no mesmo local.

Um dos nossos clientes é a Ryanair, que é uma grande companhia aérea aqui e eles têm um datacenter em Dublin, Londres e Frankfurt. Então, eles precisam ter certeza de que podem sincronizar. No caso de NCache nos tambem temos Replicação de WAN. Há também um conceito de sessão de vários datacenters em que a sessão pode ser movida de um datacenter para outro. Mas, de qualquer forma, seu cache deve ser capaz de suportar vários datacenters. Então, certifique-se de olhar para isso.

NCache vs Redis

A maioria do pessoal do .NET conhece Redis. NCache, desculpe, a Microsoft os selecionou como sua escolha para o Azure, embora Redis vem de um fundo Linux. Acho que a principal razão pela qual a Microsoft os escolheu é porque eles queriam ter vários idiomas. Então, Redis abrange muitos idiomas. NCache é bastante focado em .NET. Também temos API Java, mas NCache em si é focado em .NET. Eu quero fazer uma visão geral muito rápida dos dois apenas para que você possa ver o que isso significa e então você pode vir ao nosso site e, na verdade, há um tipo de comparação. Você pode fazer uma comparação de recursos aqui. E, então, você também pode baixar isso. Então, dê uma olhada nisso. É baseado na documentação deles e na nossa. Então, não é nada, mas... não há nada de errado nisso.

NCache também é de código aberto, assim como Redis. No caso de NCache você tem o … você pode vir ao nosso site e você pode download a Enterprise Edition ou o código aberto ou você também pode ir ao GitHub, onde está NCache? Bem aqui em GitHub e então você pode ver NCache aqui também.

Portanto, esta edição empresarial é totalmente compatível. No caso de Redis Microsoft portado Redis do Linux para o Windows. Então, alguém poderia pensar que a Microsoft estaria usando a porta no Azure, mas não está. Então, a porta que eles têm tem muitos problemas. Muitos clientes reclamaram conosco.

Então, se você usar Redis no Azure eles usam a versão Linux é estável, não há problema com isso, mas você perde todos os recursos que acabamos de falar. Se você quiser fazer um suporte local, NCache lhe dará o código aberto é totalmente gratuito, a empresa é algo que você obtém mais recursos do que paga pelo suporte também. Se você quiser no local com Redis, as únicas opções que você tem é ir com a versão Linux de Redis laboratórios. Eles também têm isso no docker. Portanto, você pode executá-lo tecnicamente no Windows, mas ainda no ambiente Linux para eles. O on-prem do Windows é da Microsoft, que como eu disse é instável e sem suporte.

No Azure Redis fornece um modelo de serviço de cache, NCache fornece um modelo de VM. O modelo de VM oferece muito mais controle. Todas essas coisas que acabamos de falar sobre leitura, escrita, carregador de cache, sincronização de banco de dados, você obtém todo esse controle e há apenas uma API de cliente.

Isso é apenas uma rápida visão geral dos dois. Eu queria tipo de menção. Basicamente, NCache é o cache mais antigo no espaço .NET. Temos toneladas e toneladas de clientes usando NCache. Também muitos deles estão no Reino Unido. Você sabe, o Reino Unido é nosso segundo maior mercado e se você tem um aplicativo .NET, espero que prefira que toda a pilha seja .NET. NCache dá a você aquela pilha .NET, Redis não faz.

Alguma pergunta antes de concluir esta palestra? Mas então você está expondo o particionamento por conta própria. Porque, em um banco de dados relacional, você tem que programar a aplicação de forma que os dados residam em um ou no outro. Quero dizer, todo o conceito de No SQL é que eles fazem o sharding para você, porque tudo é baseado na chave. Em um relacional, você tem muito mais complexidades e, até agora, nenhum dos bancos de dados relacionais conseguiu resolver o problema de escalabilidade. Eles têm se esforçado muito e melhoraram tremendamente o desempenho. Há muitas opções de memória, então, eles também têm bancos de dados na memória e fazem muitas tabelas e outras coisas na memória. Portanto, o desempenho melhorou bastante, mas o desempenho não é o problema aqui. Você sabe, o problema é a escalabilidade. Você pode lidar com essa carga e até agora eles não podem.

Portanto, a razão pela qual temos a indexação é para que você possa pesquisar esses atributos. Então, você pode fazer uma instrução SQL e pesquisar esses atributos do objeto em que você foi indexado.

Então, o que fazemos é que não permitimos que você faça uma pesquisa a menos que você tenha o índice criado. Então, se você fizer uma pesquisa NCache vai lançar uma exceção diz, este atributo não foi indexado. Então, de uma forma mais dolorosa, sim. Mas, o que dizemos aos nossos clientes é que, seja o que for que você esteja tentando pesquisar, você deve criar um índice. E, diferentemente de um banco de dados onde tudo é SQL, aqui nem tudo passa pelo SQL. Novamente, você está fazendo um monte de coisas apenas por meio da API e, em seguida, algumas coisas são feitas por meio do SQL.

Você quer dizer para o nome do cache? Há uma convenção de que a chave deve ter as informações de tipo nela e, em seguida, com base em certos, digamos, se for um objeto individual e o tipo e o valor da chave primária ou o nome do atributo da chave primária e o valor, esse é o coisa comum e então se você está salvando toda a coleção, digamos, você está salvando todos os outros pedidos para o cliente e então você pode querer buscá-lo com base no cliente, então a chave pode ser cliente, ID do cliente, meus pedidos ou algo assim assim, sabe. Portanto, as chaves precisam ser significativas com base em como você deseja buscar os dados.

Sim, todas essas são opções que você pode escolher. Se você assistir ao meu vídeo de manipulação de dados relacionais, eu passo por todas essas opções. E, novamente com o cache, digamos, você tem um relacionamento muitos-para-muitos no banco de dados. Não há muitos para muitos no nível do aplicativo. Na aplicação ou você se aproxima deste lado ou deste lado. É sempre um para muitos. Então, são coisas assim que de repente a perspectiva muda.

Você não está tentando recriar todo o banco de dados na memória. Você pode recapitular os benefícios de usar um cache distribuído? Você disse que era escalabilidade. Existem outros? Eu acho que o benefício mais importante é a escalabilidade. O benefício secundário é o desempenho e, novamente, para os casos de uso, para os casos de uso específicos do ASP.NET, as sessões, há um grande benefício. Porque as alternativas para um cache distribuído são todas muito lentas ou não escaláveis. Então, se você fizer um In-Proc, não é escalável. Porque, você tem que ir para o mesmo processo todas as vezes.

Também estou gravando isso e acho que o SDD Conf também está. Teremos essa palestra no YouTube e, se você vier ao nosso estande e nos deixar escaneá-lo, podemos enviar por e-mail o link da palestra e você poderá compartilhá-lo com seus colegas. Muito obrigado pessoal pela paciência.

DDS 2017 London

Dimensionamento de aplicativos .NET com cache distribuído

Visão geral

O que é escalabilidade?

Escalabilidade Linear vs. Escalabilidade Não Linear

Quais aplicativos precisam de escalabilidade?

O problema de escalabilidade

Implantação de Cache Distribuído (NCache)

Usos comuns do cache distribuído

Cache de dados do aplicativo

Cache específico do ASP.NET

Demonstração prática

Criar um cache clusterizado

Simule o estresse e monitore as estatísticas de cache

utilização NCache com sessões ASP.NET

Visão geral do cache de dados do aplicativo (API)

Cache do cliente (próximo ao cache)

API JCache (JSR 107)

API IDistributedCache

Recursos de cache de dados do aplicativo

Expirações absolutas

Expirações deslizantes

Sincronizar Cache com Banco de Dados

Integração do Entity Framework / Entity Framework

Cache de leitura

Cache Write-Through

Dependências de cache

Replicação WAN de Cache Distribuído

NCache vs Redis

O que fazer a seguir?

Contate-nos

DDS 2017 London

Dimensionamento de aplicativos .NET com cache distribuído

Visão geral

O que é escalabilidade?

Escalabilidade Linear vs. Escalabilidade Não Linear

Quais aplicativos precisam de escalabilidade?

O problema de escalabilidade

Implantação de Cache Distribuído (NCache)

Usos comuns do cache distribuído

Cache de dados do aplicativo

Cache específico do ASP.NET

Compartilhamento de dados de tempo de execução por meio de eventos

Demonstração prática

Criar um cache clusterizado

Simule o estresse e monitore as estatísticas de cache

utilização NCache com sessões ASP.NET

Visão geral do cache de dados do aplicativo (API)

Cache do cliente (próximo ao cache)

API JCache (JSR 107)

API IDistributedCache

Recursos de cache de dados do aplicativo

Expirações absolutas

Expirações deslizantes

Sincronizar Cache com Banco de Dados

Integração do Entity Framework / Entity Framework

Cache de leitura

Cache Write-Through

Dependências de cache

Replicação WAN de Cache Distribuído

NCache vs Redis

O que fazer a seguir?

Contate-nos