NCache Arquitetura

Show gravado
Por Ron Hussain e Zack Khan

O webinar de hoje será baseado em NCache Arquitetura. Agora, abordaremos uma visão geral do cache distribuído e como ele resolve seus gargalos no .NET e .NET Core. Analisaremos casos de uso comuns, bem como a arquitetura de cache distribuído e detalhes de clustering, bem como qualquer dúvida que você possa ter em relação não apenas a NCache, mas cache em geral. Agora, a qualquer momento durante este webinar, temos a opção de perguntas aqui na guia de perguntas do GoToWebinar, portanto, verifique sua conveniência na guia de perguntas. E, assim que você escrever uma consulta, poderei trazê-la à tona durante a apresentação para ser respondida por Ron ou por mim mesmo. Também temos um pouco de tempo no final desta sessão para podermos responder a quaisquer outras perguntas que surgirem, mas estamos ansiosos para nos divertirmos muito.

Então, sem mais delongas, vou passar a palavra para Ron e vamos começar. Muito bem, obrigado, Zack. Então, pessoal, como Zack acabou de mencionar, o tópico de hoje é NCache arquitetura. Neste webinar, abordarei detalhadamente como NCache clustering funciona, quais são as topologias mais comuns que você pode escolher e um dos principais benefícios do NCache em termos de casos de uso do seu aplicativo. Quais são esses casos de uso e como você pode aproveitar ao máximo NCache dentro de seus aplicativos de servidor?

Então, espero que todos possam ver minha tela. Se eu conseguir uma confirmação rápida sobre isso, começarei rapidamente. Sim, acho que estamos todos bem se você puder. Aí está, eu acho. Sim, parece bom. Perfeito. Ok, então vamos começar rapidamente com isso.

O problema de escalabilidade

Tudo bem, então vamos primeiro definir o que NCache é? E para isso, terei que ir em frente e definir o que é um problema de escalabilidade, e então como NCache é capaz de resolver esse problema de escalabilidade. Portanto, em uma arquitetura de servidor típica onde você tem aplicativos implantados, geralmente há mais de uma instância ou mais de um servidor, independentemente de esses aplicativos serem implantados. Portanto, é seguro dizer que sua camada de aplicação é algo muito escalonável.

Você pode adicionar quantos servidores em uma camada de aplicativo. Você pode construir um formulário da web, um formulário de aplicativo, onde vários servidores de aplicativos ou servidores da web estão hospedando o mesmo aplicativo, mas eles estão trabalhando em equipe e estão dividindo a carga da solicitação entre si. E, se você optar por uma arquitetura mais recente, até mesmo com arquitetura de microsserviços, terá a capacidade de dimensionar individualmente seus serviços de aplicativos, microsserviços que precisam de mais computação ou mais capacidade de tratamento de solicitações.

Portanto, a camada de aplicativos é muito escalonável. É linearmente escalável. À medida que você cresce, você consegue lidar com cada vez mais carga de solicitações. O problema entra em jogo quando você lida com o banco de dados, como um banco de dados relacional. Como todos esses aplicativos, independentemente do nível de escalabilidade, quão escaláveis ​​eles sejam, eles sempre teriam que se comunicar com um banco de dados back-end. E, quando eles se comunicam com um banco de dados back-end, geralmente é uma única fonte. E isso não é muito escalável. É muito bom para armazenamento; você pode ter muitos recursos de disco. Portanto, você pode obter benefícios de armazenamento com isso. Mas quando você tem uma enorme carga transacional em seus aplicativos, e isso se traduz em uma carga transacional de banco de dados, os bancos de dados tendem a ficar congestionados. E esse é o principal problema, você sabe, onde o aplicativo tem dificuldades com o tratamento de solicitações. Não é escalável e a experiência do usuário final também fica comprometida.

NoSQL databases resolvem de alguma forma esse problema. Você pode ter um banco de dados SQL, mas isso requer que seu aplicativo seja rearquitetado de forma que pare de usar um banco de dados relacional e comece a usar um banco de dados relacional. NoSQL database e esse é um grande projeto. Então, NoSQL nem sempre é uma solução para um problema de escalabilidade.

A solução: NCache Cache Distribuído

Então, o que devemos fazer agora quando temos isso? A solução é muito simples: você deve ter um cache distribuído na memória como em NCache. Em primeiro lugar, está na memória, portanto, o principal benefício que você obtém é que o desempenho do seu aplicativo aumentará. É super rápido em comparação com um banco de dados relacional. E o principal benefício é que é linearmente escalonável. Ao contrário de um servidor de banco de dados, que geralmente é uma fonte única. NCache pode residir em vários servidores. Ele permite que você crie um cluster de cache que pode ser executado em várias caixas. E, como você sabe, seus requisitos ou necessidades aumentam, onde você precisa ter mais capacidade de tratamento de solicitações que precisam ser tratadas na camada de seu aplicativo, você pode adicionar mais servidores em tempo de execução no cluster de cache.

A coisa legal sobre NCache é que você o utiliza além de um banco de dados relacional; ou um banco de dados back-end, não substitui suas fontes de dados convencionais. É algo que complementará as fontes de dados existentes de forma que seja capaz de aumentar o desempenho de seus aplicativos. É capaz de aumentar a capacidade de tratamento de solicitações para seus aplicativos. E, à medida que você cresce no aplicativo, você sempre pode aumentar o número de servidores no cluster de cache, porque esses servidores estão em um cluster, então eles trabalham em equipe. Eles são capazes de dividir a carga da solicitação entre si de forma que, como resultado, forneçam escalabilidade linear. Então, NCache é um modelo linearmente escalonável e muito fácil de usar. Vamos falar como funciona a arquitetura de implantação. Então, em um ambiente de produção tipicamente grande, é assim que NCache pareceria:

Você teria um monte de servidores. Podem ser serviços Windows ou Linux, projetados de tal forma que NCache fica entre seu aplicativo e o banco de dados. Por exemplo, você pode começar com dois ou três NCache servidores, e então você pode crescer para quatro ou cinco NCache servidores e diferentes tipos de aplicativos - por exemplo, seu ASP.NET ou ASP.NET Core aplicativos da web, seu .NET ou .NET Core serviços ou .NET/.NET Core aplicativos de servidor. Ou mesmo pode ser Java ou Node.js. Portanto, esses aplicativos também podem aproveitar as vantagens do cache distribuído.

NCache em si é escrito em .NET/.NET Core. Ele roda em Windows e também em caixas Linux. Da mesma forma, seus aplicativos poderiam estar em qualquer plataforma e funcionariam sem problemas. Normalmente, recomendamos que você tenha NCache em servidores de configuração dedicados, que hospedam apenas NCache, para que você tenha uma natureza dedicada de recursos para NCache. E seus servidores de aplicativos estarão em uma camada separada. Para que você também tenha recursos dedicados para seus aplicativos. Mas também há outra opção de implantação, onde para configurações menores você pode ter NCache sentados nas mesmas caixas, onde seus aplicativos também estão em execução. Então, essa é sempre uma possibilidade com NCache. Mas, conforme discutido, a opção recomendada é que você tenha uma camada de cache separada, conforme mostrado no diagrama. E então NCache fica entre seu aplicativo e o banco de dados. A ideia aqui é que você armazene em cache todos os dados que você usa com mais frequência em seus aplicativos. Podem ser dados de referência ou dados transacionais. Por "referência", quero dizer dados que exigem mais leitura e por "transacionais", quero dizer dados que exigem leitura e gravação intensivas. E, depois de saber quais dados armazenar em cache, você pode chamar esses dados de seu "conjunto de trabalho". Pela primeira vez, você pode recuperar esses dados do banco de dados e, em seguida, também pode adicioná-los dentro NCache e as chamadas subsequentes podem ser tratadas através NCache apenas, você economiza viagens caras ao banco de dados. Isso é o que normalmente chamamos de padrão "cache-aside", onde quaisquer alterações feitas também são propagadas para o cache e depois para o banco de dados. E, nenhum banco de dados existe no cache, você sempre o busca no banco de dados e o mantém dentro NCache mas você sempre verifica o cache primeiro. Então, se você encontrar dados dentro do cache, você não precisa ir ao banco de dados e retornar desse ponto.

Leitura/gravação

A abordagem alternativa é usar "leitura" ou "gravação", que é representada aqui por linhas pontilhadas. NCache tem um recurso que pode automatizar isso, onde oferece a opção "cache-through" e é denominado "read-through" para leituras e "write-through" para gravações. Isso funcionará de forma que você sempre use o cache como sua fonte principal e implemente um manipulador de leitura e gravação no cache e que se encarregará de atualizar as fontes de dados de back-end. Portanto, quaisquer que sejam as operações de leitura que você realizar, se os dados não existirem, eles irão perfeitamente para o seu banco de dados com base no seu provedor, os recuperarão para o seu aplicativo e também retornarão ao aplicativo e também os armazenarão dentro NCache. Para atualizações, ele atualizará o cache e também o banco de dados em uma abordagem sincronizada ou assíncrona, dependendo do modelo que você chamou no aplicativo.

Então, compartilharei mais detalhes sobre padrões de leitura, gravação e armazenamento em cache, mas apenas para fornecer uma imagem de implantação de alto nível, é assim que você veria NCache implantados em um formulário de servidor, onde vários aplicativos ou formulários de aplicativos, eles podem se conectar NCache e, então, podem aproveitar as vantagens de um cache distribuído, onde o acesso à memória melhora o desempenho das aplicações. E ter vários servidores na camada de cache pode fornecer escalabilidade linear. Espero que isso tenha ficado claro; por favor me avise se houver alguma dúvida. Bem, felizmente, neste momento, parece que não há nenhum, então sinta-se à vontade para continuar. Muito bom.

NCache Números de escalabilidade

Então, a seguir, falarei sobre NCachenúmeros de escalabilidade. Acabamos de mencionar isso NCache é capaz de resolver o problema de escalabilidade do seu aplicativo. Então, NCache em si é linearmente escalável. Então, como a camada de aplicação é escalável, você sabe, tendo um gargalo de banco de dados resolvido por meio de um modelo linearmente escalável, aqui estão alguns números que você pode tomar como referência. Esses foram nossos testes de benchmark que conduzimos em nosso ambiente de controle de qualidade, usamos servidores com muita CPU e RAM para que pudéssemos realmente esticá-los e usá-los em uma situação de alta carga. Começamos com um servidor e continuamos aumentando a carga de aplicativos com dois servidores. Assim que um conjunto de servidores atingiu o limite máximo de capacidade de CPU e RAM, foi aí que adicionamos outro servidor.

Essa é a regra geral; onde você pode continuar usando os servidores de cache existentes, comece com dois NCache servidores, e quando você vê que esses dois servidores estão no limite da capacidade de hardware, se sua CPU está no limite ou sua RAM está no limite - esse é o ponto em que você faz uma escolha que agora preciso expandir e eu precisa adicionar um terceiro servidor no cluster de cache. Isso é exatamente o que fizemos com um tamanho médio de objeto de 1 quilobyte, continuamos aumentando a carga de aplicativos e aumentando o número de servidores. Até que o conjunto determinado de servidores estivesse no limite. E estes não eram dados imediatos; eram dados de aplicativos da vida real, mas simulados em nosso laboratório de controle de qualidade. Assim, com dois servidores, com três, quatro, cinco, até cinco servidores, conseguimos lidar com 2 milhões de solicitações por segundo com tamanho médio de objeto de 1 quilobyte.

Portanto, foi uma combinação de leituras e gravações aplicadas consistentemente no cache. Assim, no geral, foi alcançado um rendimento de 2 milhões de solicitações por segundo. E, ao mesmo tempo, sem comprometer o desempenho. Portanto, a taxa de transferência não significa apenas muitas solicitações por segundo; mas a latência das solicitações individuais também deve ser mantida e deve ser super rápida. Um vídeo de demonstração disso, bem como um white paper, está publicado em nosso site (Veja aqui). E isso é algo que você também pode revisar.

Usos comuns do cache distribuído

Ok, vamos falar sobre alguns dos casos de uso comuns de NCache.

• Cache de dados do aplicativo

  O caso de uso número um é o armazenamento em cache de dados de aplicativos, chamamos isso Cache de dados do aplicativo. Agora, esses são os dados provenientes de um banco de dados back-end. Já estabelecemos que o banco de dados é lento em geral porque é baseado em disco; em comparação, a RAM é uma fonte mais rápida. A outra questão é que o banco de dados tende a ficar bloqueado com tráfego intenso. Se você tiver muita carga transacional e houver um único servidor, espera-se que ele não forneça o desempenho necessário no final do aplicativo. Portanto, faz muito sentido armazenar em cache os dados do aplicativo dentro de seus aplicativos usando NCache. É muito simples; você usa NCache APIs e você simplesmente chama cache. Você se conecta ao cache chamando APIs de inicialização de cache. Uma vez conectado ao cache, você pode chamar 'cache.Adicionar, cache.Atualizar, cache.Remover'ou'cache.Obter'para recuperar dados do cache. Então, vou mostrar alguns exemplos no final. Mas, a ideia aqui é que quaisquer dados que você pense que vai ler mais de uma vez, sejam dados de referência ou dados transacionais. Para dados de referência, NCache vai agregar muito valor porque não precisa voltar ao banco de dados para recuperar quaisquer alterações.

  

  Certo, os dados no cache poderão ser usados ​​por um longo período de tempo. E, enquanto você usa dados de NCache, você não precisa acessar o banco de dados de back-end. Isso melhora o desempenho do seu aplicativo. E oferece escalabilidade porque NCache é escalável em comparação.

  Portanto, é muito intuitivo armazenar em cache todos os seus dados de referência, mas também recomendamos que você armazene em cache alguns ou mesmo a maioria dos seus dados transacionais. Em nossa experiência, recomendamos armazená-los em cache para qualquer dado que você leia mais de uma vez, mesmo que seja algo que você leia duas ou três vezes. Porque mesmo que esteja sendo alterado no banco de dados, e depois dessa alteração, se você ler mais de uma vez - duas ou três vezes - faz muito sentido armazenar esses dados em cache, para que você não precise vá para o banco de dados back-end. E temos recursos integrados NCache o que também pode fornecer 100% de sincronização com o banco de dados. Isso é algo que você também pode sempre considerar.

  Ron, recebi uma pergunta rápida, principalmente:
  Sempre preciso acessar meu cache clusterizado pela rede? Estou com medo de que problemas de rede possam fazer com que meus aplicativos não funcionem. Existe alguma maneira de manter alguns dos meus dados localmente?

  Ok, normalmente, a implantação padrão é que recomendamos que você tenha NCache em caixas separadas e depois sua aplicação em caixas separadas, certo? Então, quando NCache é baseado no protocolo TCP, portanto é uma chamada de rede. Existe um recurso chamado "Client-Cache", que é um cache local que fica nas caixas do aplicativo. E, em alguns casos, se você realmente precisar de mais executores e não quiser ter nenhum tipo de latência causada pela rede, isso também pode ser feito "in-proc", o que significa que ficará dentro do seu processo de aplicação. Então, quando isso acontece, o subconjunto de dados é automaticamente trazido para dentro do cache do cliente. Então, isso salvará qualquer comunicação processo a processo. E também economizará qualquer comunicação de rede ou sobrecarga de rede. Então, temos um recurso; isso é algo que abordarei quando passarmos para nossas topologias. Então, compartilharei mais alguns detalhes, mas apenas para dar uma visão geral rápida, é assim que funciona o cache do cliente. É um cache que fica na mesma caixa onde estão seus aplicativos. E a ideia aqui é que não são necessárias viagens frequentes à rede se o cache do cliente estiver ativado. E isso funciona sem nenhuma alteração de código. Então, espero que isso responda à pergunta. Por favor, deixe-me saber se houver mais perguntas. Sim, parece bom. Rony, leve isso embora. Muito bom.

• ASP.NET e ASP.NET Core Cache

  O próximo caso de uso de NCache está em um aplicativo da web. Se houver, você sabe, alguns requisitos de armazenamento em cache dos dados do usuário, certo? E normalmente é ASP.NET ou ASP.NET Core estado da sessão. Agora, esses dados não pertencem ao banco de dados, porque são dados transitórios. São dados que um usuário construirá e permanecerão no escopo da aplicação enquanto o usuário estiver ativo. Em alguns casos, você pode mantê-los no banco de dados para fins históricos, mas na maioria dos casos, os dados pertencem a um usuário.

  Então, Microsoft ASP.NET ou ASP.NET Core sessão. Existem algumas opções que você pode usar no servidor de estado, você pode usar no processo, você pode usar um servidor de banco de dados, todas essas opções têm problemas. Por exemplo, in-proc é um ponto único de falha; você precisa usar o balanceamento de carga de sessão fixa. O ASP.NET State Server é novamente um ponto único de falha e, você sabe, não é escalonável. O banco de dados é uma opção, novamente não é um ponto único de falha porque você pode fazer backup dele, mas em alguns casos, pode ser um ponto único de falha, mas é lento e não escalável. Então, o que devemos fazer aqui? Novamente, considere usar NCache para ASP.NET e ASP.NET Core cache do estado da sessão. Funciona de forma que você conecte nosso provedor. É uma opção sem alteração de código, mas assim que você conecta NCache dentro de seus aplicativos, NCache torna-se seu armazenamento de sessão principal. E a ideia aqui é que será super rápido porque é baseado em RAM. É muito escalável porque existem vários servidores. E, dentro NCache, assim que progredirmos na apresentação e eu cobrirei as topologias, você entenderá que NCache possui backups, com a ajuda de replicações. E os dados da sessão são dados do usuário, certo? Portanto, são dados que você não gostaria de perder em nenhuma situação, porque uma vez perdidos esses dados, isso tem um impacto no usuário, isso tem um impacto nos negócios. Portanto, com a replicação, o backup dos dados também é feito.

  

  Então, se eu tiver que listar os benefícios que você obtém, e você sabe, antes de tudo, você vai melhorar o desempenho do seu aplicativo por causa do acesso à memória. Você tem vários servidores que suportam seus aplicativos para armazenamento em cache de sessão, por isso é muito escalonável. Além disso, possui recursos de alta disponibilidade e confiabilidade de dados integrados. Portanto, não há perda de dados da sessão ou tempo de inatividade do aplicativo caso algum NCache servidor cai. E você não precisa mais usar o balanceamento de carga de sessão fixa porque NCache é uma entidade compartilhada. A solicitação pode ir para qualquer servidor web; sempre será capaz de encontrar dados de NCache com base em nosso protocolo. Então, tudo isso sem nenhuma alteração de código também.

  Outro caso de uso aqui, você também pode agrupar seu estado de visualização se estiver usando formulários da web ASP.NET. É aí que também irá armazenar em cache o estado de visualização. O estado de visualização fica pesado; consome muita largura de banda. Ele se torna parte dos seus pacotes de solicitação e resposta e é sempre enviado de volta ao navegador. E nunca é realmente usado lá, mas é algo que fica armazenado no navegador, no lado do cliente. E quando você postar de volta, é aí que o estado de visualização é trazido de volta no lado do servidor. Então com NCache, permitimos que você armazene em cache o estado de visualização no lado do servidor, para que sua carga útil não tenha mais um estado de visualização pesado anexado a ela. Isso melhora o desempenho. Embora, você sabe, o estado de visualização seja algo que sempre é armazenado no navegador. Mas se você mantê-lo no lado do servidor, onde é necessário, você saberá melhorar o comportamento geral do aplicativo. Ele não consumirá mais sua largura de banda porque o pacote real de solicitação e resposta não possui mais um estado de visualização pesado anexado a ele. E também seremos muito seguros porque o estado de visualização é armazenado no lado do servidor, e então você pode configurar alguma criptografia e alguns recursos de segurança sobre ele. E esta também é uma opção sem alteração de código. Mas isso se aplica apenas a formulários web legados. Portanto, eu recomendo que você, se tiver um aplicativo de formulários da Web ASP.NET, considere também um estado de exibição de cache.

  E então temos ASP.NET e ASP.NET core cache de resposta. Portanto, páginas estáticas ou partes de páginas dentro de uma página que são estáticas, você deve considerar armazenar em cache essas saídas de página. E em ASP.NET core, temos uma opção de cache de resposta que você pode escolher, e essa também é uma opção sem alteração de código. Além disso, também temos ASP.NET e ASP.NET Core SignalR Backplane. Porque em um formulário da web, se você estiver usando o SignalR, você precisará de um backplane. E backplanes típicos, como um sistema de arquivos ou um banco de dados, que podem enfrentar todos os desafios de escalabilidade e desempenho que acabamos de discutir. Com NCache, será super rápido, escalonável e confiável, porque estamos usando um sistema de mensagens muito confiável nos bastidores. Então, esses são alguns dos casos de uso que você pode aproveitar no ASP.NET ou ASP.NET Core aplicações.

Antes de prosseguir, Zack; Acho que há uma pergunta postada. Sim. Então, a questão surgiu basicamente de dizer e DB por padrão. Então, no meio do seu -- eu queria esperar até você terminar, mas a questão basicamente é perguntar. E no caso, você poderia elaborar a questão, senhor?

Olá Ron, é NCache também adequado para fins de publicação de dados, com o requisito, onde o requisito é salvar dados no cache da memória com opções para sincronizar dados no banco de dados como processo em segundo plano? E pode NCache cuidar desse mecanismo de sincronização entre cache de memória e bancos de dados por padrão?

Sim, essa é uma pergunta muito boa. Para casos avançados, isso é algo que sempre pode ser um requisito. Funciona de duas maneiras. Uma é que seu aplicativo agora está usando dados provenientes de NCache, mas os dados existem no banco de dados. Portanto, essas são duas fontes diferentes que precisam estar sincronizadas tanto para leitura quanto para escrita. Agora, se o aplicativo que está conectado ao NCache e o banco de dados é o único aplicativo responsável por alterar os dados dentro NCache e banco de dados, agora recomendamos que você use leitura e gravação. E sim, isso pode ser feito de forma assíncrona ou sincronizada, dependendo de suas necessidades. Então, o que realmente acontecerá é que sempre que você tentar buscar alguns dados do NCache e ele não existe no cache e você deseja que ele seja armazenado em cache, você chamaria automaticamente a leitura e isso lerá o banco de dados de back-end com base no seu código. E da mesma forma, se os dados vierem de um banco de dados e, novamente, esses dados precisarem ser atualizados no banco de dados, assim que você atualizar os dados no cache, nesse caso, você fará uso do write-through. Agora o write-through também pode ser write-behind, o que significa que os dados devem ser atualizados dentro NCache e no banco de dados usando seu manipulador write-through. E se você quiser uma invocação assíncrona disso, nesse caso você pode usar write-behind, para que isso possa ser feito em segundo plano. Mas novamente, NCache e sua aplicação é responsável por isso, onde NCache está chamando seu código e seu aplicativo está invocando isso.

Outra situação pode ser que existam outros aplicativos que possam estar alterando dados diretamente no banco de dados e seu aplicativo não esteja ciente disso. Então, nesse caso, o que realmente vai acontecer é que você precisa usar nossos recursos de sincronização de banco de dados. Você deve criar uma dependência personalizada; você sabe, o SQL Server possui notificação em cadeia. Temos dependências de banco de dados. Portanto, existem muitos recursos de sincronização onde qualquer alteração no banco de dados é capturada por NCache automaticamente. E você pode usar novamente a leitura e recarregar os dados dentro NCache também. Então, para resumir, NCache você sabe, pode lidar com as duas situações: onde é o seu aplicativo que é a única entidade que muda alguma coisa dentro NCache e banco de dados, ou em uma situação em que o banco de dados possa ser alterado fora do escopo do aplicativo que está usando o cache.

Portanto, ambos os cenários estão cobertos, e NCache lhe dará uma opção de 100 sincronizações que você conhece para esses casos. Se você está falando sobre cache de memória, normalmente o cache de memória também é apresentado pelo ASP.NET, certo! Mas se você está se referindo NCache como cache de memória, então já respondi à pergunta. Então, por favor, deixe-me saber se houver mais perguntas, e podemos continuar a partir daí.

• Mensagens do Pub/Sub

  Parece bom. Acho que podemos seguir em frente. Claro. Tudo bem, a seguir abordarei as mensagens do Pub-Sub. Como você pode ver, NCache já é compartilhado entre aplicativos, certo. Portanto, é uma entidade que você pode usar para atender aos seus requisitos de dados. Você pode adicionar dados a ele; você pode recuperar dados dele. Você pode obter benefícios de desempenho e escalabilidade de NCache. Você pode estender este caso de uso usando NCache também como plataforma de mensagens. Então, NCache mensagens são muito poderosas dentro NCache. É um mecanismo assíncrono e orientado a eventos onde vários aplicativos podem direcionar requisitos de mensagens ou requisitos de coordenação de aplicativos entre si. Se você precisar que vários aplicativos se comuniquem entre si, construir comunicação será um desafio. Então, você teria que confiar em algo que é uma entidade centralizada, NCache é essa entidade. E com seu suporte a mensagens, é capaz de oferecer a opção em que um aplicativo pode adicionar dados ou mensagens a NCache, e essas mensagens podem ser propagadas para todos os assinantes do outro lado: os outros aplicativos que precisam, você sabe, dessas mensagens.

  

  Da mesma forma, também podem ser mensagens baseadas em dados. Por exemplo, quaisquer dados são adicionados, atualizados ou excluídos e você é notificado sobre isso. Podem ser algumas mensagens de aplicativo personalizadas ou mensagens baseadas em dados, de modo que abrangem ambas as áreas onde quaisquer dados estão sendo preenchidos dentro NCache e você deseja que outros aplicativos estejam cientes disso, você pode direcionar os requisitos de mensagens por meio disso. Ou podem ser mensagens personalizadas ou mensagens orientadas por aplicativos, em que um aplicativo precisa se comunicar com outro aplicativo. É novamente baseado no modelo escalonável na memória. Ele também possui opções de replicação confiáveis. É baseado na plataforma convencional de mensagens Pub-Sub onde temos um conceito de tópico, e temos um conceito de message broker, onde múltiplas aplicações estão conectadas a ele. Assim, você pode definir aplicativos de editor e assinante. Os aplicativos do editor publicam, você sabe, mensagens para NCache que são então transmitidos a todos esses assinantes. E então, os assinantes também podem enviar suas próprias mensagens. NCache atua como uma plataforma de comunicação entre essas diferentes aplicações.

• Pesquisa de texto completo (Lucene distribuído)

  Finalmente, temos outro caso de uso, que é a pesquisa de texto completo. Portanto, se você tiver um aplicativo e precisar direcionar quaisquer requisitos de pesquisa de texto completo do NCache, considere usar nossos recursos de pesquisa de texto completo baseados em Lucine.NET.

  Você sabe que normalmente a API Lucene é independente. Certo, pessoal, você pode estendê-lo em vários servidores. NCache oferece a capacidade de carregar índices dentro da memória também. Então, NCache usaria índices baseados em disco, mas permite que você, na verdade, estenda a capacidade de armazenamento e tratamento de solicitações tendo vários servidores. Portanto, embora seja baseado em disco, ainda será melhor do que uma única fonte no banco de dados. Pois, nos casos em que você tem muita carga transacional, cada servidor será responsável pelo seu próprio conjunto de solicitações de índices. Então, será muito escalonável; também será muito confiável. Por se tratar de armazenamento assistido, quando se trata de índices de cena, a própria persistência é um recurso com NCache. Quaisquer dados que você armazena dentro NCache também pode ser persistido no disco ou, com base em alguns provedores de banco de dados, também pode ser persistido em alguns bancos de dados. Mas Lucene é o único recurso onde NCache usa disco em comparação com RAM, porque a natureza do caso de uso é tal que requer que os dados sejam persistentes.

  

Espero que tenha sido simples. Então, esses foram alguns dos casos de uso. Novamente, nesses casos de uso, temos muitos recursos; qualquer tipo de aplicativo, qualquer requisito específico dentro de um aplicativo, pode ser totalmente tratado usando nossos recursos de cache de objeto e cache de sessão.

Só uma pergunta rápida, Ron.
Existe uma maneira de acessar meus dados no cache como faço no meu banco de dados MySQL? Quero poder executar consultas SQL nos dados do meu cache. Posso fazer isso?

Certo. NCache em primeiro lugar, suporta uma pesquisa SQL e consultas LINQ. Então, se você tiver a capacidade de escrever um aplicativo que possa simplesmente se conectar a NCachee, em seguida, execute pesquisas baseadas em critérios, de forma que essa seja a opção mais fácil que você pode utilizar, onde você escreve uma pesquisa baseada em critérios. Por exemplo, você pode selecionar todos os produtos onde preço do produto é maior que 10 e menor que 100. Ou você pode encontrar todos os produtos com base em uma categoria; você pode encontrar clientes com base em uma região. Portanto, você pode criar pesquisas baseadas em SQL ou pesquisas baseadas em LINQ e NCache forneceria os dados do cache. Então essa é uma opção.

A outra opção é termos uma integração com LINQ Pad. Então, se você deseja apenas visualizar dados sem ter que passar pelo desenvolvimento de um aplicativo, o LINQ Pad é uma maneira fácil de executar consultas LINQ e, em seguida, visualizar dados executando consultas LINQ.

E então, em nosso próximo lançamento, a terceira opção é fornecer uma ferramenta de análise de dados. Então daremos a você uma forma automatizada, uma ferramenta de monitoramento, que lhe dará a capacidade de monitorar seus dados que existem no cache. E isso lhe dará essas opções de pesquisa baseadas em critérios a partir de uma GUI, então isso é algo que está em desenvolvimento; os requisitos foram concluídos, o trabalho de desenvolvimento foi concluído. Acho que fará parte do nosso próximo lançamento.

Definitivamente ansioso por tudo isso. Perfeito. Sim. Muito bom. Acho que estamos bem por agora, Ron. Também deixarei algumas dessas perguntas para o final, porque temos algumas interessantes, mas sim, vamos continuar. Claro.

Cluster dinâmico de autocura

Então, a seguir irei abordar o cluster de cache dinâmico, você sabe, todos os detalhes sobre ele. NCache é baseado no protocolo de clustering de cache baseado em TCP IP. É o nosso próprio cluster de cache implementado. Não estamos usando nenhum cluster de terceiros ou do Windows para esse assunto. É um protocolo 100% proprietário. Está escrito em .NET e .NET Core, então, você sabe que é muito conveniente em termos de --- os soquetes TCP também são .NET e .NET Core baseado. É uma arquitetura 100% ponto a ponto, portanto, não há um único ponto de falha. Você pode adicionar ou remover servidores em tempo de execução. Você não precisa parar o cache ou os aplicativos clientes conectados a ele. Assim, dinamicamente você pode fazer alterações em um cluster de cache em execução e, NCache não lhe dará nenhum problema por isso. Conforme você adiciona um servidor, os clientes são notificados em tempo de execução, então eles sabem automaticamente que esse servidor não existe mais, você sabe, faz parte do cluster de cache agora, então eles começam a usar o servidor adicional, o cluster se ajusta automaticamente. Da mesma forma, depois que você remove um servidor, outros servidores detectam que esse servidor desapareceu definitivamente. Eles notificam os clientes e os clientes param de usar o servidor perdido. Há um suporte de failover de conexão, que também é construído no lado do cliente, portanto, qualquer queda do servidor garantirá que, você sabe, o cluster garantirá que os clientes estejam cientes disso e façam o failover da conexão e comecem a usar o sobrevivente servidores.

Assim, em qualquer caso, quaisquer alterações no cluster são propagadas para os clientes. Os clientes são inteligentes, estão sempre cientes do estado do cluster de cache. Portanto, isso garante que não haja tempo de inatividade ou perda de dados, pois também temos suporte de replicação integrado. Então, NCache está altamente disponível e, também, é muito confiável com a ajuda da replicação. Ele garante 100% de tempo de atividade no final do aplicativo, sem qualquer interrupção do aplicativo, você pode continuar usando NCache.

Topologias de cache

A seguir, falarei sobre as topologias de cache. Essa é a parte principal que eu queria cobrir. Temos quatro opções para escolher. A primeira opção é novamente para configurações menores. Eles determinam como você configuraria um cache.

Cache espelhado

Portanto, temos a opção de configurar um cache usando uma topologia de cache espelhado, e a forma como funciona é que você tem no máximo dois servidores. Um desses servidores atuaria como um servidor ativo, onde todos os clientes estarão conectados. O outro servidor atuaria como um servidor passivo, que funciona como backup, e o backup é feito por NCache. Esta topologia, uma vez configurada, segue automaticamente a arquitetura. Você não precisa, basicamente você sabe, definir que isso se torna ativo ou que isso se torna passivo, isso é feito por NCache automaticamente. Mas, uma vez feito isso, o que realmente acontecerá é que todos os aplicativos clientes se conectarão ao servidor ativo e é de lá que eles lerão e gravarão dados. Quaisquer dados que tivermos no servidor ativo serão copiados no servidor passivo por meio de uma opção de espelhamento assíncrono. Assim, o cliente atualiza o ativo, retorna, para que o custo de replicação não seja incorrido no final do aplicativo cliente. A aplicação cliente será super rápida. Por trás das cenas, NCache deve atualizar o backup. E o backup existe por um motivo importante: se o servidor um ficar inativo, o servidor de backup será atualizado automaticamente como um servidor ativo e os clientes farão failover de suas conexões e começarão a usar o servidor de backup anteriormente ativo recentemente. E, agora que o primeiro servidor volta, ele se juntará novamente como um nó de backup, não como um nó ativo, porque já temos um nó ativo no cluster de cache. E tudo isso é feito perfeitamente para seus aplicativos. Você não precisa fazer nenhuma intervenção quando um servidor é adicionado ou um servidor é perdido.

Essa topologia é muito boa tanto para leitura quanto para gravação. Portanto, é bom para referência, bom para dados transacionais, mas tem um problema de capacidade porque você tem apenas dois servidores no máximo e, desses dois servidores, apenas um servidor está ativo em um determinado momento. Então, para configurações menores, com dados confiáveis, sabe cache, essa pode ser uma das opções.

Cache replicado

Continuando, a segunda opção é um cache replicado. Isto é novamente para configurações menores. Isso funciona de forma que todos os servidores estejam ativos, como você pode ver o servidor 1 e o servidor 2, ambos estão ativos. Os clientes estão divididos entre servidores diferentes, portanto, se você tiver seis clientes, conforme mostrado no diagrama, alguns deles se conectarão ao servidor um e outros se conectarão ao servidor 2. Certo, esses três estão conectados ao servidor um e estes estão conectados ao servidor 2.

Isso é feito automaticamente; o balanceamento da conexão é algo que é construído dentro NCache. Todos os servidores estão ativos, mas cada servidor possui uma cópia do cache. Portanto, quaisquer dados que você tenha no servidor 1, uma cópia estará no servidor 2, e essa cópia será mantida com a ajuda de atualizações de sincronização. Portanto, quaisquer atualizações que você execute em um servidor, essas atualizações deverão ser aplicadas em outros servidores em uma chamada de sincronização e, com isso, queremos dizer que o cliente irá esperar até que toda a operação seja concluída. Se a operação falhar em qualquer servidor, toda a operação será revertida. E é assim que conseguimos uma cópia 100% sincronizada em todos os servidores. Agora, isso é muito bom em termos de confiabilidade, mas também se você tiver um caso de uso intensivo de leitura, porque você tem mais cópias de dados ou mais cópias de servidores diferentes, então, à medida que você tiver mais servidores, sua capacidade de leitura aumentará porque você tem mais servidores para atender solicitações. Mas, como você acabou de notar, temos uma atualização de sincronização, portanto, qualquer operação de gravação deve ser aplicada em todos os servidores. Portanto, é bom para configurações menores em termos de capacidade de gravação. Se você tiver três ou quatro servidores, será necessário aplicar a mesma operação três ou quatro vezes, o que pode impactar negativamente no aumento do desempenho. Portanto, esta topologia é mais recomendada para cenários de dados de referência, para configurações menores. É escalonável para leituras, não muito escalonável para gravações, mas é muito confiável. Traz alta disponibilidade e confiabilidade de dados, pois, se você perder algum servidor, por exemplo, o servidor 1 é perdido, não há perda de dados ou tempo de inatividade porque esses aplicativos farão failover e começarão a escolher o servidor sobrevivente e, eles terão uma cópia do cache Já disponível.

Cache Particionado e Cache de Réplica de Partição

A próxima opção é que você pode escolher, você sabe, configurar um cache usando cache particionado. Agora particionada e a réplica de partição são as topologias mais populares. O cache particionado permite distribuir dados entre os nós de servidor disponíveis. Por exemplo, se você tiver dois servidores e tiver alguns dados, metade dos dados iria para o servidor 1, metade dos dados iria para o servidor 2. A distribuição de dados também faz parte NCache. Não é algo que seus aplicativos fazem, é feito automaticamente pelos aplicativos em tempo de execução. Há um mapa de distribuição inteligente e um algoritmo de hash, que determina quais dados irão para qual servidor.

Então, com base nisso, seus aplicativos são os que vão distribuir os dados uniformemente entre todos os servidores do cluster de cache. Agora os dados são distribuídos uniformemente, portanto a carga da sua solicitação também será distribuída uniformemente. Portanto, isso lhe dará mais capacidade de leitura e gravação com base no número de servidores. Se você tiver dois servidores, terá dois servidores trabalhando em equipe. E, se você crescer de dois para três, terá mais servidores lidando com suas solicitações de leitura e gravação. Assim, você obtém mais escalabilidade para leituras e gravações. Portanto, de maneira linearmente escalável, você obtém mais escalabilidade se adicionar mais servidores. Ao adicionar mais servidores, você também agrupa os recursos de memória, porque os dados são distribuídos, portanto, você agrupa o armazenamento de todos os servidores. Portanto, se você tiver dois servidores, terá capacidade para dois servidores. Se você adicionar um terceiro ou quarto servidor, você aumentará sua capacidade, você sabe, em muitos servidores. Portanto, a capacidade geral é agrupada, de modo que você obtém um crescimento linear à medida que adiciona mais servidores ao cluster de cache.

Muito bom para leitura, muito bom para gravação, muito escalável para referência e também para dados transacionais. A única desvantagem dessa topologia é que ela não possui nenhum backup. Se você perder um servidor, perderá essa partição. Então, quando isso acontecer, você precisará encontrar uma maneira de construir esses dados a partir de um banco de dados back-end. Portanto, se o seu objetivo principal é alcançar alto desempenho, se for um aplicativo centrado no desempenho, e você puder voltar para um banco de dados, o que geralmente é o caso, você não estará confiando em NCache para alta disponibilidade e confiabilidade de dados, isso proporcionará o melhor desempenho em comparação com todas as outras topologias.

Mas se você precisa de alta disponibilidade, e você sabe, os requisitos de confiabilidade de dados também devem ser atendidos NCache, tenho uma topologia melhor, chamada Partição de cache de réplica. Agora, a arquitetura geral é exatamente como particionada com um aprimoramento de réplicas, onde cada servidor possui partição de dados, mas cada servidor mantém duas partições; uma partição de dados ativa, onde os clientes estão conectados e uma partição de backup de outro servidor. O servidor 1 está ativo, seu backup está em 2, o servidor 2 está ativo, seu backup está em 1. E você pode escolher opções de backup sincronizado ou assíncrono. Se você escolher partição de réplica com assíncrono, o cliente atualizará a partição ativa e retornará as operações concluídas no cliente e então, NCache atualizará a partição de backup nos bastidores. Se você escolher sincronizar, o aplicativo cliente atualizará o ativo e fará backup como uma operação transacional. De qualquer forma, você sabe, a sincronização é obviamente mais confiável, a assíncrona é mais rápida. Mas de qualquer forma, NCache é capaz de lidar com a confiabilidade dos dados de tal forma que, se algum servidor falhar, a topologia de backup será ativada e você não verá nenhuma perda de dados ou tempo de inatividade do aplicativo. Certo.

Então, deixe-me mostrar rapidamente esta topologia com 3 servidores. Assim, obtemos todos os benefícios de alto desempenho para leituras, alto desempenho para gravações, você sabe, escalabilidade linear tanto para leituras quanto para gravações. Além disso, obtemos benefícios de escalabilidade, alta disponibilidade e confiabilidade de dados. Se algum servidor falhar, não haverá perda de dados ou tempo de inatividade do aplicativo.

Demo

Espero que esteja claro. Deixe-me levá-lo ao nosso ambiente de demonstração agora e mostrar rapidamente como você pode construir essas topologias de cache e, em seguida, também mostrarei como testar rapidamente um cluster de cache. Mas, enquanto isso, entre em contato comigo se houver alguma dúvida. Bem, apenas um rápido lembrete de que tudo o que estamos mostrando também podemos fazer com você em sessões práticas e de suporte técnico em seus ambientes, para seus casos de uso específicos. Então, tudo o que discutimos aqui, mesmo após o webinar, ficaríamos felizes em poder nos reunir com você também sobre isso, para poder demonstrar como funcionaria para você.

No que diz respeito às perguntas, tenho uma que apareceu bem no final. Um deles é um dos seus favoritos.
Tem havido muita discussão sobre o uso do Hazelcast para cache de aplicativos. O que NCache desde que o Hazelcast não o faça?

OK. Em primeiro lugar, é mais um debate. NCache na verdade está escrito em .NET e .NET Core, então plataforma preferida para NCache é o Windows. O que há de bom em NCache é que ele roda em .NET, assim como, você sabe, em Windows, e também em Linux. Portanto, a plataforma e a compatibilidade suportam isso NCache oferece, não há outro produto que seja capaz de conseguir isso. Então, essa é a primeira parte, onde é a escolha preferida se você, você sabe, considera a plataforma que está planejando usar. A outra diferença é que eu encorajaria todo mundo a procurar, você sabe, nosso páginas de comparação, você encontrará material muito bom lá também. Mas, para resumir rapidamente isso, NCache o suporte ao cache de objetos tem muitos recursos que faltam completamente em outros produtos. Por exemplo, na pesquisa SQL, temos um conjunto elaborado de recursos disponíveis dentro NCache. Temos carregador de cache e atualizador de cache. Esses são recursos completamente exclusivos para NCache. Nosso manipulador de leitura e gravação com capacidade de executar .NET e .NET Core código no lado do servidor, isso é algo que é um recurso absolutamente único para NCache, e a lista continua, certo. Então, alguns dos recursos que você sabe, você pode personalizar no lado do servidor. Esses estão disponíveis apenas em NCache e então, do ponto de vista da aplicação, há muitos recursos que faltam em outros produtos. Então, eu encorajaria todos a verificar nossa página de comparações. Existem algumas comparações, comparações recurso por recurso publicadas, e que fornecerão informações mais detalhadas sobre isso.

Esta é definitivamente a nossa linha de questionamento favorita, seja um webinar ou mesmo uma solução tecnológica, poderia ser Hazlecast, poderia ser Scala, poderia ser Redis, mas muito obrigado, Ron. Sim, acho que estamos prontos para ir. Por favor continue. Claro.

Criar novo cache clusterizado

Então, deixe-me fazer uma rápida demonstração do produto criando um novo cache clusterizado. Vamos chamá-lo de cache de teste. Certo, deixe-me mudar essa parte aqui, apenas tenha paciência comigo. OK.

Então, acabamos de explicar quatro topologias de cache. Vou usar o cache de partição de réplica, porque é o mais recomendado com opção de replicação assíncrona. Vou manter todos esses padrões.

Siga em frente e mostrarei como é fácil configurar um cache usando ferramentas GUI. Este é nosso gerenciador web, mas você também pode conseguir tudo usando nossos cmdlets do PowerShell e também pode automatizar essa implantação, se isso for um requisito. Vou adicionar o servidor um, onde NCache está instalado. Em seguida, adicionarei o servidor 2. Então, minhas 2 caixas com NCache com tamanho de 2 shows vai ser, você sabe, configurado. Então, minha ideia aqui é criar um cluster de cache de 2 nós usando 2 GB de tamanho de cache em cada um. Então, total de quatro shows com 2 servidores onde NCache já está instalado. E então, usarei minha caixa para conectar-me a esse cluster de cache.

Parâmetros TCP. esta é a porta que você precisa configurar, depois de fazer isso. Mantenha-o padrão ou especifique qualquer porta onde o firewall não esteja impactando essa porta.

Se você precisar configurar criptografia e compactação, esta é a tela. Vou mantê-lo como está. Escolha o próximo. Despejos, se o seu cache ficar cheio, é algo que você pode escolher. Uma opção é que seu cache simplesmente não entreterá nenhuma operação de gravação. Isso lhe dará um erro, 'cache está cheio'. Outra opção é configurar o despejo e, com base nesses algoritmos, ele removerá alguns dos itens do cache em tempo de execução. Portanto, com base na prioridade, no uso, os itens usados ​​menos recentemente ou com frequência podem ser removidos e cinco por cento dos itens serão removidos do cache. Vou iniciar esse cache no final e iniciar automaticamente, para que toda vez que meu servidor for reinicializado ou NCache o servidor reinicia, ele é capaz de reiniciar os caches que estão parados.

Vou escolher o acabamento e pronto. É tão fácil configurar um cluster de cache. E daqui a pouco ele vai me mostrar outra view, onde esse cache será iniciado, e depois vou mostrar alguns detalhes de monitoramento e gerenciamento a partir daí. Temos alguns vídeos mais detalhados disponíveis sobre configurações de cache, então se houver, se houver alguma dúvida, me avise agora, ou podemos, você sabe, contar com esses vídeos também.

Posso selecionar e escolher o cluster de monitoramento, e isso abrirá outro painel, que me permitirá monitorar totalmente meu cache. Ele me mostra um cluster de cache totalmente conectado, contadores de taxa de transferência de solicitação, contadores de latência e, em seguida, adições, buscas e contadores de atualização também estão lá. Da mesma forma, ele me mostra o uso de CPU e memória e situações de cache cheio.

Também tenho dashboards para cliente, bem como uma visualização de relatório, onde vemos dashboards do lado do servidor e do lado do cliente. No momento não há nenhum aplicativo conectado a ele, mas existe uma maneira de simular alguma carga usando este botão de estresse de teste. Portanto, posso iniciar um carregamento fictício ou alguma atividade em meu cluster de cache chamando esse teste de estresse. Assim que eu fizer isso, você verá que um cliente está conectado e essa topologia exige que meus dados sejam distribuídos, certo. Portanto, alguns dados iriam para o servidor 1 e outros para o 2. Portanto, este cliente está usando ambos os servidores uniformemente. Como você pode ver, as solicitações estão chegando a ambos os servidores, o tamanho do cache está aumentando em ambos os servidores.

Temos partições ativas e de backup também exibidas em ambos os servidores. E se eu mostrar rapidamente os contadores de latência, é uma latência abaixo de milissegundos, até mesmo latência de microssegundos, no que diz respeito às minhas operações. E posso ver o painel do cliente mostrando essas estatísticas do lado do cliente e, da mesma forma, temos um relatório que mostra as estatísticas do lado do servidor.

Ron, tenho uma pergunta, na verdade recebemos algumas perguntas, então uma delas é:
Qual é a sua recomendação para despejo? E, se for pelo menos o despejo, espere até o próximo, se o despejo estiver desativado, podemos aumentar o tamanho do cache ou diminuí-lo?

Claro. Então, você sabe, o despejo é algo que precisa ser configurado com base no seu caso de uso, certo. Se os dados são algo que você pode permitir que sejam despejados, certo. O próprio despejo removerá alguns dados se o cache ficar cheio. A situação ideal é que você nunca precise fazer isso e seu cache esteja dentro da capacidade, certo. Assim, você fornece tamanho ou memória suficiente ao seu cache para que ele nunca fique cheio. Mas, nos casos em que isso acontece, você sabe, chega a um ponto em que fica cheio. Nesse caso, se seus dados forem algo que você sempre pode reconstruir a partir de um banco de dados back-end, é recomendável ativar as remoções. Por exemplo, para sessões ASP.NET, não recomendamos ativar as remoções, porque você estaria removendo alguns usuários para abrir espaço para os novos usuários, e todos os usuários têm seus dados importantes, certo. Portanto, são dados que você não gostaria de perder em nenhum cenário. Portanto, para esses cenários, recomendamos que você aumente o tamanho do cache. Planeje o tamanho do seu cache de forma que seja grande o suficiente e nos casos em que fique cheio NCache permite alterar o tamanho do cache em tempo de execução. Você pode editar isso corretamente e, com base nisso, aumentar e salvar essas configurações em um cache em execução. Portanto, é altamente aplicável e aumentará o tamanho do cache em tempo de execução.

Alguma outra dúvida? Parece que isso respondeu, e vou guardar alguns deles para o final, para que você possa completar sua demonstração. Claro. Então, voltando ao meu ambiente de demonstração, você pode adicionar clientes, por exemplo, posso adicionar minha caixa como cliente e esta é uma rápida visão geral de um aplicativo de exemplo que posso executar a partir da minha caixa. Por exemplo, isso também está disponível no GitHub, então se você pesquisar NCache no GitHub você veria alguns exemplos, e eu extraí um dos exemplos de lá. Então, o que você realmente precisa fazer dentro do seu aplicativo é incluir este pacote NuGet que é Alachisoft.NCache.SDK, e se você estiver interessado em cache de dados de aplicativos, esta é a amostra que você deve considerar. E, com base nisso, uma vez adicionado, você pode incluir alguns recursos dentro da aplicação.

Isso já incluirá algumas, você sabe, bibliotecas de NCache, como parte deste novo pacote NuGet. E então você inclui esta referência usando Alachisoft.NCache.Cliente. Adicione também Tempo de execução.Caching, certo, e com base nisso você pode definir um identificador de cache e, dentro dele, temos vários métodos. Por exemplo, deixe-me mostrar como inicializar o cache. Na verdade, vamos entrar nisso. Tenha paciencia comigo. Estou passando por um momento difícil. De qualquer forma, por algum motivo, não consigo entrar nisso, acho que há um problema com a própria caixa. Mas de qualquer forma, as APIs são bastante intuitivas. Deixe-me mostrar a você nosso PowerPoint. Este exemplo está realmente usando isso, não consigo demonstrar porque não consigo entrar no código. Não está me deixando.

Então, este é um identificador de cache e este é o trecho de código que eu queria mostrar, que o CacheManager.GetCache permitirá que você se conecte ao cache. Então você pode ligar cache.Obter para realmente obter quaisquer dados do cache. Da mesma forma, você pode ligar cache.Adicionar or cache.AddAsync para adicionar quaisquer registros no cache e inserir da mesma forma como no upsert onde ele adiciona, bem como atualiza dados no cache e da mesma forma, você pode chamar cache.Remover.

Então, é isso amostra está disponível para download e execução em seu cache. Tudo o que você precisa fazer é apontar para o cache no final do aplicativo. Existem várias configurações. Você pode especificar o nome do cache e do IP in-line ou pode contar com um client.ncconf, que este pacote NuGet inclui no projeto. Então, se eu mostrar rapidamente alguns recursos, você verá, muitos arquivos são realmente adicionados, e esse arquivo aqui é um arquivo que permite que você se conecte ao cache. Então, ele já consegue se conectar ao meu 'democache'. Se eu executá-lo, ele realizará alguma atividade no meu cache e iniciará as operações de cache.

Da mesma forma, eu tenho outro exemplo que vai dar, você sabe, mais algumas opções, por exemplo, havia uma pergunta sobre procurando dentro NCache, certo. Então, eu recomendo que você use este exemplo aqui. Isto é para pesquisa SQL. Ele é baixado novamente do GitHub e novamente está usando pesquisa, usando, tem dados de amostra e, em seguida, chama a pesquisa usando SQL. E tem vários recursos aqui, novamente na mesma linha, os exemplos são bastante intuitivos. Você pode inserir itens e então consultar usando tags de nome, você pode consultar, você sabe, consultar usando índices ou projeções definidas.

Infelizmente não posso entrar nestes métodos por causa das questões ambientais, mas novamente estes serviriam como um excelente ponto de referência para usar NCache de qualquer aplicativo que precise usar cache dentro do aplicativo ou que tenha um caso de uso de pesquisa dentro do aplicativo.

Cache de cliente

Houve outra pergunta sobre Cache de cliente, portanto, essa topologia também é uma opção sem alteração de código. Quaisquer dados armazenados em cache de um banco de dados dentro NCache, você poderá armazená-lo ainda mais em cache usando o cache do cliente. É uma cache em cima de outra cache. Funciona sem nenhuma alteração de código. É um cache sincronizado com cache clusterizado, portanto não há problemas de consistência de dados. A sincronização é feita por NCache. Quaisquer atualizações feitas em um cache do cliente são propagadas para o cache clusterizado como obrigatório e, em seguida, propagadas para outros caches do cliente, e no cache gerencia toda a sincronização. Para cenários de dados de referência, onde você não tem muitas gravações, esta é uma opção muito recomendada.

Replicação de WAN

Do mesmo modo, NCache também tem um Replicação de WAN. Temos topologias ativo-passivo e ativo-ativo. Assim, todos os dados do seu cache podem ser replicados de um data center para outro através do nosso bridge cache. O backup da ponte em si é feito em um servidor passivo ativo, então você tem um cache de origem e um cache de destino, replicação unidirecional ou migração de dados de leste para oeste de um datacenter para outro para cenários de DR ou para migração de leste para oeste, você sabe, ou para situações em que você precisa de dados de um aplicativo e precisa usá-los no aplicativo de destino. Assim, você pode transferir dados inteiros do cache de um data center para outro.

A outra opção é ativa-ativa. Neste caso, temos os dois sites ativos, então o site um está transferindo dados para o site dois e o site dois está transferindo dados para o site Um. Novamente, é uma opção sem alteração de código. É apenas uma configuração. Depois de configurar a ponte, você conecta dois caches e NCache assume o controle e inicia a replicação de dados entre esses caches.

E isso também se estende à topologia multiativo-ativo, portanto, não precisa ter apenas dois sites, podem ser três, quatro ou cinco sites onde todos os sites estão transferindo dados entre si. Então, NCachea capacidade de sincronizar dados de todos os sites de uma só vez. E, a propósito, isso é feito de forma assíncrona, para que o custo de replicação não seja novamente incorrido no lado do aplicativo ou no lado do usuário. Isso é feito no aplicativo. Você tem aplicativos clientes conectados aqui e aqui. Eles não veem nenhuma degradação de desempenho devido a essa replicação WAN. Isso é feito nos bastidores por NCache. Deixe-me saber se houver alguma dúvida. Vamos concluir a apresentação e o conjunto de recursos neste ponto. Zack, me avise se houver alguma dúvida.

Sim, temos alguns. E a todos, vocês sabem, agradeço sua paciência, então este também é um bom momento para fazer quaisquer outras perguntas, caso você tenha se perguntado durante a apresentação. Então, vamos começar com um.
Como você confirma se o seu cache está funcionando em um estado íntegro? Recebemos algum tipo de notificação, etc.? Por exemplo, como sabemos se há um problema?

Certo. Nós temos ferramentas de monitoramento e gerenciamento. Portanto, uma coisa pode ser inspecionar visualmente e ver a integridade do cluster. Você vê, o uso da CPU, o uso da RAM. Se você conhece sua linha de base, quantas solicitações seus aplicativos estão gerando e qual é a utilização típica de NCache com base nesses contadores, você pode inspecionar visualmente usando nossos painéis de monitoramento e gerenciamento. E então, temos alertas para qualquer situação, por exemplo, você inicia um cache, para um cache, um nó entra, sai, o tamanho do cache fica cheio ou o cluster entra em estado não saudável, como, cérebro dividido, temos alertas, que fazemos login nos logs de eventos do Windows. E você também pode configurar alertas por e-mail de NCache, e também pode gerar um e-mail para você. Então isso é uma coisa que vai ser um monitoramento proativo, algum alerta de NCache, Onde NCache alertaria e você pode tomar ações com base nisso. E então temos dados históricos capturados na forma de logs de contador perfmon, bem como logs de cache. Para aquelas situações em que você não sabia o que havia de errado e viu alguns problemas com NCache, podemos entrar e nos envolver, e podemos revisar NCache logs e faça uma avaliação da integridade do cache nesse caso. Portanto, há muitos de vocês que conhecem caminhos a esse respeito que podemos explorar.

Parece bom. Outra questão é:
Qual é a versão mais recente do .NET que NCache atualmente oferece suporte para clientes?

OK. Normalmente, tendemos a estar atualizados .NET framework versão, .NET Core. Atualmente, o .NET 6 é compatível, o que é um pré-requisito para NCache. Você precisa ter o .NET 6 como algo obrigatório em NCache servidores. Mas, seus aplicativos podem estar em qualquer, você sabe, .NET framework, acho que a partir de 3.5 4.0, 4.5, ou até 4.7, 4.8. Seus aplicativos podem estar em qualquer um dos .NET ou .NET Core estrutura. É apenas uma limitação do lado do servidor. E, assim que uma compatibilidade de estrutura mais recente for testada, por exemplo, para .NET 7, já a estaremos testando em nosso laboratório de controle de qualidade. Então, assim que tivermos, você sabe, isso assinado, nós iremos, você sabe, lançar um suporte oficial para isso também.

Maravilhoso. Outra questão é:
O que você consideraria ser a quantidade segura de caches clusterizados entre meus servidores de cache? Posso criar, digamos, 15 caches clusterizados entre meus servidores de cache?

OK. Em primeiro lugar, NCache não impõe nenhum limite de quantos caches você pode configurar. Na verdade, se você olhar meu ambiente de demonstração, tenho dois caches configurados. Assim, você pode criar quantos precisar. Porém, há uma recomendação técnica ou relacionada à capacidade que normalmente recomendamos em um ambiente de produção para não ir além de quatro a cinco caches. Porque cada cache é um cluster de cache separado. Na verdade, ele consumirá todos os recursos de armazenamento, clustering, comunicação e também haverá uma sobrecarga de gerenciamento de cluster. Portanto, à medida que você aumenta o número de caches, você está, na verdade, introduzindo esse problema de capacidade nesse ambiente ou dentro desse ambiente. Então, recomendamos mantê-lo, você sabe, entre quatro e cinco, se possível. Numa situação em que você precisa ter vários caches, você pode estender até 10. Mas, como eu disse, é novamente uma recomendação. Não há limite real que imponha isso. É uma recomendação de uso geral de nossa parte.

OK. Deixe-me acrescentar mais uma, pois sei que estamos no final da sessão e sei que as pessoas têm outras coisas na janela de encaixe.
lata NCache fornecer replicação de DR?

Sim. O recurso de replicação WAN que acabei de discutir, a última topologia, que cobre DR, recuperação de desastres. Os sites podem ser transmitidos com os dados do site ativo, portanto, você teria um backup completo do site de DR. Você só precisa ativar o final do aplicativo. Como todos os dados já foram salvos em backup, não há perda de dados na situação em que um data center fica completamente inoperante ou você mesmo precisa desativá-lo para manutenção.

Tudo bem. Acho que acertamos o máximo que pudemos. Senhoras e senhores, saibam que também estamos disponíveis fora destas sessões. Estamos muito felizes em trabalhar com você, lado a lado, quando se trata de analisar suas configurações existentes, caso você já seja usuário do NCache. Se você é novo em NCache, ficaremos felizes em preparar um teste e realizar sessões práticas para orientá-lo sobre como isso funcionaria em seus aplicativos integrados, mas acima de tudo, saiba que você pode entrar em contato a qualquer momento quando se trata de qualquer dúvida sobre NCache, ou mesmo usando o produto e se precisar de ajuda. Temos muitas novidades a caminho, lançamentos de novas versões também, então, você sabe, fique ligado e teremos mais desses webinars em breve.

Uma salva de palmas para Ron. Eu realmente agradeço por você reservar um tempo para uma sessão hoje e estou ansioso pela próxima. Obrigado a todos. Obrigado, Zack. Claro. Tudo bem, pessoal. Tenham todos um dia maravilhoso e esperamos vê-los em nosso próximo webinar. E apenas um aviso: após o término deste webinar, teremos uma gravação do webinar carregada em nosso site, assim que tudo estiver pronto e limpo. Então, se você não teve a chance de, você sabe, ter alguma dúvida respondida, se quiser revisitar algum dos pontos que levantamos, fique à vontade para voltar ao nosso site e conferir o webinar gravado.

Tudo bem então. Saudação a todos. Você tem um bom. Obrigado, pessoal. Bye Bye.

O que fazer a seguir?

• NCache Adicionar ao carrinho
• Baixar NCache
• Solicite uma demonstração AO VIVO personalizada