DEVinterseção 2016

Dimensionamento de aplicativos .NET com cache distribuído

Por Iqbal Khan
Presidente e Evangelista de Tecnologia

Seus aplicativos .NET podem enfrentar gargalos de banco de dados ou armazenamento devido ao crescimento na carga de transações. Saiba como remover gargalos e dimensionar seus aplicativos .NET usando cache distribuído. Esta conversa abrange:

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

Visão geral

Olá pessoal. Meu nome é Iqbal Khan. Eu sou um evangelista de tecnologia na Alachisoft. Somos uma empresa de software com sede na área da baía de São Francisco. NCache é o nosso principal produto que é um cache distribuído e este é o meu tópico de hoje. Meu tópico não é sobre NCache hoje, seu cache em geral. NosDB é outro produto que temos, é open source NoSQL database para .NET. Vou usar o Azure para demonstrar o cache distribuído para que vocês possam ver como ele é realmente usado.

Portanto, o tópico de hoje é dimensionar aplicativos .NET para armazenamento em cache distribuído. Eu prefiro ter uma discussão mais interativa. Então, como eu estou falando, se vocês tiverem uma pergunta, por favor, levantem a mão. Então, podemos falar sobre isso naquele momento, em vez de esperar até o fim. Acho que isso torna a conversa muito mais significativa.

Então, deixe-me começar. Ok! Então, vamos passar por algumas definições. Tenho certeza que a maioria de vocês já sabe disso, mas isso é para fins de conclusão.

AMPLIAR

A primeira definição é escalabilidade. A escalabilidade é o alto desempenho do aplicativo sob cargas de pico. Portanto, se você tiver, digamos, um aplicativo ASP.NET ou qualquer aplicativo .NET que funcione super-rápido, com, digamos, cinco usuários, não é necessariamente escalável. Claro, se ele não funcionar rápido com cinco usuários, você terá outros problemas além disso. Mas a maioria dos aplicativos funciona super-rápido com cinco usuários, mas é quando você chega a 5,000 ou 50,000 ou 500,000 usuários que as coisas realmente começam a falhar. Portanto, se você deseja que seu aplicativo seja escalável, ele deve funcionar sob cargas de pico.

Escalabilidade Linear

Escalabilidade linear significa que sua arquitetura de aplicativo, sua estratégia de implantação, se for feita de forma que a adição de mais servidores ofereça uma capacidade incremental de lidar com mais transações do que você é linearmente escalável.

Isso significa que se você tivesse dois servidores e se você adicionar, digamos mil usuários com um servidor de três, você deveria ter 1500 usuários ou algo assim.

Escalabilidade Não Linear

Mas, se o seu aplicativo, se sua arquitetura ou implantação não for linearmente escalável, ele se parecerá mais com uma curva logarítmica que sobe e desce, o que significa que, depois de um certo ponto, não importa se você adicionar mais servidores.

Vai desacelerar as coisas. Se você tiver mais transações, simplesmente não poderá sair. Você não pode comprar-se fora desse problema. Portanto, você deseja não apenas escalabilidade, mas também escalabilidade linear.

Quais aplicativos precisam de escalabilidade?

Os aplicativos a seguir são os que geralmente apresentam esses tipos de problemas. Estes são aplicativos da Web ASP.NET, esses são serviços da Web, são back-end da Internet IOT que geralmente também é serviços da Web, você pode ter processamento de big data que geralmente não é tão comum em .NET, mas o processamento de big data também é algo que precisa ser dimensionado ou qualquer outro aplicativo de servidor. Você pode ser uma instituição financeira que tem um requisito de conformidade para processar determinado número de transações.

Portanto, você pode ter um aplicativo de servidor que tenha um requisito de conformidade para, digamos, se você for um aplicativo de transferência bancária, precisará transferir os fundos para o próximo dia útil ou em um determinado horário. Então, você precisa ser capaz de processar mais e mais transações. Então, se você tem um desses aplicativos, veio ao assunto certo.

O problema de escalabilidade

Então, vamos definir o problema de escalabilidade. A maioria de vocês sabe que suas arquiteturas de aplicativos hoje, se você tiver um aplicativo ASP.NET ou de serviços da Web, a arquitetura das escalas de camada do aplicativo varia linearmente. Então, você pode adicionar mais servidores, geralmente não há problema. O problema realmente é com seu armazenamento de dados e, quando uso a palavra armazenamento de dados, quero dizer bancos de dados relacionais e mainframe. Existem dados legados. Qualquer armazenamento de dados que você usava tradicionalmente e que se torna um gargalo e quando se torna um gargalo, você tem esse problema. o NoSQL databases, eu deveria dizer que nem sempre são a resposta. Mas NoSQL movimento começou em parte por causa disso. Como os bancos de dados relacionais não eram escaláveis, NoSQL databases são escaláveis, mas não são bons em todas as situações porque, você sabe, eles exigem que você mova todos os seus dados do banco de dados existente para um NoSQL database que você pode fazer isso para muitos dados novos, mas os dados comerciais tradicionais, seus clientes, suas contas, todos esses dados precisam permanecer relacionais por motivos comerciais e técnicos. Razões técnicas, claro, são que um banco de dados relacional tem um ecossistema que não é correspondido por nenhum NoSQL database e razões comerciais são, obviamente, da mesma natureza.

Assim, o NoSQL database nem sempre é a resposta e mesmo que tenhamos NoSQL database produto que vendemos é chamado NosDB, que é usado apenas como um aumento de bancos de dados relacionais. Portanto, você não pode sair dos bancos de dados relacionais. Os bancos de dados relacionais vieram para ficar. Então, você precisa conviver com essa realidade. Portanto, você precisa resolver a escalabilidade com bancos de dados relacionais ainda em cena.

A solução de escalabilidade

A solução, claro, é que você deve usar um cache distribuído na memória. NCache é uma dessas soluções. É um cache distribuído de código aberto. Somos o cache distribuído .NET mais antigo do mercado. Nós existimos nos últimos 10 anos, na verdade 11 agora. E somos o único cache .NET realmente nativo.

A maioria de vocês já ouviu falar Redis, direita? Então, há mais de 2 anos, nunca ouvimos falar de Redis porque eles não estavam realmente focados nisso. Não foi até que a Microsoft fez uma parceria com eles para o Azure.

Implantação de cache distribuído

O benefício de um cache distribuído na memória é que você pode usá-lo com seus bancos de dados existentes. Assim, você pode resolver esse problema que seus bancos de dados relacionais estão fornecendo a você por meio de um cache distribuído na memória. Então, como você resolve esse problema? Você resolve esse problema, vamos ver essa foto aqui.

Portanto, você tem uma camada de aplicativo que é seus aplicativos da Web, seu serviço da Web, qualquer outro aplicativo de servidor e pode adicionar mais servidores aqui. Para aplicativos da Web e serviços da Web, geralmente há um balanceador de carga lá em cima que não desenhei nisso. Assim, você pode adicionar mais servidores nesta camada. Você não pode adicionar mais servidores na camada de banco de dados. Sim! Você pode adicionar mais servidores no NoSQL camada, mas, como eu disse, nem sempre é a resposta. Então, você tem que resolver essas duas caixas. Portanto, você coloca um cache distribuído na memória entre a camada do aplicativo e o banco de dados.

O cache distribuído geralmente forma um cluster. Portanto, nem todos os caches distribuídos formam um cluster. Memcached nunca formou um cluster mesmo sendo um cache distribuído. Redis forma um aglomerado, NCache definitivamente forma um cluster. Um cache distribuído forma um cluster de dois ou mais servidores aqui. A razão pela qual digo dois é para fins de redundância e para replicação e para muitos outros e também para fins de escalabilidade. Se você precisar apenas de um servidor de cache, provavelmente não precisará de um cache distribuído. Portanto, você deve ter no mínimo dois servidores de cache aqui e esse cluster de cache realmente agrupa a memória e os recursos de CPU de todos os servidores de cache em uma capacidade lógica. O que isso significa é que, à medida que você adiciona mais servidores, obtém mais memória, mais processamento de CPU e mais capacidade de placa de rede. Esses são os três gargalos da escalabilidade; memória, CPU e placa de rede. Placa de rede nos dias de hoje são … um gigabit ou dez gigabits é praticamente o padrão. É muito difícil atingir o máximo de um cartão gigabit ou dez gigabits, a menos que os tamanhos dos objetos sejam grandes. Mas, se o tamanho do seu objeto for grande, grande significa centenas de kilobytes por objeto, então é muito fácil maximizar uma placa de rede se você tiver muito tráfego. Mas, se você tiver mais servidores e, claro, mais placas de rede, a memória será da mesma maneira.

A razão pela qual é um cache distribuído na memória é porque a memória é muito mais rápida que o disco e é isso que realmente agrega valor. É mais rápido, é mais escalável. Portanto, o objetivo aqui é capturar cerca de 80% do acesso do aplicativo que vai para o cache distribuído. Assim, restarão apenas 20% para ir para o banco de dados.

Muitas pessoas inicialmente viram o cache como um aumento de desempenho. Sim! É um aumento de desempenho porque na memória é mais rápido do que isso. Mas, mais importante, é uma necessidade de escalabilidade porque você não pode escalar sem algo assim em sua infraestrutura. Na verdade, mais e mais empresas estão quase tornando um padrão que, assim como eles terão um banco de dados em seu ambiente de aplicativos, eles também terão um cache distribuído. Algumas pessoas chamam de grade de dados na memória que está no lado Java, esse é um termo. Algumas pessoas chamam isso de malha de dados, mas cache distribuído é o nome mais comum para o ecossistema .NET. Então, isso é uma infraestrutura. Depois de colocá-lo no lugar, você pode usá-lo como uma ferramenta realmente poderosa. A proporção entre os servidores de aplicativos e a camada de armazenamento em cache geralmente é de cerca de 4:1, 5:1, supondo que sejam servidores bastante carregados em termos de transações. Você pode ir mais de 5:1 também dependendo da natureza destes. E, um servidor de cache típico tem cerca de 16 giga a 32 giga na memória e tipo de configuração quad core dual CPU. Portanto, não é uma caixa muito sofisticada. Na verdade, você não quer uma caixa muito sofisticada nesta camada. Você quer mais caixas do que algumas caixas muito sofisticadas. Se você adicionar mais memória, poderá ir até 128 ou 256 GB de memória, mas mais memória significa que você precisa ter uma CPU mais forte. Por que é que? Porque, se você tiver mais memória, seu heap será maior, sua coleta de lixo será uma tarefa muito maior e a coleta de lixo não é a coisa mais rápida no .NET e consumirá sua CPU. Assim, você se parece cada vez mais com um banco de dados. Então, é melhor ter 16 a 32 giga é um bom ponto ideal por servidor de cache. Alguma dúvida até agora?

NCache Números de escalabilidade

Aqui estão os números de escalabilidade de NCache. Caches diferentes teriam números diferentes, mas o objetivo é que isso seja escalável. Então, as leituras escalam dessa maneira que as gravações estão escalando isso. As leituras são mais lentas que as gravações porque a replicação acontece com as leituras. Vou falar sobre essas capacidades.

A razão pela qual você precisa de replicação é porque a memória é volátil. Portanto, se algum servidor cair, você perderá esses dados. Então, você não quer perder esses dados em muitos casos.

Usos comuns do cache distribuído

O objetivo da palestra até agora era meio que mostrar por que você precisa de cache distribuído. E, agora que estabelecemos esse caso, vamos falar sobre para que você usará um cache distribuído.

Cache de dados do aplicativo

O caso de uso mais comum é o que eu estava falando, que é um cache de dados do aplicativo. Você armazena em cache os dados que existem em seu banco de dados, bem aqui. Assim, você armazena em cache o máximo possível e melhora seu desempenho e escalabilidade.

A principal coisa a ser observada no caso de uso de cache de dados do aplicativo é que os dados existem em dois lugares. Um no banco de dados, um no cache. Sempre que isso acontece, qual é a primeira preocupação que vem à sua mente de que o que poderia dar errado se existisse em dois lugares? Sim, consistência!

Portanto, é muito importante que um bom cache distribuído lide com isso. Porque, se um cache não for capaz de lidar com o fato de que os dados devem ser consistentes em ambos os locais, você será forçado a armazenar em cache mais dados somente leitura. Os dados somente leitura são cerca de 10% a 15% ou 20% dos dados. A maioria dos dados é o que chamo de dados transacionais. Estes são seus clientes suas contas. Esses são os dados que estão mudando. Pode mudar a cada poucos segundos, embora na maioria das vezes possa mudar a cada dois minutos. Portanto, mesmo que você pudesse armazená-lo em cache por um minuto ou 30 segundos, ainda se beneficiaria de lê-lo várias vezes e se multiplicar isso pelo número total de transações que estão acontecendo em um determinado dia, você terá milhões de transações que não vão mais para o banco de dados. Portanto, é muito importante que, para o armazenamento em cache de dados de aplicativos, um bom cache distribuído lide com essa consistência e eu vou falar sobre os recursos que são realmente importantes para ter essa consistência. Portanto, o cache de dados do aplicativo armazena em cache os dados permanentes. Dados permanentes significam que existem em seu banco de dados permanentemente.

Cache específico do ASP.NET

O segundo caso de uso é que, se você tiver um aplicativo ASP.NET, isso também se aplica a outros aplicativos da Web, mas estou focando no .NET. Você pode armazenar em cache seu estado de sessão, seu estado de exibição, se não estiver usando a estrutura MVC e pode armazenar em cache sua saída, a saída da página. Todos esses dados são temporários por natureza. Não é permanente. Quaisquer dados que não sejam permanentes não devem realmente existir no banco de dados. É um dado transitório.

Quando os dados são transitórios, quando são temporários e não existem no banco de dados, existem apenas no cache, qual é a maior preocupação que vem à mente de que o que poderia dar errado? Persistência... Ou falta dela. Então, se você não persistir, você perde dados. E se esse servidor de cache cair e você tiver essa cesta de compras ou qualquer outra coisa e digamos que você seja uma companhia aérea e esse seu cliente acabou de fazer essa pesquisa de voos e eles vão comprar 10 passagens ou quatro passagens no valor de pelo menos US $ 5,000 e a última página eles dizem enviar ou qualquer que seja a última página e de repente a sessão se foi porque o servidor de cache caiu e eles têm que começar tudo de novo. Toda a atividade é perdida. Você pode perder esse cliente. Não é uma experiência muito boa.

Portanto, qualquer coisa que você armazenar em cache que seja transitória, o cache deverá replicar. Qualquer cache que não faça replicação, não é um cache viável. E, a replicação tem custo, portanto, o cache deve fazer uma replicação eficaz e eficiente. O estado de sessão é um caso de uso muito comum para um cache distribuído porque as sessões são muito comuns no ASP.NET.

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

O terceiro caso de uso comum ou o terceiro que, na verdade, não é muito conhecido é chamado de compartilhamento de dados em tempo de execução. Isto é, se você tiver vários aplicativos que precisam compartilhar. Um aplicativo produz algo ou atualiza algo que outro aplicativo ou outra instância desse aplicativo precisa usar. Normalmente, você usaria filas de mensagens para isso tradicionalmente ou apenas colocaria esses dados no banco de dados e o outro aplicativo puxaria. Mas, um cache distribuído é muito bom para esse caso de uso. Não existe para substituir as filas de mensagens. As filas de mensagens têm outro uso, mas se seu aplicativo estiver sendo executado no mesmo datacenter, todas as instâncias e eles precisarem compartilhar dados, essa é uma plataforma de compartilhamento de dados ou dados muito mais escalável, porque todos os aplicativos estão conectados à mesma plataforma e isso platform pode acionar eventos, em um modelo Pub/Sub. Pub significa que um aplicativo é o editor, eles publicam algo e disparam um evento. Todos os assinantes disso serão notificados e consumirão esses dados.

Há também outros tipos de notificações. Quando determinados itens são modificados, seu aplicativo pode mostrar interesse em determinados itens e se esse item for alterado, avise-me. Ou há um consulta contínua característica que NCache tem que é como um Dependência SQL recurso no servidor SQL, onde NCache permite que você diga um tipo de consulta SQL que diz SELECTS Customers WHERE Customers.City = "New York". Portanto, se algum cliente com este critério já adicionou, atualizou ou removeu o cache notificado.

Portanto, é uma maneira muito mais inteligente de monitorar as alterações no cache. Portanto, todas essas coisas permitem que você compartilhe dados entre aplicativos de maneira muito rápida e escalável em tempo de execução. E também são dados transitórios, embora muitos desses dados existam no banco de dados, mas a forma em que você os está compartilhando provavelmente não. Então, é transitório. Então, isso também deve ser replicado. Alguma dúvida até agora? Ou vocês já conhecem essas coisas completamente ou eu sou super bom.

Visão geral do cache de dados do aplicativo

Então, vamos ver alguns códigos-fonte em termos de como... quais são os recursos que você deve usar e como usá-los. vou usar NCache como o exemplo, mas como eu disse meu foco é mais nos recursos reais.

Aqui está uma maneira típica de usar qualquer cache.

Customer Load(string customerId)
{
    // Key format: Customer:PK:1000
    string key = "Customers:CustomerID:" + customerId;
    
    Customer cust = (Customer) _cache[key];
    
    if (cust == null)
    {
        // Item not in cache so load from db
        LoadCustomerFromDb(cust);
        // Add item to cache for future reference
        _cache. Insert(key, cust);
    }
    return cust;
}

Você carregaria um cliente de um banco de dados. Antes de ir para o banco de dados, você verificará o cache e usará a chave, uma chave baseada em string. Vamos diz Clientes: CustomerID e o ID do cliente real pode ser 1000 ou algo assim e você diz para verificar o cache. Se você tem no cache não precisa ir ao banco de dados, você tem. Se você não tiver no cache, você vai para o banco de dados, carrega esse cliente e o coloca no cache. Quando o colocares na cache, da próxima vez que vieres, tu ou qualquer outra pessoa que o vieres encontrarás na cache. Então, esse é um paradigma muito simples. Depois de fazer isso, todos encontram coisas que valem mais do que o cache.

É claro que há muitos outros recursos que você pode pré-preencher o cache com muitos dados que você acha que são bons para serem necessários de qualquer maneira. Portanto, você economizará muitos acessos ao banco de dados antecipadamente e ainda continuará adicionando dados ao cache que não são encontrados no cache. Por exemplo, aqui está um projeto de estúdio visual. Se você fosse usar NCache você ligaria dois desses conjuntos. Um é NCache.Tempo de execução e um é NCache.Rede. Você usará dois dos namespaces aqui da mesma forma NCache.Tempo de execução e NCache.Web.Caching. Nomeamos nossos namespaces para serem bastante próximos do cache do ASP.NET. Então, que você saiba, quando NCache saiu cache ASP.NET era o único cache disponível. Então, você tem isso e no início do seu aplicativo, este é um aplicativo de console, é claro, o seu será diferente. Você se conectará ao cache e obterá um identificador de cache. Cada cache é nomeado e você tem um identificador de cache e, em seguida, adiciona seus objetos ao cache. Então, digamos, você acabou de adicionar, você faz cache.Adicionar aqui. Você especifica sua chave. Embora isso provavelmente não deva ser David Jones, deve ser algum tipo de ID do cliente e, em seguida, você tem o objeto real e, em seguida, especifica as expirações. E você especifica as expirações absolutas de um minuto. Você está dizendo que após um minuto expirar este item do cache. Todo o resto você apenas manteve no padrão. E, mais tarde, você pode fazer cache.Obter e obter esse mesmo cliente de outro lugar. Portanto, apenas operações simples de cache.

using System;
using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.sample.data;

namespace BasicOperations
{
    public class BasicOperations
    {
        public static void Main(string[] args)
        {
            try
            {
            //Initialize cache via 'initializeCache' using 'Cache Name'
            //to be initialized. 
            Cache cache = NCache.InitializeCache("demoCache");
            cache.Clear();

            //Another method to add item(s) to cache is via CacheItem  object
            Customer customer = new Customer();
            customer.Name = "David Johnes";
            customer.Age = 23;
            customer.Gender = "Male";
            customer.ContactNo = "12345-6789";
            customer.Address = "Silicon Valley, Santa Clara, California";

            DateTime calendar = new DateTime();
            calendar.AddMinutes(1);

            //Adding item with an absolute expiration of 1 minute
            cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
            Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
            ...

Demonstração prática

No caso de NCache, todos os caches são nomeados. Agora vou mostrar rapidamente como é um cache e depois voltaremos ao código. Configurei várias VMs no Azure. Então, você pode correr NCache no Azure, na Amazon, local. Em todos os casos, os próprios servidores de cache são apenas VMs. Isso é apenas VMs do Windows 2008, 2012. O cliente de cache no Azure pode ser uma VM, uma função da Web, uma função de trabalho ou um site.

Criar um cache clusterizado

Eu entrei no cliente de demonstração, bem aqui. Eu vou agora ir rapidamente e criar um cache. Então, eu posso mostrar como é o cache. Use esta ferramenta chamada de NCache Gerente, ferramenta gráfica e permite que você… Eu vou vir aqui e dizer que crie um 'Novo Cache Clusterizado'.

Todos os caches em NCache são nomeados. Então, vou apenas nomear meu cache. Eu vou levar todo o resto como padrão neste momento.

Vou escolher uma topologia para a réplica particionada. Falarei rapidamente sobre isso no final desta palestra. Réplica particionada é minha topologia.

Vou usar a Replicação Assíncrona.

Vou escolher meu primeiro servidor de cache, que é o demo2. Então, esses são dois meus nós de cache.

Eu vou clicar em Avançar. Vou pegar todos os padrões. Vou especificar quanta memória quero alocar para esse cache. Então, dessa forma o cache não consumirá mais memória do que isso. Acabei de dar um show, mas é claro que o seu vai ser muito maior. Esse é o tamanho de uma partição.

Então, uma vez que o cache usa tanta memória, o cache está cheio. Portanto, ou ele rejeitará quaisquer novos itens ou despejará alguns dos itens existentes. Então, vou dizer, elimine 5% do cache nisso e direi que o uso menos recente é o algoritmo a ser usado e acabei de criar o cache.

Vou em frente e adicionar um cliente a isso.

Então, acabei de criar um cache e vamos iniciar o cache.

Simule o estresse e monitore as estatísticas de cache

Eu vou escolher as estatísticas, então, posso usar algumas estatísticas do PerfMon. Também vou monitorar o cluster. Então, acabei de iniciar o cache. Esse cache é chamado de cache de demonstração. Vou testá-lo rapidamente. Então, acabei de executar uma ferramenta de teste de estresse que vem com NCache e permite que você teste rapidamente o cache em seu próprio ambiente.

Então, esse cache agora está funcionando. Então, o que está acontecendo é que, na caixa do cliente, e o cliente significa a caixa do servidor de aplicativos, eu tenho um arquivo de configuração, bem aqui. Então, acabei de criar o cache e agora ele sabe quais são os servidores de cache. Agora, deixe-me voltar ao código. Então, quando eu realmente escolhi esse nome de cache, foi isso que realmente aconteceu, meu aplicativo agora se conectou a todos os servidores de cache no cluster e me deu um identificador de cache, para que, quando eu fizer um cache.Adicionar, na verdade vai adicioná-lo ao local apropriado no cache e também fazer a replicação tudo para mim, tudo isso é feito.

Então, a API esconde todos esses detalhes, mas eu queria mostrar como é esse cache nos bastidores e como é fácil usar o NCache nessa situação. Então, vamos voltar ao nosso principal. Aqui está a aparência da API.

• Conexão de cache

  ICache cache = CacheManager.GetCache(“myDistributedCache”);
  cache.Dispose();

• Buscando dados

  Employee employee = cache.Get<Employee>("Employee:1000"); 
  bool isPresent = cache.Contains("Employee:1000");

• Gravando dados

  cache.Add("Employee:1000", employee);
  cache.AddAsync("Employee:1000", employee);
  
  cache.Insert("Employee:1000", employee);
  cache.InsertAsync("Employee:1000", employee);
  
  Employee employee = (Employee) cache.Remove("Employee:1000");
  cache.RemoveAsync("Employee:1000");

Você faz um cache.Obter, cache.Contém, cache.Adicionar, Inserir, Remover. Inserir significa adicionar se não existir, caso contrário, atualizar.

Recursos de cache de dados do aplicativo

OK, agora que temos uma ideia de como é um cache, o que é uma API simples. Vamos ao recurso sobre o qual falamos. Que são importantes para um cache distribuído.

Mantenha o cache atualizado

Então, a primeira coisa que dissemos é que um cache distribuído deve manter os dados atualizados, o cache atualizado. Então, existem quatro maneiras de fazer isso. O número um é expiração, que muitos caches têm quase todos os caches, permitindo que você expire coisas.

Então, há um Expiração Absoluta e há um Expiração deslizante. Expiração Absoluta é o que acabei de mostrar, ou seja, diz expirando este item, vamos daqui a cinco minutos, independentemente do que acontecer. E, a razão pela qual digo isso é porque, como eu disse, esses dados existem no banco de dados e só posso confiar neles por cinco minutos que não serão alterados no banco de dados. Eu não quero mantê-lo por mais do que isso no cache, porque ele pode mudar no banco de dados. Então, você está fazendo um palpite sobre a natureza dos dados. Alguns dados podem ser armazenados em cache por horas e dias. Você sabe, esta pode ser a sua tabela de pesquisa. Pode ser que seus preços mudem uma vez por dia ou algo assim. Então, você pode armazenar isso em cache por 24 horas.

Outros dados são seus dados transacionais. Você pode armazená-lo apenas por talvez 30 segundos ou um minuto, desde que você se sinta confortável. Portanto, a expiração absoluta é para dados permanentes e é uma maneira de você estimar ou adivinhar por quanto tempo é seguro manter os dados no cache. Isso é muito importante. Distinção que quero fazer entre as expirações absolutas e o deslizamento.

A expiração deslizante basicamente diz para remover este item do cache quando ninguém mais estiver tocando nele, para esse intervalo. Tocar significa buscar ou atualizar. Assim, por exemplo, um estado de sessão. Quando você faz logout, um estado de sessão não é mais tocado por ninguém. Portanto, após 20 minutos ou mais, ele precisa ser removido do cache.

A expiração deslizante é usada para dados transitórios, geralmente. É mais uma operação de limpeza. Não tem nada a ver com manter os dados atualizados. Tem a ver com apenas se livrar dele porque você não precisa mais dele. Mas, expiração absoluta é o que você precisa para manter os dados atualizados. Em segundo lugar, você sabe, expirações é uma coisa muito importante. Todo cache deve tê-lo e a maioria deles, aliás, acho que todos, pelo menos, expiração absoluta.

Sincronize o Cache com o Banco de Dados

A segunda característica é algo que a maioria deles não faz. E é aqui que você deseja sincronizar o cache com o banco de dados.

Usando dependências de banco de dados

Você diz, você sabe, eu realmente não posso prever com que frequência ou quando isso será atualizado no banco de dados. Não sei quando os dados serão atualizados no banco de dados. Porque, eu tenho vários aplicativos que estão atualizando. Pode ser que outras pessoas estejam tocando diretamente nos dados. Então, eu só quero que o cache monitore o banco de dados. Assim, e o cache deve estar ciente dessa alteração no banco de dados. Esta é uma característica que NCache tem. É chamado de dependência SQL. Na verdade, ele usa um recurso do servidor SQL chamado dependência SQL, onde NCache torna-se um cliente do banco de dados.

Deixe-me mostrar rapidamente como é isso. Então, se eu tiver um cache aqui. Então, novamente, da mesma forma que fizemos as bibliotecas e então você se conecta ao cache. Agora, quando você estiver adicionando o item ao cache, aqui mesmo. Se eu vier aqui e então eu digo 'AddProductToCacheWithDependency', vá para definição. Então, aqui você está dizendo para este cache, aqui está minha instrução SQL.

private static void AddProductToCacheWithDependency (Product product)
{
// Any change to the resulset of the query will cause cache to invalidate the dependent data
string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.ProductID);

//Let's create SQL depdenency
CacheDependency sqlserverDependency = new SqlCacheDependency(connectionString, queryText);

CacheItem cacheItem = new CacheItem(product);
cacheItem.Dependency = sqlserverDependency;

//Inserting Loaded product into cache with key: [item:1]
string cacheKey = GenerateCacheKey(product);
cache.Add(cacheKey, cacheItem);
}

private static string GenerateCacheKey (Product product)
{
string cacheKey = "Product#" + product.productID;
return cachekey;
}

Portanto, sua instrução SQL geralmente reflete essa linha na tabela. Portanto, se você adicionar um produto, deve ser que a instrução SQL com o ID do produto seja igual a isso. Então, você está criando esta instrução SQL para o SQL Server. Porque isso é o que você passa como parte da dependência do SQL para o SQL Server. Você vai passar para NCache. Então, você na caixa do cliente está passando isso para NCache. Então, você está especificando isso como sua instrução SQL. Você está criando um objeto 'cache Item' e dentro do item de cache você especifica a 'SQLServer Dependency'. Então, SQLCacheDependency é uma classe de NCache, na realidade. Isso não é o mesmo que a dependência do SQL Server. Isso tem o mesmo nome, exceto a dependência do cache SQL. Isso mantém essa instrução SQL, você especifica isso e adiciona o item ao cache. Então, você fez isso e está neste momento sentado nesta caixa, bem aqui.

Então, você passa isso para NCache. Ele vai para um dos servidores de cache. Este servidor de cache se torna um cliente do banco de dados agora. Porque você também especificou as informações da cadeia de conexão. Em algum lugar aqui, você especifica a string de conexão. Então, NCache servidor torna-se um cliente do seu banco de dados. Agora esse banco de dados pode ser SQL Server, pode ser Oracle e NCache estabelecerá uma conexão de dependência SQL. O SQL Server criará uma estrutura de dados dentro do SQL Server que monitorará o conjunto de dados.

Então, assim como NCache tinha aquele recurso de consulta contínua sobre o qual falei para compartilhamento de dados em tempo de execução, onde NCache estava monitorando todos os clientes, onde Cliente. Cidade = “Nova York”. Agora, o SQL Server está monitorando esse conjunto de dados no SQL Server e, se alguma linha correspondente a esse critério for adicionada, atualizada ou removida do banco de dados SQL, o SQL Server notificará o servidor de cache. O servidor de cache agora sabe que esses dados foram alterados no banco de dados. Então, ele tem duas opções. Ele pode remover isso do cache, que é o comportamento padrão, ou pode recarregar uma nova cópia.

Usando Read-Through/Write-Through

A maneira como ele recarregará uma nova cópia é, se você usar outro futuro de NCache chamado Leia. Vou pular isso e terei que voltar a isso. Então, há um recurso chamado read-through que é o seu código. Você implementa um manipulador de leitura e eu lhe mostrarei o manipulador de leitura. Então, aqui está um IReadThroughForneced.

{
    // <summary>
    // Contains methods used to read an object by its key from the master data source.
    // </summary>

    public class SqlReadThruProvider : Alachisoft.Ncache.Runtime.DatasourceProviders. IReadThruProvider
    {
        private SqlDatasource sqlDatasource;
        // <summary>
        // Responsible for loading the object from the external data source.
        // Key is passed as parameter.
        // <param name="key">item identifier; probably a primary key</param>
        // <param name="exh">Current expiration hint; you can modify the value and attach a new hint</param>
        // <param name="evh">Current eviction hint; you can modify the value and attach a new hint</param>
        // <returns></returns

        public void LoadFromSource(string key, out ProviderCacheItem cacheItem)
        {
            cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
            cacheItem.ResyncItemonExpiration = true;
            cacheItem.ResyncProviderName = sqlDatasource.ConnString;
        }
        // <summary>
        // Perform tasks like allocating resources or acquiring connections
        // </summary>
        ...

Você implementa isso. Ele tem um método Init que o inicializa. Um método Dispose e realmente como um método Get. Então, o get passa a chave e você devolve o item de cache. Então, você vai na sua fonte de dados e carrega aquele item, especifica a expiração ou qualquer outra coisa e passa de volta para NCache. Esse seu código roda no servidor de cache. Isso é uma coisa importante a ter em mente.

Então, a leitura, na verdade, é executada no próprio servidor de cache. Na verdade, eu tenho outro diagrama.

Portanto, a leitura é executada no próprio servidor de cache. Então, o servidor de cache tem que ser desenvolvido em .NET para o seu código .NET rodar nele, certo? Então, se sua loja .NET, se seu aplicativo estiver em .NET, a razão pela qual eu disse que toda a sua pilha deveria ser .NET para todos esses benefícios.

Então, chegando, por exemplo Redis, Redis é um cache baseado em Linux. Então, é um ótimo cache, não tenho nada contra eles, mas se você é uma loja .NET você precisa fazer todas essas coisas e seu código deve ser executado no servidor de cache para que o cache possa se sincronizar com o banco de dados e recarregar automaticamente esse item do banco de dados. Portanto, seu manipulador de leitura é o que é chamado quando uma dependência de SQL é acionada, se você quiser. Se você não quiser isso, ele apenas removerá esse item do cache. E, quando ele é removido do cache, na próxima vez que seu aplicativo procurar por ele, ele não o encontrará e irá buscá-lo no banco de dados. Agora, em certos casos, por exemplo, é um catálogo de produtos que você armazenou em cache e acabou de atualizar o preço. Por que remover o produto do cache, você acabou de atualizar o preço? Porque agora a aplicação tem que ter a lógica para ir buscar no banco de dados. É melhor recarregar automaticamente.

Portanto, muitos dos dados, se você acha que serão necessários repetidamente, seja para expirar ou quando a sincronização do banco de dados ocorrer, é melhor recarregá-los do que removê-los. Porque então o aplicativo não precisa fazer isso. Quanto mais isso o cache fizer, mais fácil será o aplicativo. Então, outra maneira que o cache pode se sincronizar com o banco de dados. Então, se você não tem SQL server ou Oracle, digamos, você tem MySQL ou DB2, então esses dois recursos que existem, então você pode usar a dependência de banco de dados, que é outro recurso do NCache aquele onde NCache agrupa uma tabela específica e você modifica seus gatilhos de banco de dados para atualizar o sinalizador nessa linha. NCache pega e diz que este item tem troco. Então, preciso que você o remova ou recarregue.

Usando procedimentos armazenados CLR

Os procedimentos CLR são outra maneira de sincronizar o cache com o banco de dados. Onde você realmente escreve um procedimento CLR. Você o chama do seu gatilho de tabela. Então, digamos, se você tiver um gatilho Add ou Update ou Delete. Você chama esse procedimento CLR, ele chama NCache ou chama o cache.

No caso do procedimento CLR, você precisa ter certeza de que o cache suporta métodos assíncronos que NCache faz. Assim, você pode fazer em um cache como uma chamada assíncrona de inserção e o controle imediatamente volta para você. Porque, se você não fizer a chamada assíncrona, suas transações de banco de dados começarão a expirar. Porque, você está atualizando vários servidores no cache, você está passando pela rede que não é o que uma transação de banco de dados é projetada para eles. Então, você precisa ter uma chamada assíncrona.

Então, essas são as três maneiras de sincronizar o cache. Portanto, qualquer cache que você pagou precisa ter certeza de que pode manter os dados atualizados. Estas são as duas maneiras.

Sincronize o Cache com o Não Relacional

Da mesma forma, se você tiver uma fonte de dados não relacional, digamos, você tem seus dados na nuvem ou em qualquer outro lugar. Você pode até querer fazer uma chamada de método da web. Na verdade, você pode implementar uma dependência personalizada que é novamente seu código que registra e é executado nos servidores de cache e NCache chama e diz: vá e verifique sua fonte de dados se ela mudou ou não. Você verifica a fonte de dados, se mudou você notifica NCache esses dados e a fonte de dados foram alterados. Então, NCache pode removê-lo ou recarregá-lo.

Então, novamente com um banco de dados relacional NCache faz tudo por você. Em caso de não relacional, você tem que fazer uma dependência customizada.

Lidar com Dados Relacionais

O aspecto final de manter o cache atualizado são os recursos de dependência. Digamos que você tenha um relacionamento de um para muitos entre um cliente e um pedido e esteja armazenando os dois em cache. E se o objeto do cliente for removido do cache? As encomendas devem permanecer na cache ou não? E se você realmente excluísse o cliente do banco de dados. Bem, você não costuma excluir os clientes, quando estou dizendo um para muitos. Digamos, e se o lado que você removeu do cache realmente significasse que você também poderia tê-lo removido do banco de dados. Isso significa que o lado muitos não é mais válido. Então, quem deve acompanhar tudo isso? Se a cache pode fazê-lo por si, então torna a sua vida muito mais simples.

Por exemplo, o objeto de cache ASP.NET tem esse recurso chamado dependência de cache. NCache implementou e até onde eu sei, nenhum outro cache .NET tem esse recurso. Mas, basicamente você registra a relação entre os itens e diz que isso depende deste item, caso este item seja atualizado ou removido, por favor remova este item automaticamente. Então, o cache faz a limpeza para você.

Quanto mais isso o cache fizer para você, melhor será para você, porque você pode ter certeza de que seus dados serão atualizados. Depois de ter essa confiança, você pode armazenar em cache praticamente todos os dados. É apenas uma questão de qual estratégia você usará para manter os dados atualizados.

Encontrando dados

Então, agora que você tem a confiança de que os dados estão atualizados, você começará a armazenar muitos dados em cache. Bem, uma vez que você começa a armazenar em cache todos os dados, a próxima coisa que acontece é que o cache agora está começando a se parecer cada vez mais com um banco de dados. Não é um banco de dados, é sempre um armazenamento temporário. Mas, especialmente muitos desses dados de referência, você armazena praticamente todo o conjunto de dados no cache. Quando isso acontece, você quer ser capaz de pesquisar sobre ele. Em vez de sempre encontrá-lo com base em chaves, isso é muito inconveniente. Encontrar qualquer item com base na chave nem sempre é conveniente. Você quer ser capaz de pesquisar isso por outros meios.

Uma maneira é fazer uma Pesquisa SQL. Novamente, SELECT Customers WHERE clients.City = "New York". Assim como você faria ou diria me dê todos os meus produtos desta categoria. Assim, você obterá uma coleção desses objetos do cache, não do banco de dados. Vindo do cache significa, é claro, que o banco de dados não precisa mais receber esse golpe e está tudo na memória. É muito mais rápido por vir de vários servidores ao mesmo tempo.

Então, todas essas são consultas paralelas. E, para que você possa fazer isso, o cache deve suportar indexação, o que NCache faz. Não tenho certeza se outros produtos o fazem ou não, mas verifique se o cache oferece suporte à indexação. Caso contrário, serão consultas realmente muito lentas.

Agrupamento de dados

Uma coisa que você não pode fazer em um cache é juntar vários objetos ou várias tabelas, que é o que você pode fazer no banco de dados relacional. Então, existem maneiras de contornar isso, você pode agrupar coisas, você pode marcá-las de certas maneiras que você pode recuperá-las e dessa forma você pode buscar dados com base em algumas associações lógicas ou agrupamentos que estão no cache. Então, digamos que se você armazenar tudo em cache, eu lhe darei um exemplo. Por exemplo, digamos que você tenha uma coleção de clientes de volta. Então, eu tenho uma coleção de tags de objeto e quero armazenar em cache cada objeto separadamente no cache. Mas, mais tarde, quero poder buscar tudo em uma chamada.

//Caching Query Results (Collection)
//Cache Collection Objects Separately
static void CacheSupplierProducts(NorthwindEntities context, int supplierId)
{
    Tag[] productTags = new Tag[1];
    productTags[0] = new Tag("SupplierProducts:" + supplierId);
    
    IQueryable<Product> products = context.Products;
    
    var result = from product in products
                  where product.SupplierID == supplierId
                  select product;
                  
    foreach (Product p in result)
    {
        String key = "Products:ProductId:" + p.ProductID;
        _cache.Insert(key, p, productTags);
    }
}
...
ICollection productList = _cache.GetByAnyTag(productTags).Values;

Então, ou eu emito a mesma consulta, consulta SQL e digo que me devolva todas as coisas. Mas, eu peguei esses objetos do banco de dados, não os peguei do cache. E eles não são um conjunto de dados inteiro. Digamos, qualquer conjunto que eu queria buscar naquele momento. Então, eu armazenei em cache cada objeto individualmente que eu possa precisar acessar individualmente. Mas, eu quero ser capaz de buscar tudo de volta como uma coleção. Então, eu uso o conceito de uma tag. Marquei todos com a mesma tag. E essa tag pode ser qualquer string exclusiva e eu digo que me dê todos os itens que têm essa tag. Então, em uma ligação, posso recuperar toda a coleção de volta. Então, é esse tipo de coisa que você pode fazer com tags, isso meio que compensa a falta de junções no cache.

Então, você pode fazer o agrupamento. o grupos e subgrupos. Você pode fazer Tag. Você pode fazer tags nomeadas. Tags nomeadas são essencialmente você tem uma chave e, em seguida, um valor. Se você estiver armazenando em cache, por exemplo, texto, texto de formato livre. Não há como indexar esse texto sozinho porque é texto. Portanto, você mesmo precisa criar as tags e apenas a própria tag pode não ser suficiente. Você quer ser capaz de nomear cada tag.

Então, assim como um objeto tem nomes de atributos. Assim, a tag de nome é como atributos de um objeto. Assim, o nome poderia ser cidade e o valor neste texto poderia ser Nova York ou Las Vegas. Então, você pode fazer todas essas coisas e depois buscar essas coisas e em caso de NCache pelo menos você pode usar se especificar tudo isso por meio da API ou por meio do Consulta SQL. Então, quando você está buscando algo baseado em SQL…

Primeira pergunta, ótimo! Podemos usar taxonomias hierárquicas? O que você pode fazer na verdade é... os grupos e subgrupos lhe dão apenas um nível de hierarquia. Assim, dentro de um grupo você pode ter vários subgrupos, mas não pode ir além dele.

Você pode usar diferentes tipos de tags para representar porque pode atribuir várias tags a um item. Então, por exemplo, se você tivesse várias hierarquias, você pode atribuir para cada nível que você descer, você pode atribuir todos os níveis superiores a cada nível como uma tag separada.

Mais uma pergunta. Podemos controlar a representação interna do cache? Os índices são construídos com base na combinação de tabela de hash, no caso de NCache, e árvores negras vermelhas. Você pode escolher os índices, mas não escolhe qual estrutura de dados será usada internamente. Mas, os índices são construídos com base na natureza do uso. Assim, por exemplo, as tabelas de hash são boas para certos tipos de acesso e, se você for fazer o tipo de pesquisa de intervalo, as árvores pretas vermelhas são muito melhores. Então o NCache faz isso. Eu não sei o que outros produtos fazem, mas NCache índices coisas um pouco.

Read-Through e Write-Through

Deixe-me passar rapidamente pelo leitura, escrita. Então, por que você quer ler e escrever? Lendo, vimos um exemplo disso, que é que você pode recarregar as coisas automaticamente.

Outro benefício da leitura é, obviamente, que você está consolidando o máximo de acesso aos dados no próprio cache. Quanto mais você acessa... quanto mais disso vai para o cache ou camada de cache, menos ele fica em seu aplicativo e o aplicativo se torna mais simples. O aplicativo faz apenas um cache.Obter e, claro, o outro benefício disso era que você pode carregar coisas automaticamente.

Write-through é da mesma forma. Um benefício é que você consolida todas as gravações. O segundo benefício é que você pode realmente acelerar suas gravações. Assim, por exemplo, write-behind é um recurso em que você atualiza o cache de forma síncrona e o cache atualiza o banco de dados de forma assíncrona. Portanto, se as atualizações do banco de dados não forem tão rápidas quanto o cache, o que é verdade, o desempenho do seu aplicativo melhorará repentinamente porque você atualizará apenas o cache e o banco de dados de atualizações do cache.

Portanto, o read-through e write-through e write-behind são recursos realmente muito poderosos que você deve aproveitar. Este também é o código do lado do servidor que você escreve que é executado no cluster de cache e simplifica sua vida. Assim, sua aplicação pode ter mais dados no cache e também atualizá-los através do cache.

Deixe-me, rapidamente passar por isso e falar sobre algo. Não vou entrar em detalhes de Cache de estado de sessão ASP.NET. Apenas saiba que você pode simplesmente conectá-lo sem qualquer alteração de código e apenas fazer alterações no web.config e ele automaticamente cuida disso e a mesma coisa acontece com ver estado e cache de saída.

Alta disponibilidade (100% de tempo de atividade)

Vou passar rapidamente por algumas coisas. Primeiro eu queria falar sobre... Qualquer cache que você usa, porque, é como um banco de dados, é um banco de dados in-memory em produção. Portanto, um cache deve estar altamente disponível. Você deve ter cache altamente disponível.

Cluster de cache dinâmico

NCache é altamente disponível através de algumas coisas que ele faz. Primeiro tem um cluster de cache dinâmico. Você pode adicionar ou remover servidores em tempo de execução e reajustar automaticamente o cluster. Você não precisa codificar os nomes dos servidores na configuração, os clientes automaticamente. Uma vez que um cliente fala com qualquer servidor de cache, ele obtém uma informação de associação de cluster. Se a associação for alterada em tempo de execução, digamos que você adicione um novo nó ou elimine um nó, a associação atualizada será propagada para o cliente.

Então, essa é a primeira parte que deve estar lá. É muito importante que você veja dessa forma.

Topologias de cache

A segunda é a topologia de cache. Então, existem diferentes maneiras de NCache, por exemplo, fornecerá quatro topologias de cache. A primeira é chamada de Cache espelhado. É um ativo/passivo de 2 nós.

Os segundos são chamados Cache replicado, onde cada servidor no cache tem uma cópia de todo o cache. Portanto, quanto mais servidores você tiver, mais cópias de cache você terá. É escalável para leitura, não escalável para atualizações. Mas, tem seu próprio uso com casos.

A terceira topologia é chamada Cache Particionado, onde todo o cache é dividido em partições. Cada servidor é uma partição. E essas partições são criadas automaticamente.

Assim, por exemplo, no caso de NCache cada partição tem um número de baldes dentro dela. Portanto, o cluster total tem 1,000 buckets. Portanto, se você tiver três partições, elas terão um terço, um terço de buckets.

Réplica particionada é o mesmo com a partição, mas cada partição é copiada para o servidor diferente e tudo isso é feito automaticamente para você. Portanto, ao criar um cluster de dois nós, você terá duas partições, as duas réplicas. Quando você adiciona um terceiro servidor, automaticamente, uma terceira partição é criada e quando uma terceira partição é criada, alguns dos buckets precisam ser movidos da partição existente.

Então, tudo isso é feito automaticamente para você. Uma nova réplica é criada automaticamente. Na verdade, se você vê isso a partir disso, deixe-me apenas mostrar isso, aqui. Digamos, se você tivesse uma partição de dois servidores... mas digamos, se você tivesse apenas um cluster de dois servidores, você teria duas partições. Partição 1 estava aqui e Réplica 1. Partição 2, Réplica 2. Agora, você adicionou um terceiro servidor, de repente você tem que ter uma terceira partição e isso vai pegar alguns buckets daqui, alguns outros daqui, isso é uma coisa. Segundo, a réplica 2 não estará mais aqui, ela se moverá aqui porque agora, a réplica da partição 3 tem que estar aqui.

Então, todo esse ajuste é feito automaticamente para você por NCache. Então, isso é uma coisa. Segundo, há um recurso chamado Cache de cliente algumas pessoas chamam de Near Cache, que é realmente poderoso que você deve usar. Basicamente, é um cache local dentro do seu aplicativo cliente. Mas, há uma coisa especial sobre isso é que esse cache local não está desconectado do cluster de cache. Ele está conectado ao cluster de cache. Ele se mantém sincronizado.

Então, no caso de NCache, por exemplo, o cache do cliente se conecta automaticamente nos bastidores a um arquivo config. O que quer que você busque de cada um desses aplicativos, os servidores são mantidos automaticamente no cache do cliente. Então, da próxima vez que você precisar dele, você o encontrará no cache do cliente. E o cluster de cache sabe quais dados estão em qual cache do cliente. Portanto, se esses dados forem alterados, digamos, por outro cliente, o cluster notificará todos os caches de clientes que possuem esses dados para atualizar-se. Assim, o cache do cliente permanece conectado, mas é um cache local. Pode ser até In-Proc. In-Proc significa dentro do seu processo de inscrição. Então, isso realmente acelera seu desempenho, mas ao mesmo tempo você faz parte do cache distribuído geral conectado.

Replicação de WAN

Vou pular muitas coisas, não temos tempo. Então, também há Replicação de WAN. Se você tiver vários datacenters, poderá fazer com que o cache se replique na WAN e não poderá criar um cluster na WAN. Isso só vai morrer porque esses soquetes quebram, a latência é muito alta. Portanto, deve haver alguma maneira de conectar caches em dois datacenters.

No caso de NCache temos essa coisa chamada topologia de ponte que conecta vários datacenters. Você pode ter ativos-ativos, ativos-passivos ou até mais de dois datacenters agora. E tudo isso é feito de forma assíncrona e também há resolução de conflitos feita para você. Então, como você pode ver, um cache não é apenas um simples armazenamento de valor de chave. Então, há muito que você deve ter em mente nos bastidores.

NCache vs Redis

Uma coisa que eu rapidamente queria cobrir era NCache vs Redis, apenas um nível alto, eu queria falar sobre isso. NCache é o cache .NET nativo. Ele é executado no Windows e você pode fazer o cache do lado do cliente e do lado do servidor, esse é um benefício. Enquanto que, Redis é principalmente cache baseado em Linux. Antes da Microsoft fazer parceria com eles, você sabe, a maioria das pessoas no lado .NET nem sabia que eles existiam, mesmo sendo um cache muito popular no Unix e PHP e outros ambientes.

Em segundo lugar, a versão Linux do NCache está disponível no Azure, como um Cache como Serviço. Portanto, o motivo é o cache como serviço porque, para aplicativos .NET, você não pode realmente executar o código do lado do servidor em um cache baseado em Linux. Você precisa ter um cache baseado em .NET para executar. Então, essa é uma enorme limitação que você terá.

Terceiro, se você for fazer algo fora do Azure, Redis está disponível apenas como um cache baseado em Linux. O suporte a janelas que a Microsoft fez é algo que eles mesmos não usam. Mesmo no Azure, eles não optam por usá-lo nas janelas. Não é muito estável. Há também mais detalhes se você quiser ver uma visão mais detalhada comparação entre NCache e Redis, você pode vir aqui e ver as comparações. Então, nós temos comparações com todos, porque estamos tão confiantes sobre nós.

Então, como você pode ver, esta é uma comparação completa. Basta passar por isso. Se você está pensando em usar um cache distribuído, o que deveria, você tem todas essas necessidades de escalabilidade. Faça sua lição de casa, certifique-se de que o que você usa, atende às suas necessidades. E, tanto quanto NCache está preocupado, facilitaremos a comparação NCache com outros. Você pode acessar nosso site e download NCache. É de código aberto. Então, você pode baixar a Enterprise Edition ou a Open Source aqui ou você pode ir para GitHub e você terá NCache Aqui.

Esse é o fim da minha apresentação. Alguma pergunta? Você pode passar uma chamada de procedimento armazenado. Tem que ser tudo SQL, como o material de transação SQL que será executado no próprio servidor SQL.

Sim. Assim, o cache pode estar no mesmo servidor que o aplicativo. Não recomendamos. Não é uma boa estratégia de implantação, mas se você tiver uma configuração pequena, sim, claro.

Quando você particiona, todo o particionamento é feito para você. Então, a ideia toda é que cada partição deve ter o mesmo peso, em termos de tamanho de dados, em termos de transações.

Você não controla as partições, apenas sabe que elas existem.

Ao atualizar a tabela de itens, você pode optar por atualizar o cache de dentro do próprio banco de dados, caso tenha um procedimento CLR que possa fazer uma chamada direto do banco de dados para o cache. Você também pode escrever um código separado que pode atualizar o cache e tudo o que depende de quanto você é e mantém no cache.

Então, você sabe, eu posso falar mais offline se você quiser. Mas, quero dizer, existem várias maneiras de garantir que todos os dados que você precisa acessar sejam mantidos atualizados no cache.

Sim, na verdade, vou disponibilizar os slides. Essa é a razão pela qual verificamos o e-mail de todos. Então, podemos fazer isso e também teremos o vídeo gravado e enviado. Então, você pode assistir e seus colegas também podem assistir.

Na verdade, por aplicativo ou... Na verdade, em vários aplicativos. Então, tudo depende da carga da transação. Você pode ter no mínimo 2 servidores de cache só para ter o cluster e então o número de servidores depende de quantos servidores de aplicativos você tem ou quanto, quanta atividade você tem basicamente? Quantos dados serão armazenados em cache? Quanto lê e escreve você está fazendo?

Não importa, sim. Sim, tudo continuará funcionando. Obrigado pessoal.

O que fazer a seguir?

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