Escalando ASP.NET Core Apps com NCache
Webinar gravado
Por Ron Hussain e Zack Khan
ASP.NET é uma tecnologia muito popular para o desenvolvimento de aplicações web. Agora sua última versão ASP.NET Core está ganhando popularidade rapidamente com organizações ansiosas para migrar seus aplicativos da Web para ASP.NET Core. Mas, ASP.NET Core se depara com problemas de escalabilidade e desempenho quando colocado sob carga pesada do usuário. Isso acontece porque seu armazenamento de dados se torna um gargalo. No entanto, há uma maneira de contornar esse gargalo de desempenho e escalabilidade se você usar o cache distribuído. Saiba como você pode otimizar seu ASP.NET Core desempenho e escalabilidade para funcionar sob cargas de transação extremas.
Aqui está o que este webinar aborda:
- Visão geral do ASP.NET Core escalabilidade e gargalos de desempenho
- Como o cache distribuído resolve esses problemas
- Cache de dados de aplicativos por meio de ASP.NET Core Interface IDistributedCache e Direct NCache APIs
- ASP.NET Core Armazenamento de sessão com NCache
- ASP.NET Core Cache de resposta com NCache
- Alguns importantes NCache recursos de cache distribuído
No webinar de hoje, faremos uma visão geral do ASP.NET Core escalabilidade e gargalos de desempenho e como o cache distribuído resolve esses gargalos e outros problemas. Vamos falar sobre ASP.NET Core aplicativos, quais são seus gargalos de desempenho e escalabilidade e, em seguida, falaremos sobre como resolver esses gargalos de desempenho e escalabilidade com a ajuda de NCache sistema de cache distribuído.
NCache é um sistema de cache distribuído na memória para seu .NET e .NET Core formulários. É escrito em .NET e principalmente para .NET e .NET Core aplicativos, mas principalmente o foco de hoje será em torno de ASP.NET Core aplicativos da web e tenho alguns recursos de amostra disponíveis. Eu alinhei alguns aplicativos de exemplo também. Então, será um webinar prático onde compartilharei alguns detalhes de nível de recurso de diferentes casos de uso que você pode capturar e recursos que estão lá para ajudar a resolver esses casos de uso e também demonstrarei esses exemplos. Vamos começar.
Então, nossos primeiros slides são slides introdutórios sobre ASP.NET Core plataforma em geral. Tenho certeza que todo mundo sabe o que ASP.NET Core é. É a nova plataforma de aplicação web ASP. É limpo, leve e modular. É principalmente a arquitetura MVC, no que diz respeito à abordagem de aplicativos da Web. Você sabe, o popular front-end Angular, React é principalmente front-end baseado em JavaScript e, em seguida, arquitetura MVC para fazer o backup. É multiplataforma. Você pode executá-lo no Windows, Linux e qualquer outro sistema operacional, como o macOS. E, normalmente, é algo que também é muito compatível com aplicativos ASP.NET 4.0 herdados.
Se você tem um aplicativo ASP.NET MVC, agora você pode migrar dele e começar a usar o ASP.NET Core tecnologia para esse assunto, que é muito rápida, muito robusta e muito leve e arquitetura limpa, em geral.
O que é escalabilidade?
Primeira coisa que vamos falar sobre ASP.NET Core plataforma é que requer escalabilidade. Então, vamos definir o que é escalabilidade? Qualquer aplicativo que esteja sendo executado sob carga normal do usuário e por normalizado quero dizer que alguns usuários estão lá. Digamos que de 5 a 10 usuários estejam logados e estejam realizando determinadas transações, determinadas operações, solicitações de leitura e gravação. Normalmente, a ideia aqui é que seu aplicativo seja super-rápido sob baixa carga de usuário. Mas, assim que sua carga de aplicativos cresce e isso é algo que também é um requisito para os negócios, você precisa ter mais e mais usuários fazendo logon em seus aplicativos. É quando seus aplicativos tendem a ficar mais lentos. Pode haver desempenho lento sob cargas de pico.
Se seu aplicativo não for capaz de manter o mesmo desempenho que tinha com um número baixo de usuários e, quando tiver o número alto de usuários, conseguir manter o mesmo desempenho, esse aplicativo será categorizado como um aplicativo muito escalável. A arquitetura tem essa capacidade de escalar horizontalmente e ser capaz de lidar com o aumento da carga de seus usuários finais. Assim, alto desempenho sob cargas de pico é o que realmente define o fator de escalabilidade.
Aqui está um gráfico. Normalmente, a escalabilidade é alcançada em ASP.NET e ASP.NET Core plataforma por meio de vários servidores Web ou de aplicativos.
Você pode distribuir a carga do aplicativo. Você apenas implanta seu aplicativo em vários servidores da Web ou de aplicativos e, com base nisso, simplesmente distribui a carga de usuário do aplicativo nesses servidores e, à medida que adiciona mais servidores, obtém uma melhoria linear na capacidade de tratamento de solicitações. Mais servidores significam mais capacidade de tratamento de solicitações de seu aplicativo.
Aqui está uma escalabilidade não linear onde, mesmo depois de adicionar mais servidores, a arquitetura não é projetada de forma que, embora você esteja adicionando muitos servidores Web ou servidores de aplicativos, seus aplicativos não sejam dimensionados, pois sua carga de usuário é crescente.
Portanto, seus requisitos de transação estão crescendo e você está adicionando Servidores, está executando todas as etapas corretas, mas ainda não consegue obter a capacidade necessária para acomodar o aumento da carga de solicitações. Portanto, esse problema geralmente está associado a fontes de dados de back-end e falarei sobre isso.
Então, primeiro vamos ver quais aplicativos precisam de escalabilidade. Quais são os diferentes tipos de aplicativos? Dentro do ASP.NET e .NET Core temos Web Apps, e MVC Web Application, executando o negócio principal, alguns Web Services, alguns Service Calls, alguns Microservices, essa é a nova arquitetura e pode ser qualquer outro .NET geral ou .NET Core Aplicação.
Tudo isso demanda escalabilidade, porque você pode ter muitos usuários internos ou externos ou carga de solicitação acontecendo, que precisa ser atendida pela arquitetura do seu aplicativo.
O problema de escalabilidade
Eu mencionei que você pode criar um Web farm. Você pode distribuir a carga do aplicativo em vários servidores. Então, onde exatamente está o problema de escalabilidade? Como você pode ver, se você adicionar servidores, deverá ser capaz de lidar com cada vez mais carga de solicitação, porque isso oferece uma escalabilidade linear no que diz respeito ao farm de aplicativos ou ao farm da Web.
Mas, quando exatamente você começa a ver uma escalabilidade não linear ou nenhuma escalabilidade? Isso é normalmente com bancos de dados relacionais. Sua camada de aplicativo se expande bem, certo. Você pode adicionar mais servidores. Você pode criar várias instâncias do mesmo aplicativo na mesma caixa ou pode ter caixas separadas hospedando seus aplicativos. Mas todos esses aplicativos normalmente se comunicam com um banco de dados relacional de back-end e o banco de dados relacional é muito bom para armazenamento, mas quando se trata de lidar com uma quantidade extrema de carga de solicitação, por exemplo, você tem muita carga transacional acontecendo em seus aplicativos, esse banco de dados se torna um gargalo. Antes de mais nada, vai desacelerar as coisas, então, é um gargalo de desempenho e depois não tem capacidade de aumentar a escalabilidade dele. Não tem qualquer capacidade de aumentar a capacidade. Apenas forneceria a capacidade do servidor em que o banco de dados está hospedado.
Também pode ser algum banco de dados de mainframe. Pode ser algum sistema de arquivos. Todas essas fontes são um gargalo de escalabilidade para seu aplicativo e é aí que seus aplicativos ficam mais lentos. Suas solicitações começam a enfileirar e a experiência geral do usuário final é afetada por isso. NoSQL não é a resposta. Você sabe, eu entendo que muitos NoSQL produtos estão lá. Também temos um produto chamado NosDB, que é um NoSQL database. Mas o principal problema com NoSQL databases é que seus aplicativos exigiriam uma re-arquitetura, onde você para de usar um banco de dados relacional e começa a usar um NoSQL fonte de dados não estruturada em comparação.
Então, re-arquitetar o aplicativo também não é fácil, certo. Então, esse é outro problema que você precisa tomar. Portanto, em geral, seus aplicativos não são escaláveis, principalmente devido às fontes de dados de back-end.
A solução: NCache Cache Distribuído
Qual é a solução? É muito simples, que você comece a usar um sistema de cache distribuído como NCache. Está na memória, então, é super rápido em comparação com o banco de dados. Então, esse é o primeiro benefício que você tira disso. Portanto, com acesso na memória, comparado ao acesso baseado em disco NCache é super rápido em comparação. Então, primeiro benefício, suas solicitações regulares de aplicativos vão para NCache em comparação com o banco de dados, serão super rápidos e também reduzirão a carga do banco de dados, economizando viagens para as fontes de dados de back-end. Assim, seu banco de dados está livre para fazer outras coisas também. O segundo benefício é que é muito escalável. É linearmente escalável em seu modelo. Não é apenas um único servidor. Existem vários servidores que você pode usar para hospedar seu cluster de cache. É um cluster de cache. Assim, a equipe de servidores trabalha em conjunto e ajuda a atender às solicitações de seus clientes. Mais servidores significam mais capacidade de tratamento de solicitações de NCache e é aí que você obtém grandes benefícios, onde não apenas você obtém respostas super-rápidas de NCache, é super-rápido, de baixa latência e também oferece alto rendimento, escalabilidade extremamente alta. Você pode continuar adicionando mais servidores e aumentar linearmente essa capacidade sempre que a carga de usuários aumentar, sem alterar nada na arquitetura do aplicativo.
E, coisa boa sobre NCache é que você o usa além de um banco de dados de backend. Não é uma substituição de suas fontes de dados relacionais convencionais. Não precisamos rearquitetar o aplicativo para começar a usar NCache. Você sempre pode usar NCache em combinação com uma fonte de dados de back-end, onde alguns ou a maioria de seus dados estão dentro NCache e banco de dados tem cópia mestre dele. Mas, para alguns casos de uso, o cache teria todos os dados. Por exemplo, para sessões e para outros casos de uso.
NCache Números de escalabilidade
Aqui estão os nossos números de rendimento. Realizamos esses testes em nosso laboratório da AWS. Esses eram dados de aplicativos da vida real, simulados em nosso laboratório da AWS. Então, não é um toque e vá dados. Dados reais da aplicação simulados, em nosso ambiente. Onde usamos 5 NCache servidores e conseguimos atingir 2 milhões de solicitações por segundo em NCache.
Então, esse é o tipo de melhoria de desempenho que você tem se você ou os números de escalabilidade que você tem, se você tem mais e mais servidores adicionados. Então, 2 milhões de solicitações por segundo com apenas 5 NCache servidores e foi uma tendência de crescimento muito linear e deve continuar aumentando, se você continuar adicionando mais servidores.
Estes são publicados em nosso site também. Há um demonstração em vídeo disponível também.
Arquitetura de Implantação
Aqui está nossa arquitetura de implantação. Normalmente, é assim que NCache sistema de cache distribuído é implantado. Ele é compatível com todos os ambientes on-premise e na nuvem. Você pode, você só precisa que o .NET ou NET Core Framework esteja disponível. Esse é o único pré-requisito para NCache e você pode implantá-lo em servidores Windows e Linux. Pode ser suas caixas físicas ou virtuais no local ou qualquer nuvem pública ou privada, onde você tenha .NET ou .NET Core instalado no Windows ou Linux. Então, são dois requisitos.
Fora isso NCache é suportado em todas as plataformas. Está disponível em Azure Marketplace, bem como a AWS e também estamos criando um modelo baseado em SaaS ou implantação de NCache em nossas próximas versões.
Existem duas opções de implantação. Uma é que você deve usar servidores dedicados para armazenamento em cache e seus aplicativos se conectam em um modelo de servidor cliente. Esse é o modelo preferido na nuvem também, onde você não tem VMs do lado do cliente, mas tem implantação do lado do servidor.
E, a segunda opção de implantação é que você usa suas caixas de aplicativos existentes como seu NCache servidores também. Isso ocorre principalmente no local, onde você já tem uma camada de aplicativo. Configurações menores, você pode querer usar NCache para ser instalado na mesma caixa, mesmo conjunto de servidores.
De qualquer maneira NCache lida com a maior parte do seu tráfego. 100% é recomendado e algum tráfego sempre pode ir para o banco de dados de back-end e essas podem ser suas operações transacionais de leitura e gravação que você pode manipular através do cache para fontes de dados de back-end.
Portanto, você pode usar o cache como padrão de site onde seu aplicativo possui dados e atualiza dados ou busca dados do cache e do banco de dados em conjunto ou pode usar a abordagem de leitura e gravação que também está disponível com NCache.
Usos comuns do cache distribuído
Vou falar sobre alguns casos de uso e então vamos direto para o nosso ASP.NET Core cache específico recursos. Então, vamos falar sobre alguns casos de uso comuns de NCache. Existem muitos casos de uso. E, do ponto de vista técnico, listei alguns e estes são específicos para ASP.NET Core aplicativos, mas em geral para qualquer .NET ou ASP.NET ou ASP.NET Core or .NET Core. Pode ser um aplicativo da Web, algum aplicativo de back-end, alguns fluxos de trabalho, alguns serviços do Windows, qualquer aplicativo pode utilizar NCache e há muitos casos de uso que você pode escolher.
-
Cache de dados do aplicativo
Principalmente, para ASP.NET Core, vamos direcionar o cache de dados do aplicativo e nisso temos duas opções. Você pode usar Interface IDistributedCache. Se você já estiver usando o IDistributedCache em seus aplicativos, basta conectar NCache como provedor para isso. Então, essa é a primeira opção. A segunda opção é que, você usa direto NCache APIs e no cache de dados do aplicativo, você armazena em cache quase tudo dentro do seu aplicativo. Pode ser seus objetos de domínio, coleções, conjuntos de dados, quaisquer dados que você gostaria de usar mais de uma vez e não deseja ir para o banco de dados de back-end, você recuperou esses dados e agora pode preservar esses dados no cache e você pode continuar usando o repositório de cache e economizar viagens ao banco de dados.
ASP.NET Core Cache de Sessão e SignalR Backplane
O segundo caso de uso é ASP.NET Core cache específico. Esses são nossos recursos de cache de front-end da Web. Nesta frente, temos muitos recursos. Você pode usar ASP.NET Core estado da sessão. Você sabe, é uma sessão de site único e de vários sites. NCache é um cluster de cache distribuído. Assim, suas sessões são armazenadas de forma distribuída dentro NCache. Também é uma opção sem alteração de código, quase com uma linha de alteração de código no método de extensão onde você conecta NCache. Não são necessárias grandes alterações de código para usar isso e elas são muito confiáveis dentro NCache porque as sessões são replicadas entre servidores. Portanto, qualquer servidor inativo não teria nenhuma perda de dados ou tempo de inatividade do aplicativo do seu lado.
A segunda característica aqui é ASP.NET Core cache de resposta. Se você tiver páginas estáticas. Historicamente, no ASP.NET, tínhamos cache de saída. No ASP mais recente.NET Core plataforma, você pode usar o cache de resposta, onde você define os cabeçalhos de nível de página e, com base neles, todas as saídas da página são armazenadas em cache dentro NCache. Assim, as respostas são armazenadas em cache. Se você emitir exatamente as mesmas solicitações novamente, a resposta pré-armazenada será disponibilizada. Então, esse é um recurso dentro NCache, que também é uma opção sem alteração de código que você pode usar no ASP.NET Core nível de cache de front-end.
E então, se você estiver usando o SignalR e tiver um web farm, precisará de um backplane como obrigatório. Então, SignalR Backplane é necessário se você for de um único servidor para uma implantação de web farm e, nesse caso NCache pode atuar como um ASP.NET Core Painel traseiro, SignalR Backplane para seus aplicativos SignalR. Ele está usando o Pub/Sub Messaging nos bastidores, que são orientados a eventos. Muito rápido, muito escalável. Assim, você obtém benefícios de alto desempenho e escalabilidade e alta disponibilidade e confiabilidade, se você plugar NCache como ASP.NET Core SignalR Backplane.
Mensagens do Pub/Sub
Por fim, o terceiro caso de uso é o Pub/Sub Messaging. Mensagens do Pub/Sub também é um caso de uso separado. Para SignalR, nos bastidores que estamos usando é o Pub/Sub Messaging. Mas o Pub/Sub Messaging pode ser usado como um caso de uso separado dentro NCache também. Para aplicativos de microsserviços, isso faz muito sentido, onde você tem aplicativos simples definidos na arquitetura de microsserviços. Esses são responsáveis por uma tarefa dedicada. Um propósito muito importante que eles estão servindo. Portanto, é muito difícil organizar a comunicação entre esses Microsserviços e NCache pode resolver esse problema. Você não precisa implementar nenhuma comunicação em seus aplicativos de microsserviços por conta própria. Você pode confiar NCache plataforma de comunicação para isso e qualquer aplicativo conectado a ela pode enviar e receber mensagens e não precisa ter nenhuma degradação de desempenho enquanto estiver fazendo isso.
Você pode ter o modelo de assinante do editor. Onde os editores estão publicando dados no cache e, em seguida, o cache armazena e retransmite essas mensagens para todos os assinantes. É um mecanismo orientado a eventos Async. Assim, editor e assinante nem precisam se conhecer. Portanto, não há latência, espera envolvida, nenhuma chamada síncrona envolvida. Então, é uma arquitetura muito robusta, muito rápida, fracamente acoplada e tudo é gerenciado por NCache, no que diz respeito a esta plataforma.
Demonstração prática
Então, cobrimos esses recursos de alto nível. Em seguida, mostrarei o produto real em ação. Onde vou criar um cluster de cache. Teste-o. Mostrar alguns aspectos de monitoramento e depois falaremos sobre todos esses recursos que você pode usar no ASP.NET Core um por um. Então, eu alinhei alguns aplicativos de exemplo para isso. Então, estou entrando no meu ambiente de demonstração.
Então, aqui temos dois NCache servidores que estarei usando e minha caixa atuaria como uma máquina cliente de onde eu executaria todos esses aplicativos de amostra. Então, a ideia aqui é que eu vou usar o ferramenta de gerenciamento baseada na web e ferramenta de monitoramento.
Assim, esta ferramenta de gestão baseada na web permite-lhe gerir e monitorizar tudo a partir de um único ponto. Pode ser qualquer solicitação da web, solicitação http de qualquer lugar, do seu ambiente para um de seus NCache servidores ou clientes e deve permitir que você gerencie e monitore tudo remotamente através da web.
Criar um cache clusterizado
Portanto, localhost, você pode fornecer um endereço IP e acessar esse recurso de qualquer lugar da Internet. Então, vou em frente e criar um novo cache. Digamos, 'aspcorecache'. Todos os caches precisam ser nomeados. Você também pode criar vários clusters de cache e criar qualquer nome de cache significativo conforme necessário.
O modo de serialização pode ser binário ou JSON. Então, vou manter o binário, o binário e o JSON também é muito flexível, então, se você quiser usar isso, eu escolherei a partição da topologia de cache de réplica.
Dentro NCache Há muitos topologias de cache. Se eu rapidamente levá-lo para o final. Portanto, temos muitas topologias de cache para escolher. Nós particionamos e depois particionamos com backups. Então, neste temos cada servidor mantendo duas partições. Uma partição de dados ativa, onde os clientes estão conectados e uma partição de réplica passiva de outro servidor. Como você pode ver, o servidor um está ativo, seu backup está em dois e o servidor dois está ativo, seu backup está no servidor um. Caso algum servidor caia, o backup é ativado e você obtém todos os dados daqui. Em operações normais, essas partições têm distribuição igual de dados.
Os clientes estão conectados a todos os servidores, portanto, as solicitações de leitura e gravação são super rápidas e, se você adicionar mais servidores, obterá mais capacidade de manipulação de solicitações de leitura e gravação, porque todos esses servidores funcionam em combinação entre si. Então, essa é a topologia que estou escolhendo partição de réplica.
E, em seguida, opção de replicação assíncrona. Entre ativo e backup, você pode escolher sincronizar ou assíncrono. A sincronização é mais confiável. Assíncrono é mais rápido. Então, eu vou em frente com isso.
O tamanho 1024 é bom o suficiente para esta demonstração, mas você pode criar qualquer tamanho que pareça significativo para você.
Parâmetros TCP.
Questão: Estamos usando atualmente NCache, existe uma maneira de evitar um arquivo client.ncc ou nc conf ou algo que você tenha em seu pipeline de desenvolvimento?
Sim. Isso é absolutamente possível. client.ncconf permite especificar configurações para conectar a um servidor de cache, onde o cluster de cache está sendo executado, certo. No meu caso, tenho duas caixas e um nome de cache. Portanto, client.ncconf tem o nome do cache e os servidores onde este cache está configurado. Se você quiser evitar client.ncconf, você pode fornecer todas essas configurações inline. Temos parâmetros de inicialização de cache. Nós os chamamos de parâmetros de inicialização do cache. Esses são que o objeto permite que você especifique todas essas configurações dentro do código do aplicativo. Então sim. Para responder a essa pergunta, você precisa usar os parâmetros de inicialização do cache.
Questão: Podemos implantar NCache em Azure?
Absolutamente. Eu discuti isso quando estávamos compartilhando detalhes sobre a arquitetura de implantação. NCache é totalmente compatível com Microsoft Azure e AWS e qualquer outra nuvem pública ou privada. Apenas pré-requisito para NCache é .NET ou .NET Core, dependem do sistema operacional escolhido. Também estamos apresentando nosso modelo SaaS no Azure e na AWS. Portanto, é totalmente suportado. Nossa imagem de mercado também é publicada. Então, há muitas maneiras de usar NCache no Azure.
NCache é um protocolo de cluster de cache baseado em TCP/IP. Portanto, requer um endereço IP e uma porta. Então, vou manter tudo padrão na tela.
Se meu cache ficar cheio, tenho duas opções: posso rejeitar novas atualizações e continuar usando o cache para leitura ou posso ativar os despejos e remover automaticamente alguns dados para liberar espaço para os itens mais recentes.
Para sessões, para estado de exibição, para armazenamento em cache de resposta e até mesmo para armazenamento em cache de objetos, se os dados forem de natureza importante, recomendo que você desative o despejo e forneça um tamanho de gás grande o suficiente para que nunca fique cheio e mesmo que fique cheio você pode alterar o tamanho do cache em tempo de execução. Mas, se não há problema em pagar, não há problema em realmente perder alguns dados, se você puder pagar, então, nesse caso, você pode habilitar despejos e, quando o cache ficar cheio, ele removerá automaticamente alguns dados e abrirá espaço para os dados mais recentes. Então, é isso que o despejo faz.
Inicie este cache ao terminar e inicie automaticamente este cache na inicialização do serviço. Então, toda vez que meu servidor é reiniciado, o cache é inicializado automaticamente e é isso. Veja como é fácil configurar um cluster de cache de dois nós com NCache.
Simule o estresse e monitore as estatísticas de cache
Então, nosso cache está funcionando. Ele também está ativado, então, vou rapidamente testá-lo. Janela de estatísticas. Então, eles me mostram contadores de perfmon em ambos os servidores e, em seguida, monitorando aspectos de NCache.
Muito bem. Então, ele também me dá uma visão de relatório de painel do lado do servidor e do lado do cliente. Então, todos os parâmetros estão lá.
A próxima coisa é testar esse cache. Nenhum aplicativo está conectado, então vou fazer isso. Esse é o nome do cache e nos bastidores isso está usando configurações do lado do cliente para se conectar e se conectaria ao meu cluster de cache e começaria a simular solicitações. Como você pode ver o contador de solicitações por segundo e o contador médio de microssegundos por operação de cache mostrando a atividade. Temos adições, buscas, atualizações acontecendo também e temos o contador de tamanho de cache aparecendo, CPU, memória e temos IPs de clientes que estão atualmente conectados ao cache.
Deixe-me prosseguir e executar outra instância dessa ferramenta.
Questão: Outra pergunta, enquanto você estava fazendo isso é, podemos monitorar todos os clientes conectados aos nossos caches?
Absolutamente. Esse é um dos recursos muito poderosos dentro NCache. Eu posso mostrar isso com a ajuda deste exemplo. Agora que temos dois clientes conectados. Em primeiro lugar, posso ver os painéis do cliente. Então, esses dois clientes estão sendo executados a partir do 107 e posso ver as operações de leitura sendo feitas a partir dessa caixa do cliente. Se eu estiver executando aplicativos da minha caixa, o que eu faria, você veria minhas estatísticas de caixa aqui também e, da mesma forma, também podemos ver os processos, seus IDs de processo, portas, bytes enviados e recebidos daqui também. Mas, acho que a principal coisa que você está procurando são diferentes aspectos de monitoramento do lado do cliente. Então, temos operações de leitura por segundo, adições por segundo, atualizações por segundo, buscas.
Assim, temos um conjunto completo de contadores do lado do cliente, que estão disponíveis como parte do NCache, right e integridade do cache e todos esses contadores do lado do servidor, mas todos esses contadores, que você está mostrando no lado do cliente, podem ser adicionados e você também pode revisar todos eles para seus servidores de aplicativos cliente.
então, NCache é muito extenso em seu suporte para monitoramento do lado do cliente. Espero que isso responda sua pergunta.
Agora, eu executei, na verdade, sou capaz de executar duas instâncias da ferramenta de teste de estresse e você pode ver cerca de 800 a 900 solicitações por segundo por cada NCache servidor. Assim, cerca de 1500 solicitações por segundo, em média, estão sendo tratadas.
Então, essa foi uma demonstração rápida. Vou parar com essas ferramentas. Em seguida, vou mostrar os recursos reais que você pode realmente utilizar. Então, passamos um bom tempo explicando como NCache é muito escalável.? Como é implantado? Como configurar e criar um cluster de cache?
Agora, a próxima coisa que eu gostaria de destacar é como utilizar NCache em ASP.NET Core aplicações e quais são os principais casos de uso. Cobrimos diferentes casos de uso. Então, vou começar com casos de uso de cache de front-end da Web dentro do ASP.NET Core.
NCache ASP.NET Core Cache de sessão
Então, o primeiro recurso que vou destacar é NCache ASP.NET Core cache de sessão. Temos duas opções aqui. Você pode usar, se já estiver usando sessões e a maioria das chances é que você esteja usando a interface IDistributedCache. Assim, você pode conectar NCache como provedor de cache de sessão por meio de IDistributedCache. Você tem um provedor de memória autônomo. Você tem um provedor de servidor SQL. Autônomo é um único ponto de falha. Não é escalável. O SQL Server também é um ponto único de falha em alguns casos. Não é escalável e é muito lento.
NCache provedor é super rápido. Está na memória. É muito escalável. Não é um ponto único de falha e você aumenta a capacidade em tempo de execução. Assim, você pode ter mais e mais servidores adicionados e você pode saber alcançar escalabilidade ilimitada fora de NCache. Então, IDistributedCache, vamos revisar isso rapidamente. Então, aqui está nosso jogo de adivinhação, IDistributedCache.
public void ConfigureServices(IServiceCollection services)
{
//Add framework services
services.AddMvc();
services.AddNCacheDistributedCache(configuration =>
{
configuration.CacheName = "MyNCacheCache";
configuration.EnableLogs = true;
configuration.ExceptionsEnabled = true;
});
}
public void Configure(IApplicationBuilder app)
{
app.UseNCacheSession();
}
Tudo que você precisa fazer é, serviços dot add NCache Cache distribuído e, em seguida, diga app Use NCache Session e aqui está um aplicativo de exemplo que fará exatamente isso.
public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
//To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
services.AddSession();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseBrowserLink();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();A segunda opção aqui é NCache provedor de sessão que possui recursos avançados e eu tenho um aplicativo de exemplo para isso também. Então, vamos realmente focar nisso. Principalmente, porque nosso provedor é muito mais rico em recursos em comparação com o IDistributedCache, portanto, gostaria de destacar isso e, como parte disso, você veria todos os recursos que o provedor IDistributedCache também oferece.
Então, voltando aqui. Em primeiro lugar, você precisa NCache pacote NuGet, que já adicionei dentro deste. Então, se tivermos AspNetCore.Sessions.NCache, direita. Então, esse é o pacote NuGet e deixe-me voltar aqui rapidamente e revisar a sessão aqui também e isso NCache.Microsoft.Extensões.Cache. Portanto, os pacotes NuGet da sessão IDistributedCache são um pouco diferentes dos NCache provedor de sessão real.
Então, vou focar neste aqui. Tudo que você precisa fazer é…. Primeiro de tudo, venha para Startup.cs. Você tem serviços.AdicionarNCacheSessão e leva NCache configurações na configuração.
...
public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
//To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
//services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
//services.AddSession();
services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
... E, dentro da configuração, você especifica todos NCache configurações do provedor. Por exemplo, estou usando ASP.NET Core cache. SessionAppId é um atributo de id de aplicativo que o aplicativo é anexado com a chave do item de cache. Seu ID de sessão se torna a chave de cache e esse atributo seria anexado a ele. Assim, você pode visualizar exclusivamente sessões de diferentes aplicativos dentro NCache e então você configura algum bloqueio de sessão. Você pode, se você definir isso como verdadeiro. Tudo bem, então, se você definir isso como verdadeiro, isso permitiria que você simplesmente bloqueasse a sessão, para que o acesso simultâneo não seja permitido.
{
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"NCacheSettings": {
"CacheName": "mycache", //Replace "myPartitionedCache" with the name of your cache
"SessionAppId": "GuessGame", //(Optional)Specifies an identifier to make sure that session ID remains unique in case multiple applications are using the same cache.
"EnableSessionLocking": false, //(Optional)If this flag is set, NCache Session Store Provider exclusively locks the session-store item for which multiple concurrent requests are made. The default is false.
"SessionLockingRetry": -1, //(Optional)If enableSessionLocking is true and this integer is not less than 0, NCache Session Store Provider will return empty session after sessionLockingRetry, which specify the number of retries to acquire a lock. The default is -1.
"EnableLogs": false, //(Optional)When this flag is set, store provider logs all error information. The log files are created in %NCHOME%/log-files/SessionStoreProvider. The default is false.
"EnableDetailLogs": false, //(Optional)When this flag is set, store provider logs all debugging information. The log files are created in %NCHOME%/log-files/SessionStoreProvider. The default is false.
"ExceptionsEnabled": false, //(Optional)Specifies whether exceptions from cache API are propagated to the page output. Setting this flag is especially helpful during development phase of application since exceptions provide more information about the specific causes of failure. The default is false.
"OperationRetry": 0, //It specifies the number of times server will retry the operation, in case connection is lost with a server while an operation is executing. Its default is zero.
"operationRetryInterval": 0 //It specifies the time interval between each operation retry, in case connection is lost with the server. Its default value is zero.
}
}Então, você só pode ler a sessão. O acesso de gravação é concedido apenas à solicitação atual que possui o log e, em seguida, temos logs detalhados disponíveis. Sessões de site único e de vários sites estão disponíveis. Portanto, todos esses recursos só estão disponíveis se você conectar nosso ASP.NET Core provedor de sessão. As sessões IDistributeCache são suportadas, mas são limitadas. Então, vou executar isso bem rápido e isso simularia um aplicativo que acabaria se conectando a esse ASP.NET Core cache.
Na verdade, deixe-me parar com isso. Deixe-me adicionar minha caixa como cliente primeiro. Então, aqui tudo que eu preciso fazer é adicionar a caixa do cliente que é a minha caixa aqui.
Ai está. Eu tenho todas as configurações agora e agora posso executar este aplicativo mais uma vez e isso deve ter permissão para se conectar ao meu cluster de cache. Muito bem. Portanto, levará algum tempo para a primeira instanciação.
Então, isso criaria um objeto de sessão dentro NCache. Vou ver, se eu for para o aspecto de monitoramento veria um cliente conectado. Uma vez que o provedor é inicializado, esse cliente faria conexão com 107 e 108 e criaria objetos de sessão dentro NCache. No momento, apenas um objeto de sessão seria criado porque esse é o usuário principal. Eu serei o único usuário conectado, mas se você tiver vários usuários de aplicativos, verá várias sessões criadas dentro NCache. Mas, a ideia aqui é, é muito simples que tudo que você precisa fazer é adicionar essas duas linhas de códigos. Adicionar NCache sessão e depois diga Usar NCache sessão.
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
//To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
//services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
//services.AddSession();
services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseBrowserLink();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
//To test NCache Distributed Cache, uncomment this and comment the line below this
//app.UseSession();
app.UseNCacheSession();
... Esses métodos de extensão vão cobrir tudo. A primeira instanciação leva um pouco mais de tempo, é o que vimos no ASP.NET Core mas assim que estiver, os aplicativos estiverem funcionando, devemos ser capazes de testá-lo bem rápido. Ai está. Um cliente já está conectado, então acho que chegamos.
Enquanto isso, deixe-me executar um comando rápido que diz exportar. Esta ferramenta despeja todas as chaves de cache que estão atualmente lá.
Então, estou esperando um objeto de sessão adicionado ao cache porque um cliente está conectado e isso deve permitir que haja duas sessões. Um da tentativa anterior e um desta, já está lá. Ai está.
Este é um jogo de adivinhação que permite adivinhar um número e adiciona esses números dentro da sessão e também exibe esses números. Então, deixe-me adivinhar um número maior e é assim que ele fará uma solicitação para NCache.
Então, é um aplicativo bem simples, mas se você voltar aqui, temos dois itens no cache que estão lá e você deve ter visto esses dois pedidos que acabei de fazer NCache lado do servidor.
Então, isso completa nossa primeira demonstração, que você pode plugar NCache para cache de sessão. Existem muitos recursos. Sessões de site único e multisite são suportadas. O bloqueio de sessão é suportado. O registro extensivo está disponível. É muito seguro. Temos segurança e criptografia em cima disso. Então, é um pacote completo, se você planeja usar NCache para cache de sessão.
ASP.NET Core Cache de resposta
O segundo recurso aqui é o ASP.NET Core cache de resposta. Neste, temos cabeçalhos http nas aplicações. Você pode optar por ter as saídas de página armazenadas em cache e usar NCache middleware de cache de resposta para armazenamento em cache e é novamente através da interface IDistributedCache. Então, se eu voltar aqui, temos isso aplicativo de amostra.
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.HttpsPolicy;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Alachisoft.NCache.Caching.Distributed;
namespace ResponseCaching
{
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.Configure<CookiePolicyOptions>(options =>
{
// This lambda determines whether user consent for non-essential cookies is needed for a given request.
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
#region Option1
// Reading NCacheSettings using appsettings.jsonEntão, tudo o que você precisa fazer para usar isso é usar este pacote NuGet NCache.Microsoft.Extensões.Cache. Isso cobrirá sessões, IDistributedCache para cache de objeto e cache de resposta em um pacote NuGet.
E, então, a próxima coisa que você precisa fazer é serviços.AdicionarNCacheCache Distribuído.
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.Configure<CookiePolicyOptions>(options =>
{
// This lambda determines whether user consent for non-essential cookies is needed for a given request.
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
#region Option1
// Reading NCacheSettings using appsettings.json
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
#endregion
#region Option2
// Reading NCacheSettings using hardcoded values
//services.AddNCacheDistributedCache(options =>
//{
// options.CacheName = "myPartitionedCache";
// options.EnableLogs = true;
// options.ExceptionsEnabled = true;
//});
#endregion
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}Então, essa é uma interface IDistributedCache que é conectada, mas a usaremos para armazenamento em cache de resposta e nas configurações do aplicativo temos os nomes de cache e algumas configurações de log que configuramos e se eu voltar aqui, você terá o cache de resposta configurado também, services.AddResponseCaching();
...
namespace ResponseCaching
{
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.Configure<CookiePolicyOptions>(options =>
{
// This lambda determines whether user consent for non-essential cookies is needed for a given request.
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
...Portanto, este aplicativo espera que o cache de resposta seja feito. Seria feito através NCache usando a interface IDistributedCache. Então, vou fazer isso bem rápido porque leva algum tempo e espero que ele possa realmente se conectar a NCache e então mostraremos os dados que estão sendo adicionados.
Se eu mostrar o código. Você sabe, você também pode especificar configurações inline. Por exemplo, 'AdicionarNCacheDistributedCache' e você pode dizer o nome do cache 'demoClusteredCache' ou 'aspCoreCache' e você pode especificar todas as configurações inline
public void ConfigureServices(IServiceCollection services)
{
...
services.AddNCacheDistributedCache(configuration =>
{
configuration.CacheName = "demoClusteredCache";
configuration.EnableLogs = true;
configuration.ExceptionsEnabled = true;
});
...
}
ou você pode simplesmente usar o NCache configuração e dar configurações através NCache configurações, aqui. Pode ser por meio de configuração ou por meio de configurações em linha. Então, é muito simples nessa frente.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
//remaining services here
...
//Add NCache services to the container
services.SetNCacheSessionConfiguration (
Configuration.GetSection("NCacheSettings"));
services.AddNCacheDistributedCache();
services.AddMvc();
}
Se eu voltar aqui agora, esperamos que dois clientes sejam conectados porque o aplicativo de armazenamento em cache de resposta também faria uma conexão com NCache e veríamos alguns itens no cache como resultado disso.
Questão: Como exatamente os dados são criptografados e mantidos seguros?
Deixe-me mostrar este exemplo de armazenamento em cache de resposta e, em seguida, mostrarei os recursos de criptografia de segurança dentro NCache. Então, temos o aplicativo rodando e como você pode ver, temos alguns itens adicionados. Se eu simplesmente atualizar isso, temos os valores sendo atualizados a partir daqui e isso está sendo, o conteúdo de saída desta página é armazenado dentro NCache através do nosso cache de resposta e se eu mostrar as chaves do cache, agora temos mais alguns itens no cache. Então, dois itens além dos itens de sessão que já estão lá.
Agora, voltando para criptografia de segurança. Esses são muito extensos por dentro NCache. Temos recursos de segurança e criptografia. Existem muitos provedores de segurança que você pode escolher. Temos provedores AES e DES. Vários desses. Temos provedores de criptografia compatíveis com FIPS e também temos suporte para TLS 1.2. Assim, a segurança de nível de transporte também está disponível com NCache. Então, é isso que cobre sua criptografia. Onde você pode ter criptografia de ponta a ponta entre suas caixas de cliente e servidor e, em seguida, do ponto de vista de segurança, você pode escolher quem pode ser administrador de cache, quem pode ser usuário de cache e temos um provedor de segurança de criptografia baseado em LDAP baseado em diretório ativo que você pode ligar.
Portanto, se houver alguma dúvida específica, você pode nos enviar um e-mail e trabalharemos com você e compartilharemos todos os detalhes sobre como configurá-los. Mas temos um suporte muito amplo dentro NCache. Então, voltando aqui. Então, isso cobre nosso ASP.NET Core Cache de resposta.
ASP.NET Core SignalR Backplane
O próximo recurso é ASP.NET Core SignalR Backplane. Nesse caso, se você estiver usando um web farm, poderá usar NCache como um backplane para ele e em comparação com backplanes convencionais, NCache é muito mais rápido, muito confiável e muito escalável também.
Então, aqui está o pacote NuGet que eu adicionei. AspNetCore.SignalR.NCache que você pode pesquisar. Já está instalado. Tudo o que você precisa fazer, novamente, é obter um nome de cache através das configurações do aplicativo e aqui está o método de extensão. Então, se você tem services.AddSignalR, temos um método de extensão onde adiciona NCache tem um SignalR Backplane para ASP.NET Core aplicações.
// This method gets called by the runtime. Use this method to add services to the container.
// For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<NCacheConfiguration>(Configuration.GetSection("NCacheConfiguration"));
services.AddSignalR().AddNCache(ncacheOptions =>
{
ncacheOptions.CacheName = Configuration["NCacheConfiguration:CacheName"];
ncacheOptions.ApplicationID = Configuration["NCacheConfiguration:ApplicationID"];
// Uncomment in case of cache security enabled.
//ncacheOptions.UserID = Configuration["NCacheConfiguration:UserID"];
//ncacheOptions.Password = Configuration["NCacheConfiguration:Password"];
});
}Vou executá-lo bem rápido porque está demorando algum tempo. Eu acho que muitas coisas estão acontecendo. Então, vou executar esta amostra. Então, isso criaria um aplicativo de bate-papo e estaria usando, nos bastidores, usando o Pub/Sub Messaging de NCache. Então, para isso, o que realmente farei é voltar aqui e no lado do servidor mostrarei alguns contadores de desempenho, que permitiriam gerenciar e monitorar especificamente as mensagens do Pub/Sub e o SignalR está usando o Pub/ Sub mensagens nos bastidores. Então, deixe-me dizer SignalR, certo. Então, e se você notar aqui, temos a seção de mensagens aqui. Onde podemos ver o tamanho do armazenamento de mensagens, contagem de mensagens, entregues por segundo, expiradas por segundo, publicadas, contagem de tópicos.
Tópicos permite que você tenha separação de preocupações. Vários aplicativos usando NCache como um SignalR Backplane eles teriam vários tópicos criados dentro NCache. Assim, tópicos de uma mensagem de natureza semelhante podem ser dados a um tópico separado. Por exemplo, você pode criar um tópico para pedidos. Você pode criar um tópico para clientes de mensagens. Assim, você pode ter mensagens diferentes em tópicos diferentes e os assinantes conectados a um tópico separado recebem apenas as mensagens relacionadas a eles. Então, já vejo alguma atividade aqui o que significa que meu aplicativo está funcionando. Então, se eu voltar ao painel do servidor, agora temos três aplicativos em execução. Não verei nada nas estatísticas regulares. Eu veria tudo nas estatísticas de mensagens. Assim, você pode ver a contagem de mensagens.
Então, havia algumas mensagens, tamanho da loja, é cerca de 800 bytes. Mensagem publicada e então acho que outros parâmetros na data não estão lá porque ainda não temos nenhuma expiração.
Então, voltando ao meu aplicativo, eu executaria outra instância disso. Tudo bem, então, eu tenho dois aplicativos. Deveria tê-lo executado em modo anônimo, mas teste a mensagem assim que enviar isso, também será enviado aqui. Teste a mensagem 2 e você verá essa mensagem do outro lado também, certo, e se eu voltar aqui, temos alguma atividade acontecendo aqui.
Portanto, ele usa o Pub/Sub Messaging nos bastidores e permite que você crie um backplane. Portanto, o SignalR em si, o caso de uso para ele, enfatiza a notificação por push em vez da pesquisa do usuário, na qual você pode enviar conteúdo para seus usuários. Mas com o web farm, há uma limitação de que você só pode enviar conteúdo para os clientes conectados a esse servidor web. Se você tiver vários servidores web, precisará de um corpo central e Backplane por ASP.NET e ASP.NET Core resolve isso.
Então você pode usar NCache como um Backplane para isso. É uma plataforma de comunicação onde todas as mensagens são retransmitidas para NCache, Enviado para NCache e depois NCache por sua vez, envia para todos os servidores da web, transmite-o e esses servidores da web são capazes de transmitir essas mensagens para seus usuários finais, eventualmente. Então, é isso que torna muito rápida a arquitetura geral muito rápida porque o NCache está na memória. É super-rápido, muito escalável, muito confiável e altamente disponível.
OK. Então, acho que estamos bem nessa frente. Alguma pergunta? Caso contrário, vou seguir em frente e falar sobre o aspecto do cache de dados. Então, vamos gastar os últimos 10-15 minutos no cache de dados, alguns dos recursos. Existem muitos recursos nessa frente. Então, eu iria mostrar rapidamente alguns.
Então, em primeiro lugar, há muitas maneiras de usar NCache para o cache de banco de dados ou o cache de dados do aplicativo. Onde você armazena dados em cache dentro NCache & você salva viagens para o banco de dados de back-end. Se você já estiver usando o IDistributedCache, embora seja muito limitado, você pode conectar NCache como provedor.
Eu tenho um aplicativo de exemplo aqui. Novamente, é muito simples. Você precisa do pacote NuGet adicionado. é ASP.NET Core e NCache.Microsoft.Extensões.Cache.
public async Task<IActionResult> onPostResetCachedTime()
{
var currentTimeUTC = DateTime.UtcNow.ToString();
byte[] encodedCurrentTimeUTC = Encoding.UTF8.GetBytes(currentTimeUTC);
var options = new DistributedCacheEntryOptions()
.SetAbsoluteExpiration(TimeSpan.FromSeconds(20));
_cache.Set("cachedTimeUTC", encodedCurrentTimeUTC, options);
return RedirectToPage();
}Então, isso cobre IDistributedCache e você precisa de configurações de aplicativo onde você especifica o nome do cache e dentro de startup.cs você conecta. services.AddNCacheDistributedCache fornece as configurações por meio de config ou você pode usar a opção dois onde você especifica configs, todas as configurações por meio de código diretamente.
public void ConfigureServices(IServiceCollection services)
{
// Reading NCacheSettings using appsettings.json
services.AddNCacheDistributedCache(_config.GetSection("NCacheSettings"));
services.AddMvc().SetCompatibilityVersion(Microsoft.AspNetCore.Mvc.CompatibilityVersion.Version_2_2);
}E, no index.html.cs, temos alguns métodos aqui. Onde estamos chamando cache.GetAsync.
public string CachedTimeUTC { get; set; }
public async Task OnGetAsync()
{
CachedTimeUTC = "Cached Time Expired";
var encodedCachedTimeUTC = await _cache.GetAsync("cachedTimeUTC");
if(encodedCachedTimeUTC != null)
{
CachedTimeUTC = Encoding.UTF8.GetString(encodedCachedTimeUTC);
}
}E uma coisa que você precisa notar é essa interface IDistributedCache, por exemplo, se eu mostrar a você o GetAsync, ele está pegando um array de bytes de volta. Portanto, não é um objeto serializado ou desserializado que você está obtendo. Você tem que fazer a serialização e desserialização por conta própria.
using System.Threading;
using System.Threading.Tasks;
namespace Microsoft.Extensions.Caching.Distributed
{
public interface IDistributedCache
{
byte[] Get(string key);
Task<byte[]> GetAsync(string key, CancellationToken token = default);
void Refresh(string key);
Task RefreshAsync(string key, CancellationToken token = default);
void Remove(string key);
Task RemoveAsync(string key, CancellationToken token = default);
void Set(string key, byte[] value, DistributedCacheEntryOptions options);
Task SetAsync(string key, byte[] value, DistributedCacheEntryOptions options,
CancellationToken token = default);
}
}O que fizemos neste exemplo, na verdade, tomamos isso de tal forma que estamos serializando o objeto antes de adicionar e depois de recuperar estamos desserializando-o, certo. Então, estamos pegando a corda de volta por isso.
public string CachedTimeUTC { get; set; }
public async Task OnGetAsync()
{
CachedTimeUTC = "Cached Time Expired";
var encodedCachedTimeUTC = await _cache.GetAsync("cachedTimeUTC");
if(encodedCachedTimeUTC != null)
{
CachedTimeUTC = Encoding.UTF8.GetString(encodedCachedTimeUTC);
}
}Então, isso é algo que temos feito extensivamente e é isso que você tem que fazer. Com NCache usado diretamente como sua plataforma de armazenamento em cache de dados do aplicativo, você não precisa fazer tudo isso. NCache seria serializar e desserializar seus objetos automaticamente. Você só precisa marcá-los como serializáveis.
Então, vou executar este exemplo bem rápido e isso deve me permitir mostrar a interface IDistributedCache também e, finalmente, enquanto isso está sendo executado, eu também gostaria de construir, então, esta é nossa interface IDistributedCache e este é o segundo opção aqui, que estou mostrando aqui, é a opção direta NCache APIs. Aqui estão nossas APIs.
/*Cache Connection*/
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();
/*Fetching Data*/
Employee employee = cache.Get<Employee>("Employee:1000");
bool isPresent = cache.Contains("Employee:1000");
/*Writing Data*/
cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Como alternativa, recomendamos que você obtenha mais controle se gerenciar tudo por meio de NCache chamadas de API. Você se conecta a NCache usando inicialize o cache ou obtenha o cache nas versões atuais e então você diz cache.Get to retrieve items cache.Add to add items. Adicionar Async também está disponível Inserir e Inserir Async também está disponível e então você pode chamar cache.Remove. Portanto, essa é a segunda abordagem que mostrarei quando este exemplo for executado e o IDistributedCache for suportado, mas nossas APIs diretas são mais ricas em recursos em comparação.
Questão: Podemos usar NCache API junto com IDistributedCache e para isso onde podemos obter as amostras?
Então, antes de tudo, sim, você pode usar o IDistributedCache. Você já deve estar usando IDistributedCache. Assim, você pode conectar NCache como fonte para isso. Então, isso pode ser um ponto de partida e, além disso, você também pode começar a usar nossas APIs diretas no mesmo aplicativo. Então, sim, você pode fazer isso. Não o limitamos a usar um ou outro. Todos esses casos de uso que discutimos sobre Cache de Sessão, Cache de Resposta, SignalR Backplane, IDistributedCache ou direto NCache chamadas de API. Cinco desses recursos, você também pode usar todos eles em um único aplicativo. Então, essa é a beleza de NCache onde você pode combinar todos esses casos de uso.
Aplicativos de exemplo, todos esses exemplos são, eles vêm instalados com NCache, direita. Portanto, não estamos usando nada personalizado aqui. Então, tudo isso está disponível em amostra de arquivo de programa, NCache amostras. Estes são publicados em nosso site também.
Portanto, esta amostra foi executada. Então, se eu redefinir o tempo de cache, ele faria isso e se eu voltasse rapidamente aqui, mostraria as chaves de cache e agora você veria mais algumas chaves de cache. Acho que alguns itens expiraram, mas você vê o tempo de cache UTC. Alguns objetos de armazenamento em cache de resposta devem ter expirado.
Então, é assim que você usa a interface IDistributedCache com NCache.
Agora vou mostrar o direto NCache Chamadas de API, que recomendamos. Isso é algo que você também pode fazer. Então, para isso, você pode usar o Alachisoft.NCache.SDK pacote NuGet. Esse é o nosso SDK completo, que traz todos os recursos do lado do cliente e todos os recursos podem ser expostos no cliente usando este SDK e, com base nisso, posso dizer que inclua esses namespaces Alachisoft.NCache.Cliente e você também pode incluir Alachisoft.NCache.Tempo de execução porque existem alguns recursos avançados que você pode usar com isso.
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Client;
using System;
using System.Configuration;
using Alachisoft.NCache.Runtime.Caching;
namespace Alachisoft.NCache.Samples
{
public class BasicOperations
{
private static ICache _cache;
}
}
...Interface ICache. Esta é a nossa própria interface ao contrário do IDistributedCache, certo. Então, temos muitos recursos, como você pode ver em comparação, e dentro deles também temos vários recursos. Então, esses são alguns objetos no ICache.
Assim, você pode inicializar o cache. A inicialização é feita através NCache.Cliente. CacheManager.GetCache, então, é assim que você se conecta a ele. Você obtém um identificador de cache e, usando esse identificador de cache, pode configurar uma expiração baseada em tempo. Dê o objeto que é cliente neste caso, AdicionarObjectToCache e estamos conseguindo um cliente. Então você diz cache.Add um item de valor-chave é adicionado. Assim, o objeto do cliente seria serializado automaticamente enquanto você adiciona no cache e, em seguida, a recuperação é por meio de cache.Get, update por meio de cache.Insert, onde você pode alterar alguns valores. Altere o tempo de expiração e então você pode chamar cache.Remove para remover os dados também.
Então, dentro desta amostra se rapidamente. Tudo bem. Então, está obtendo o cache das configurações do aplicativo. Se eu der o nome desse cache para asp core cache, isso começará a usar o mesmo cache para cache de dados e você já viu isso onde eu usei o mesmo cache em diferentes aplicativos, mas, se for um grande aplicativo usando todos esses recursos em conjunto uns com os outros, em combinação entre si, também são suportados.
Então, enquanto isso está sendo executado, existem muitos recursos. Estou apenas mostrando um ou dois nos exemplos porque essas são apenas operações básicas e isso adicionaria alguns dados no cache. Pode não parar a qualquer momento, não tenho certeza, mas vamos ver. Enquanto isso, se eu mostrar a você, um cliente está conectado. Já fez algumas operações, né. Vamos torcer para isso. Deixe-me colocar um ponto de interrupção em algum lugar e executá-lo mais uma vez.
Então, o que ele realmente fez foi inicializar o cache, adicionar um objeto, recuperá-lo, atualizá-lo, recuperá-lo novamente, depois removê-lo e, em seguida, o cache foi descartado. Então, antes de descartar eu coloquei um ponto de interrupção, então espero que agora você possa ver os detalhes inicializados, adicionados, buscados, atualizados, atualizados no cache. Então, todos esses métodos foram executados.
Então, é assim que é simples executar esta amostra. Tudo o que você precisa é do pacote NuGet e dos namespaces a serem incluídos e, em seguida, brincar com diferentes APIs, que vou mostrar aqui.
Muitos recursos estão disponíveis. Vou passar os últimos 5 a 6 minutos em diferentes recursos, que estão disponíveis como parte do nosso NCache APIs. Assim, você pode usar a expiração baseada no tempo. Expiração absoluta e deslizante está disponível. Absoluto é quando você dá um tempo adiantado e os dados seriam removidos após esse tempo. Deslizar é, se você continuar usando esses dados, digamos que você tenha 10 minutos de expiração deslizante, se você não acessar esse item por 10 minutos, só então ele é removido. Caso contrário, ele permaneceria no cache, se você continuar usando esse objeto.
Você pode sincronizar seu cache com banco de dados. Qualquer alteração no conteúdo do item em cache, certo. Por exemplo, o item em cache qualquer alteração no registro do banco de dados. Se você tiver itens armazenados em cache que pertencem ao banco de dados, qualquer alteração no banco de dados invalidaria o item do cache e temos uma dependência SQL para isso, que é baseada em eventos. Temos dependência baseada em banco de dados, dependência de pesquisa de banco de dados, que é baseada em pesquisa. Ele agrupa para alterações e, se encontrar que alguns registros no banco de dados foram alterados, removerá os itens correspondentes do cache. procedimentos armazenados .NET CLR, onde você pode fazer NCache Chamadas de API diretamente dos servidores de banco de dados. Você também pode sincronizar seu cache com bancos de dados não relacionais. Dependências de arquivo disponíveis. Você pode tornar os itens de cache dependentes dos arquivos. Ou também pode ser uma dependência personalizada, onde você executa um registro de código com NCache e isso determinaria se esse item deve ser expirado do cache. Portanto, com base em sua lógica de negócios, você pode expirar itens do cache. Temos dependência de base de chave. Você pode usar isso para lidar com relacionamentos entre itens armazenados em cache. Assim, relacionamentos um-para-um, um-para-muitos e muitos-para-muitos podem ser gerenciados dentro NCache.
Suporte do lado do servidor, suporte de código é muito extenso. Você pode usar o padrão de cache paralelo ou pode usar o padrão Read-through e Write-through, onde você lê no cache, a partir do cache e, se os dados não estiverem no cache, você pode ler o cache executando seu provedor. É uma interface que você implementa e registra conosco e pode ler o cache e obter esse item ou destruí-lo do banco de dados de back-end.
E write-through é o oposto disso, onde você atualiza o cache e também pode atualizar automaticamente o banco de dados de back-end chamando seu manipulador de write-through, uma interface que você implementa e registra e write-behind atualizaria o banco de dados de back-end de forma assíncrona, o que é muito rápido em comparação, onde você não precisa nem para operações de gravação, seu item de cache será atualizado apenas no cache e seu aplicativo retornará e nos bastidores, o cache atualizará os bancos de dados de back-end.
Grupos, subgrupos estão disponíveis. Você pode criar coleções lógicas dentro NCache. As etiquetas são suportadas. Você pode anexar palavras-chave nos itens e pode recuperar, remover ou buscar ou até mesmo brincar ou pesquisar itens com base em sua tag correspondente.
As pesquisas do tipo SQL estão disponíveis. As pesquisas SQL e LINQ são suportadas. Você pode pesquisar itens com base em seus atributos. Você pode executar um critério de pesquisa, que pode ser algo como selecionar produtos em que produto é o tipo de objeto onde e dizer selecionar produtos em que produto.preço é maior que 10 e produto .preço é menor que 100. Portanto, com base em seus critérios especificados NCache formularia o conjunto de resultados em suas aplicações.
E também há suporte para consultas LINQ. Estes são paralelos. A indexação de dados é suportada como parte disso. Você precisa disso como uma obrigação que torna muito rápida a pesquisa de NCache.
Mensagens e eventos do Pub/Sub
As mensagens e eventos do Pub/Sub são um recurso separado. Nós temos uma plataforma de mensagens Pub/Sub orientada a eventos assíncronos. Temos consulta contínua baseada em critérios, onde você pode mapear um conjunto de dados e obter eventos desse conjunto de dados. Por exemplo, você pode mapear todos os produtos, onde os preços dos produtos são inferiores a 100. Então, esse pode ser seu conjunto de dados. Qualquer alteração nesse conjunto de dados você seria notificado.
Os principais eventos de base estão disponíveis. Assim, você pode ser notificado se um item for atualizado ou removido ou pode ser no nível de cache onde todos os itens estão sendo monitorados.
Cluster de cache dinâmico
Finalmente alguns detalhes sobre NCache agrupamento. É baseado no protocolo de cluster de cache dinâmico. NCache permite adicionar ou remover servidores em tempo real. Portanto, não há um único ponto de falha. Caso algum servidor fique inativo, ele é gerenciado dentro do protocolo. Se você adicionar mais servidores, ele começará automaticamente usando o servidor recém-adicionado. Se um servidor ficar inativo, você não terá tempo de inatividade, mesmo nesse caso, e não haverá um único ponto de falha, principalmente porque existem vários servidores hospedando esse cache.
Adicionar e remover servidores é simples, no que diz respeito aos seus aplicativos. Dá a você 100% de tempo de atividade, um cenário de cache altamente disponível e, em seguida, já cobrimos as topologias.
Temos alguns Cache de cliente. Replicação de WAN recursos. Você pode ter replicação site a site entre sites ativos-ativos ou ativos-passivos. Isso também é gerenciado.
Então, você sabe que a lista continua. Acho que cobrimos muitos detalhes e gostaria de fornecer uma visão geral rápida de como você pode realmente utilizar NCache em ASP.NET Core. Então, já estamos caminhando para o final desta apresentação. Acho que um marcador de hora.
Eu acho que vamos concluir isso neste ponto. Por favor, deixe-me saber se há alguma dúvida até agora? Caso contrário, vou entregá-lo a Zack e ele poderá continuar a partir daí. Alguma pergunta? Deixaremos o chão aberto por cerca de um minuto. Se você tiver alguma dúvida ou ainda estiver pensando em alguma, fique à vontade para jogá-la fora.
E enquanto estamos nisso, cobrimos praticamente todos esses recursos que você está vendo. ASP.NET Core Sessões, Cache de Resposta, SignalR Backplane, IDistributedCache, Cache de Dados e Direct NCache Chamadas de API e ainda temos aplicativos de amostra para Pub/Sub Messaging. Se você estiver interessado separadamente nesta seção, também poderá obter um aplicativo de amostra separado disponível.
Questão: Esta apresentação estará disponível mais tarde?
Sim será. Poderemos não apenas obter uma gravação do webinar, mas também teremos os slides disponíveis se você quiser baixá-los e usá-los, e você receberá um e-mail com um link para o webinar gravado assim que estiver pronto. Portanto, você sempre pode acessar nosso site quando estiver ao vivo e, nos webinars gravados, você poderá encontrá-los.
Questão: Qual é a diferença entre IDistributedCache e NCache ASP.NET Core Provedor de armazenamento de sessão?
Ok, então, acredito que a questão seja mais focada na diferença de uso da sessão através do IDistributedCache e Session use-o através do nosso provedor de cache. Portanto, em um alto nível, o IDistributedCache é limitado em termos de funcionalidade. NCache provedor lhe dá mais controle. Em primeiro lugar, você pode usar o bloqueio de sessão. A sessão IDistributedCache é um armazenamento baseado em não bloqueio. Você pode usar sessões de site único e de vários sites. Esse é um recurso específico dentro NCache que não está disponível em IDistributedCache. Embora, NCache suporta IDistributedCache Session Provider como está. Ele oferece muitos benefícios em cima do IDistributedCache, mas quando comparamos as sessões do IDistributedCache com NCache e você sabe, NCache Provedor de armazenamento de sessão com NCache, Isso e onde NCache provedor tem uma vantagem clara. Depois, há muitos recursos, como compartilhamento de sessão entre diferentes aplicativos. Há um atributo de ID do aplicativo de sessão que você pode especificar. Suas exceções podem ser registradas no log de eventos, logs de cache podem ser criados, logs de cliente podem ser criados. Portanto, há uma enorme lista de recursos que são diferentes entre esses dois.
Portanto, é altamente recomendável que, se você estiver usando o cache de sessão com NCache, então eu pessoalmente recomendaria revisar nosso provedor de armazenamento de sessão em comparação com a Sessão IDistributedCache com NCache porque você tem muitos benefícios.
Questão: Como o agrupamento de dados pode facilitar a recuperação desses dados?
Certo. Então, você anexa um grupo a vários itens e, em seguida, há APIs baseadas em grupo onde você diz obter dados de grupo e obtém todos esses itens de uma só vez. Portanto, você não precisa fornecer chaves desses objetos individuais separadamente. Assim, com uma chamada de API, todos os dados do grupo podem ser recuperados. Você pode remover dados em uma chamada de API. Então, é assim que o processo de recuperação e atualização é mais fácil em comparação.