Palestra no Live 360 Orlando 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
O que é Escalabilidade
Então, vamos começar com algumas definições. Tenho certeza de que a maioria de vocês já sabe disso, mas vamos repassar para fins de completude. A primeira definição é escalabilidade. Então, o que é escalabilidade? As pessoas costumam confundir escalabilidade com desempenho. O desempenho é um tempo de resposta realmente rápido por aplicativo, mas isso pode ocorrer apenas com cinco usuários e, se você levar isso de cinco usuários para cinco mil ou 50,000 usuários e esse desempenho permanecer bom, seu aplicativo será escalável. Esse é o resumo do que estamos tentando alcançar.
Em qualquer aplicativo que você tenha, se você puder obter o mesmo desempenho que teve com cinco usuários ou uma carga de transação muito baixa, se você puder obter o mesmo desempenho com alta carga de transação, você será escalável. Se você não tiver um bom desempenho com cinco usuários, terá outros problemas.
Escalabilidade Linear
A escalabilidade linear é mais uma definição de infraestrutura, que é se seu aplicativo for arquitetado de tal forma que adicionar mais servidores à implantação, seja adicionar mais servidores de aplicativos ou servidores de banco de dados ou qualquer outra coisa, se isso puder aumentar a capacidade de transação de forma linear moda, então você tem uma arquitetura de aplicativo linearmente escalável.
No entanto, se você não puder fazer isso, se adicionar mais servidores não estiver agregando nenhum valor, há algo fundamentalmente errado e você não poderá dimensionar o aplicativo de maneira linear. O objetivo aqui é, obviamente, ser capaz de escalar de forma linear.
Escalabilidade não linear
Não linear seria onde, à medida que você adiciona mais servidores, você vê um aumento, mas em um certo ponto depois disso não há mais aumento, na verdade, há uma queda de desempenho mesmo adicionando mais servidores, porque a arquitetura do aplicativo e a implantação existem alguns gargalos que você simplesmente não é capaz de superar.
Quais aplicativos precisam de escalabilidade?
Geralmente são aplicativos da web.
Então, essas são pessoas do ASP.NET para.NET, serviços da Web, back-end para a Internet das Coisas, que é um espaço emergente muito forte e processamento de big data. O processamento de big data é mais comum no lado Java. Poucas pessoas fazem isso no lado .NET, mas o processamento de big data também é outro espaço. E, qualquer outro aplicativo de servidor, este pode ser seu aplicativo de processamento em lote. Você pode ser uma empresa de serviços financeiros e você tem milhões de clientes e eles ligam e mudam de endereço ou talvez estejam transferindo fundos de uma conta para outra e como você tem certos requisitos de conformidade que no meio da noite ou algo assim você para concluir esses processamentos e há algum processamento em lote acontecendo no back-end, em um fluxo de trabalho, de certa forma. Portanto, qualquer outro aplicativo de servidor que esteja sob restrição de tempo para realizar um determinado número de transações precisa de escalabilidade.
Problema de Escalabilidade
Então, onde está o problema de escalabilidade? Falamos sobre escalabilidade linear e não linear. Portanto, o problema de escalabilidade é que a camada do aplicativo é dimensionada de maneira linear muito agradável. Se você tem uma aplicação web ou serviços web, sua camada de aplicação, basta adicionar mais servidores, sem problemas. É o armazenamento de dados que é o gargalo. E, quando digo a palavra armazenamento de dados, quero dizer bancos de dados relacionais e dados legados de mainframe. eu não quero dizer NoSQL database. NoSQL databases são ótimos. Também temos um NoSQL produto chamado NosDB mas nenhum banco de dados SQL nem sempre é a resposta. Eles são uma resposta se você puder mover quanto mais dados você mover NoSQL database é mais uma solução de escalabilidade que você obtém. Mas, o problema é que você não pode mover todos os dados para NoSQL. Há muitos dados que precisam permanecer relacionais por motivos técnicos e comerciais.
Assim, os bancos de dados relacionais vieram para ficar. Eles não vão a lugar nenhum em termos desse problema. Então, você tem que contornar essa realidade ou trabalhar com essa realidade que você vai trabalhar com bancos de dados relacionais e ainda tem que resolver esse problema. E a razão pela qual você precisa resolver esse problema é que você tem todos os aplicativos que mencionei que precisam de escalabilidade.
Implantação de cache distribuído
E, claro, a resposta é ter um cache distribuído conectado entre a camada do aplicativo e a camada do banco de dados.
Então, um cache distribuído é, essencialmente, um conceito muito poderoso e muito simples. Você tem dois ou mais servidores de baixo custo e eles são agrupados em cluster e esse cluster agrupa a memória e os recursos de CPU de todos os servidores em uma capacidade lógica. o gargalo e a escalabilidade ocorrem em três áreas. Uma é a memória, a segunda é a CPU e a terceira é a placa de rede.
Então, se você tem, digamos, um servidor de banco de dados aqui e você tem 20 caixas de camada de aplicativo que um servidor de banco de dados você pode usar em termos de força de hardware, você pode adicionar mais memória, muito mais CPUs, mas há um limite para isso. Portanto, a resposta é, para poder ter mais e mais servidores que não são muito avançados, na verdade, eles não devem ser avançados por definição. E, o que vimos nos últimos 10 anos ou mais fazendo isso é que a configuração mais comum é um tipo quad-core de CPU dupla de um equivalente. Então, digamos, uma caixa de 8 núcleos e uma caixa de 16 núcleos é na verdade uma configuração bastante sofisticada para um servidor de cache. 8 núcleos é praticamente o comum.
Memória, é claro, você precisa de muita memória porque a memória é barata, então não é um fator importante. Você precisa de muita memória, porque o cache é um armazenamento na memória, então armazena tudo na memória e, uma configuração típica seria de cerca de 16 a 32 giga de memória em cada servidor de cache e 2 servidores de cache é o mínimo que você deve ter para fins de redundância. Então, por ter essa arquitetura, agora você está em uma situação em que adiciona mais servidores na camada do aplicativo. Você adiciona mais servidores proporcionalmente na camada de cache. Então, geralmente, é uma proporção de 4 para 1 ou 5 para 1 é o que vimos como o mais prático. Em alguns casos, você pode ir muito mais do que 5 para 1. Significa 5 servidores de aplicativos para 1 servidor de cache, mas não há limite de quantos servidores você pode ter. Você pode ter 2, você pode ter 4, 10, 20, 30 servidores, mas para você ter 20 servidores aqui, você provavelmente precisa de cem servidores no ambiente do balanceador de carga.
Então, em algum momento, isso se torna um ponto alto de qualquer aplicativo que vimos na web ou e-commerce no cenário de negócios online. Então, adicionando mais servidores aqui, isso não é mais o gargalo. Então, o cache distribuído está realmente se tornando uma prática recomendada. Se você tem escalabilidade conforme a necessidade. Porque agora, não apenas você tem um banco de dados que está lá para seu próprio propósito, você precisa de persistência permanente de armazenamento de dados para todos os dados do aplicativo, mas também tem essa infraestrutura realmente rápida e escalável que faz parte da arquitetura do seu aplicativo agora. Então, quando você está programando, você não está mais apenas programando para o banco de dados. Você está sempre pensando em um cache porque o cache agora garantirá que seu aplicativo nunca fique lento, mesmo sob cargas de pico. Mesmo que o banco de dados não tenha sido projetado para ser dimensionado da mesma maneira. Então, esta é uma imagem típica.
Cerca de 80% do tráfego vai ficar preso ou será 80% do tempo você irá para o cache, 20% do tempo você irá para o banco de dados e que esses 20% são em sua maioria atualizações e claro, algumas leituras porque você precisa obter dados no cache, mas você também pode pré-preencher o cache e há muitas outras maneiras de fazer isso. Mas, reduzindo o tráfego tão drasticamente na camada de banco de dados, é assim que você obtém desempenho e escalabilidade.
Então, esse é o caso de usar um cache distribuído. Por que você deve manter isso como parte de sua arquitetura de aplicativo.
Casos de uso comuns
Então, agora que defendemos o uso de um cache distribuído, a próxima pergunta é como você o usa? Onde você usa? que tipo de uso você deve ter de um cache distribuído?
Cache de dados do aplicativo
Bem, o uso mais comum é o cache de dados do aplicativo. É aqui que, como eu estava falando, quaisquer dados que você tenha no banco de dados, você os armazena em cache. Para que você não precise ir ao banco de dados. O que deve ser lembrado, e abordarei esse ponto com mais detalhes nos slides de acompanhamento, é que, em um caso de uso de armazenamento em cache de dados de aplicativo, os dados existem em dois lugares. Um está no banco de dados que é onde sempre deve estar e o segundo é o cache. Então, sempre que os dados existem em dois lugares, qual é o primeiro problema que vem à mente? Sincronizando! Sim.
Portanto, qualquer cache que não consiga lidar com essa situação, força você a armazenar em cache dados somente leitura, dados que você sabe que nunca serão alterados. Na verdade, a maioria das pessoas quando você fala sobre cache, o pensamento instintivo que vem à mente é por que é para dados somente leitura? Eu realmente não quero armazenar em cache meus clientes e contas e dados que mudam a cada 30 segundos. Mas, a pesquisa mostra que o maior uso de um cache está nos dados transacionais e, uma vez que você o armazene, provavelmente precisará dele no próximo minuto ou dois minutos, qualquer que seja essa atividade, qualquer que seja a janela móvel de seu uso. É quando você precisa dos mesmos dados novamente e, se conseguir obtê-los do cache, está reduzindo essas viagens ao banco de dados e multiplicando isso por milhões de transações que estão acontecendo em seu aplicativo e isso se torna um aumento bastante significativo. Portanto, mantenha esse problema em mente à medida que avançamos que qualquer bom cache deve lidar com isso de maneira muito eficaz.
Cache específico do ASP.NET
O segundo caso de uso é que, se você tiver um aplicativo ASP.NET, haverá muitos dados transitórios. Transiente significa temporário e que você pode colocar no cache e esses dados não pertencem realmente ao banco de dados. Por exemplo, um banco de dados existe para permanente. É uma loja permanente. Esse é o seu registro mestre. Então, um estado da sessão, você provavelmente precisará mantê-lo apenas enquanto o usuário estiver logado, talvez 20 minutos depois, você sabe. Então, por que mantê-lo no banco de dados? Banco de dados não é tão rápido. Os bancos de dados relacionais não foram projetados para armazenar blobs e as sessões geralmente são armazenadas como blobs. Portanto, há um grande impacto no desempenho quando você armazena sessões no banco de dados. Portanto, o estado da sessão é um caso de uso muito bom para o ASP.NET colocá-lo no cache distribuído.
E, se você não estiver usando a estrutura MVC, o estado de exibição também estará lá, o que é uma parte bastante pesada de dados que flui do servidor da Web para o navegador com apenas uma finalidade, retornar ao navegador em um postback. Então, é uma viagem bem longa, para nada, como dizem. Então, seria muito melhor se você apenas o mantivesse no lado do servidor e apenas enviasse uma pequena chave. Então, esse é um caso de uso muito, muito bom para armazenamento em cache.
O terceiro caso de uso é a saída da página, muitas de suas páginas a saída delas não muda toda vez. Então, se não está mudando, por que executar a página porque quando você executa a página você está consumindo a CPU e a memória e todos os outros recursos. Por que não apenas pegar a saída da última execução e exibi-la. Assim, a Microsoft ou ASP.NET tem uma estrutura de cache de saída onde você pode conectar um cache distribuído. Então, agora neste caso de uso, nestes três casos de uso no ASP.NET, a natureza do problema mudou completamente. Não é mais sincronização entre o cache e o banco de dados. Por quê? Porque não há banco de dados. Cache é o banco de dados.
A natureza do problema agora é... então o cache está na memória, certo? É assim que você obtém todo o desempenho. Então, quando você está mantendo dados na memória e esse é o único armazenamento, qual é a maior preocupação que você tem? Você pode perdê-lo! E se essa caixa reiniciar? O Windows é conhecido por reinicializar ou reciclar processos de trabalho. E se e eu quero dizer, mesmo se uma caixa Linux tivesse que reiniciar, mas e se sua caixa reiniciar? Você está pronto para perder esses dados? E se você for uma companhia aérea e esse cliente estiver na última página de enviar um vale de US$ 5,000 tinha aquela passagem de férias em família que eles comprariam para o Havaí e de repente ele disser, desculpe, você tem que começar tudo de novo! Você sabe e eles passaram por todos os tipos de pesquisa de voos e horários de verificação e também fizeram voos do Google e viram quais correspondiam e todas as outras coisas, então não foi uma boa experiência.
Como empresa, você não quer perder o cliente, o carrinho de compras, você não quer perder isso. Então, a resposta para isso é um cache distribuído. Você só deve manter as sessões nele ou todos os dados transitórios se isso puder garantir a confiabilidade, se garantir que você nunca perderá esses dados, ele garantirá a replicação. Assim, um bom cache distribuído faz uma replicação de dados em vários servidores. Agora, a replicação é na verdade uma perda de tempo, é uma coisa extra do que estar fazendo apenas para essa contingência de que estamos falando. Portanto, o lado negativo da replicação é que ela tem um impacto no desempenho. Portanto, se um cache não o fizer de maneira inteligente e muitos deles não o fizerem, você verá um impacto no desempenho quando ativar a replicação.
Compartilhamento de dados de tempo de execução por meio de eventos
Portanto, mantenha esses dois pontos em mente e o terceiro caso de uso é o que a maioria das pessoas não sabe, na verdade, um cache distribuído, uma vez que você tenha essa infraestrutura em seu ambiente, é uma plataforma de compartilhamento de dados orientada a eventos muito poderosa. Portanto, você pode ter vários aplicativos que precisam compartilhar dados em um fluxo de trabalho. Você pode ter uma situação do tipo pub/sub, que provavelmente usará um barramento de mensagens, barramento de serviço corporativo ou uma fila de mensagens para isso. Um cache distribuído é uma plataforma muito poderosa para isso. Como você já o possui internamente, é realmente mais rápido e mais escalável do que as outras opções porque foi projetado para desempenho, enquanto os outros aplicativos foram projetados mais apenas para compartilhamento.
Portanto, tipo pub/sub orientado a eventos de um compartilhamento entre vários aplicativos. Um aplicativo produz alguns dados, os coloca no cache, dispara um evento. Existem outros aplicativos que registraram interesse nesse evento, que quero consumir esses dados sempre que estiverem disponíveis para mim. Então, eles recebem o evento e, novamente, um aplicativo pode estar aqui, um aplicativo pode estar aqui, isso se torna um mecanismo de evento escalável muito poderoso que todos podem acessar.
Então, esse é um terceiro caso de uso. Mesmo no caso, no recurso de compartilhamento de dados de tempo de execução ou caso de uso, a maioria dos dados é transitória. Embora esteja sendo derivado de dados permanentes e provavelmente poderia recriá-lo a partir desses dados permanentes, mas é muito trabalho fazer isso e esses dados geralmente são temporários, porque a natureza disso usa temporário. Normalmente não é, não precisa ser salvo no banco de dados. Ele só precisa ser consumido. Então, o cache é novamente o único armazenamento que será e, assim como as sessões e outros, os problemas são os mesmos que a confiabilidade tem que entrar em ação. Então, essas são as três maneiras comuns de usar um cache distribuído.
Então, o bom desses três casos de uso é que não há necessidade de programação para fazer isso porque o ASP.NET framework permite que você conecte um provedor de terceiros. Então, para sessões, por exemplo, se você tiver, vou mostrar rapidamente uma amostra rápida, onde tudo o que você faz é acessar a configuração da Web e, claro, no ASP.NET core, esse paradigma vai mudar um pouco, mas a ideia é a mesma.
Configurando o cache de sessão ASP.NET
Portanto, se você for para o Web.config, este é apenas um aplicativo ASP.NET simples. Você vai para Web.config, você precisa primeiro adicionar o assembly de qualquer cache que você vai usar no caso de NCache, você fará apenas o assembly add no NCache provedor de armazenamento de sessão e você apenas copia e cola e a segunda coisa que você precisa fazer realmente é fazer alterações aqui.
Portanto, há uma tag de estado de sessão na web que configura onde você precisa ter certeza de que o modo é personalizado e o tempo limite é qualquer que seja o tempo limite. E, em caso de NCache, então você precisa apenas adicionar esta linha e há um monte de outros parâmetros que você pode especificar que eu não vou entrar, mas um deles é apenas o nome do cache. No caso de NCache, todos os caches são nomeados e eu vou te dar uma demonstração disso também, mas. Então, você apenas especifica o nome do cache. O cache já está criado. Isso é como uma string de conexão que informa a qual cache se conectar porque você pode ter vários caches, um para Sessões, um para dados de aplicativos e isso é tudo. Quero dizer, você faz essa alteração e apenas faz um teste de sanidade, passa por todos os casos de uso comuns de seu aplicativo e seu aplicativo de repente está pronto para armazenar sessões em um cache distribuído como NCache. Então, a maneira mais fácil de se beneficiar e o maior ganho na verdade são as sessões.
Então, isso é tudo que você precisa fazer para o uso do estado da sessão em um cache distribuído como NCache ou qualquer outro e o mesmo vale para o cache de saída do estado de exibição. É toda a mudança baseada na configuração. Eu não vou entrar nesses cada um deles. Eu só queria mostrar isso como um exemplo.
Cache de dados do aplicativo
Então, vamos ao coração de um cache distribuído e eu digo coração porque é onde a maior parte do seu tempo será gasto. Se você optar por incorporar um cache distribuído, passará a maior parte do tempo fazendo o cache de dados do aplicativo. Então, como é uma API típica?
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Se vocês conhecem o objeto de cache ASP.NET, NCache tenta imitá-lo o mais próximo possível, embora sejamos um superconjunto, então há mais. Cada cache tem sua própria API. Isto é o que um NCache API parece. Você se conecta com o cache, é um cache nomeado. Você obtém um identificador de cache, você mantém esse identificador de cache ao redor e dentro do aplicativo você mantém apenas Cache.Get. Obter, contém, adicionar, inserir, remover, também há adicionar assíncrono, inserir assíncrono. Inserir significa adicionar se não existir ou atualizar se já existir. Essa é a mesma terminologia que o objeto de cache ASP.NET você usa, é por isso que também a usamos. E o método Async basicamente significa que você não precisa esperar que essa operação seja concluída. Você pode, na verdade, há um terceiro parâmetro que é que você pode especificar um retorno de chamada. Portanto, seu retorno de chamada será chamado caso algo dê errado ou você possa presumir que tudo correu bem.
Mantenha o cache atualizado
Então, quando estivemos aqui, falamos sobre cache de dados de aplicativos, a maior preocupação é que você precisa manter o cache atualizado. Portanto, um bom cache distribuído deve permitir que você faça isso porque, se não permitir, forçará você a armazenar em cache os dados somente leitura. Dados somente leitura são cerca de 10 a 15% de seus dados, de qualquer maneira. Então, como você vai realmente se beneficiar desse cache se estiver armazenando em cache apenas 10 a 15% do que deveria armazenar em cache? Então, o que você quer fazer é armazenar em cache todos os dados, praticamente todos os dados, pouquíssimos dados estariam onde você diz que realmente não faz sentido armazenar em cache. Mas, quase todos os dados. Alguns dos dados serão armazenados em cache por um curto período de tempo. Portanto, uma vez que você armazena esses dados em cache, todos são dados do aplicativo, o cache mais difícil garante que o cache seja atualizado das diferentes maneiras pelas quais ele pode fazer esse número um é expirações.
Usando expirações baseadas em tempo
A expiração é uma expiração absoluta e há uma expiração deslizante. Eles 2 têm significados muito diferentes, embora ambos sejam expirações. Expiração absoluta é o que você deve fazer para manter o cache atualizado, porque você está supondo que está dizendo, estou salvando este objeto de cliente no cache. Eu acho que é seguro armazenar em cache em cinco minutos. Você está apenas fazendo um palpite baseado em, é um palpite educado, mas é um palpite. Em cinco minutos você espera que ninguém vá modificá-lo no banco de dados, mas se o fizerem, seu cache ficará inconsistente com o banco de dados. A expiração deslizante, por outro lado, não tem nada a ver com manter o cache sincronizado. Tem a ver com o despejo ou tem a ver com a limpeza automática da cache.
Então, sessões, você está dizendo que quando não há ninguém logado, após 20 minutos de inatividade, remova a sessão. Então, você está fazendo como uma limpeza. Você está dizendo que o cache, por favor, limpe-o, limpe-o para mim. Eu não quero ter que acompanhar tudo isso. Eu coloquei no cache, eu especifiquei quanto tempo ele deve ficar no cache mesmo se ninguém estiver tocando nele, depois disso limpe-o. Então, objetivos muito diferentes que você tem de permanente de expiração absoluta versus expiração deslizante. Portanto, expiração deslizante, você usaria para sessões de dados transitórios. Expiração absoluta, você usaria para dados permanentes.
Outro termo que quero usar é dados de referência versus dados transacionais. Dados de referência são dados que não mudam com muita frequência, mas mudam, não são somente leitura. é, é a sua tabela de produtos que o preço pode mudar todos os dias ou todas as semanas ou algo assim, mas não é tão frequente quanto um objeto de cliente ou como objeto de atividade ou algo ou um objeto de pedido. Portanto, os dados transacionais são o que queremos armazenar em cache. Claro, os dados de referência são um dado que queremos armazenar em cache, mas os dados transacionais também são algo que é onde vamos obter todos os dados. Portanto, se a expiração não for suficiente para garantir que seu cache permaneça atualizado, você precisará ter mais recursos.
Usando dependências de banco de dados
Então, o próximo recurso, um recurso muito poderoso que um bom cache distribuído deve ter é que ele deve ser capaz de sincronizar o cache com o banco de dados sem envolver você, sem que você monitore as coisas. Então, você deve ser capaz de dizer ao cache que estou armazenando esse objeto em cache. Isso está relacionado a esse conjunto de dados no banco de dados. Portanto, monitore esse conjunto de dados no banco de dados. Veja se muda, vá e faça uma ou duas coisas, ou remova este item do cache, remoção significa que da próxima vez que o aplicativo o desejar, ele não o encontrará no cache. O que acontece quando não o encontra na cache? Você obtê-lo a partir do banco de dados. Portanto, é como obter uma nova cópia ou, em segundo lugar, pode recarregar uma nova cópia automaticamente. Recarregar uma nova cópia automaticamente requer outro recurso chamado read-through, sobre o qual falarei.
Então, eu vou voltar a isso, mas sincronização de banco de dados é um recurso muito poderoso. Isso é o que lhe dá tranquilidade para garantir que seu cache permaneça atualizado. Que você não terá que se preocupar com os dados que está armazenando em cache e existem diferentes maneiras de sincronizar o cache com o banco de dados. A mais comum é a dependência SQL, que na verdade é um recurso do ADO.NET ou do servidor SQL que NCache usa.
Então, por exemplo, eu vou realmente mostrar o código que eu deveria. Então, deixe-me rapidamente... Vou mostrar rapidamente como é o código. Onde foi isso? Então, se você tem um aplicativo .NET, digamos que este é NCache, é claro, você faria referência a dois dos NCache bibliotecas. NCache.Tempo de execução e NCache.Rede. Então, novamente, tentamos nomeá-lo o mais próximo possível do namespace do objeto de cache ASP.NET para NCache.Rede. Quando saímos em 2005, o objeto de cache ASP.NET era o único cache disponível, então somos os mais antigos no espaço, por isso escolhemos esse nome para facilitar as pessoas. Então, dentro do aplicativo, você incluiria alguns NCache namespaces. Então, você se conectaria com seu cache, você obteria um identificador de cache e agora você tem um identificador de cache, então, digamos, você cria seu objeto e deseja fazer Cache.Add. Assim, Cache.Add recebe uma chave. Observe que a chave é na verdade uma string, então seguimos isso. Bem, isso não está seguindo essa convenção de nomenclatura, mas geralmente é Customer:CustomerID: qualquer que seja o ID para esse cliente, então você faz Cache.Add depois e, neste caso, está especificando a expiração absoluta de um minuto. Como dizendo, não faça nenhuma expiração deslizante e todas as outras coisas. Então, é apenas para dar uma ideia de como é um cache.
Muito fácil de usar, API muito simples, muito mais simples do que fazer ADO.NET ou qualquer outra programação.
Como é um Cache?Deixe-me apenas mostrar a você como é um cache, mas com um cache real. Então, eu tenho essas VMs e o Azure. Então, eu tenho demo 1 e 2 dois. Estes são dois servidores de cache que vou usar. Essas são VMs de cache e terei meu servidor de aplicativos. Vou chamá-lo de cliente de demonstração. Então, meu aplicativo será executado no cliente de demonstração. Ok! Então, eu tenho a Área de Trabalho Remota para isso. vou em caso de NCache Vou executar esta ferramenta chamada NCache gerente, eu realmente tenho isso aqui. E, eu vou em frente e criar. Deixe-me verificar rapidamente se não há cache com esse nome. Ok! Então, vou em frente e criar um novo cache. Vou chamar meu cache de demonstração de cache. Eu vou apenas levar todo o resto como o padrão. Vou escolher uma topologia de cache. Não vou entrar em detalhes, mas essa topologia de cache faz particionamento e replicação ao mesmo tempo. Então, quando você fizer essa topologia, seu cache ficará assim.
Então, esses são seus servidores de cache. Então, alguns dos dados, esse 1 2 3 4 são os elementos de dados. Assim, alguns dos dados estão na partição 1, alguns dos dados estão na partição 2 e é feito backup de cada partição em um servidor diferente. Então, se você tivesse 3 servidores aqui.
Digamos que você tenha a partição 1 2 e 3, o servidor 2 tenha a réplica da partição 1, o servidor 3 tenha uma réplica da partição 2 e o servidor 1 tenha a réplica da partição 3. Então, o cache na verdade é um servidor. Na verdade, é mais de um servidor, que está em um cluster. Eles se conhecem e eu vou rapidamente levá-lo de volta a isso. Então, digamos que eu escolhi uma topologia de réplica de partição. Vou escolher o demo 1 como meu primeiro servidor de cache. Por que é tão lento? Demo 2 como meu segundo servidor de cache. Eu acho que é provavelmente porque a internet é lenta, talvez. Não sei. Então, eu tenho um cluster de cache de dois nós. Então, a demonstração um e dois agora se conhecem. Então, eles vão conversar entre si nesta porta. Na porta 7802 que eu poderia mudar. Por que é tão lento? Certificar-se.
Ok! Então, a seguir vou especificar quanta memória o cache deve ter. Então, tem um show, você provavelmente terá, como eu disse, 13 shows ou algo assim. E, então, vou especificar a política de despejo que é usada menos recentemente. Vou economizar 15%... Lamento despejar 5% do cache. Isso é muito lento, não sei o que está acontecendo. Essa caixa toda é lenta, até um clique é, até a CPU não é, sim! Parece que sim. Sim é!
Ok! Então, basicamente, você tem um cluster de servidores que logicamente são chamados de cache e você os conhece apenas por um cache de demonstração. Em sua caixa, digamos, sua caixa de servidor de aplicativos, digamos NCache está instalado aqui. Você terá um arquivo de configuração que terá esse nome de cache e uma lista de servidores que o representam. Então, isso é apenas um ponto de partida, mas novamente você saberá que todo o cluster é apenas um nome de cache e você se conecta a ele e, em seguida, sua API cliente se conectará a todos os servidores de cache nesta imagem. No caso de réplicas de partição, cada cliente fala com todos os servidores para que possa ir diretamente para onde estão os dados, a parte de particionamento.
Vou em frente e adicionar um cliente para este que é o meu cliente de demonstração. Vou em frente e clicar no assistente de cache, demorando muito para clicar, e direi iniciar o cache. Então, apenas dizendo que o cache será iniciado em ambas as caixas. NCache é um cache baseado em Windows, portanto, possui todos os recursos fáceis de usar que um bom produto baseado em Windows possui. Então, você pode fazer tudo isso de um lugar central, tudo isso você também pode fazer por meio de scripts.
Sincronização de banco de dados - DemonstraçãoEntão, deixe-me mostrar como é a sincronização de banco de dados. Então, por exemplo, o que você faz é, novamente, é o mesmo tipo de aplicativo, você tem o cache e quando você tenta adicionar um dado ao cache, digamos que você esteja fazendo Cache. Adicione aqui e isso é é claro NCache código, você especifica uma dependência de cache SQL que é um NCache class, mas mapeia no back-end para a classe de dependência SQL do SQL Server. E você passa uma string SQL que é usada por NCache para se conectar ao banco de dados e o servidor de cache agora se torna um cliente do seu banco de dados. Então, por exemplo, se sua aplicação está aqui, digamos, seu código está rodando aqui, você acabou de emitir esta chamada. OPA, desculpe! Você acabou de emitir essa chamada de cache desse anúncio e passa essa dependência de cache do SQL. O cliente envia tudo isso para o servidor de cache.
Então, um dos servidores de cache ou vários. E o servidor de cache agora abre uma conexão com o banco de dados porque você especificou uma string de conexão também aqui. E, essa força de conexão é, claro, pool. Então. se várias vezes você especificar a mesma cadeia de conexão, haverá um pool de conexão no back-end. Então, outro cache agora se tornou um cliente do seu banco de dados. Ele monitorará seu banco de dados para que o banco de dados notifique o NCache servidor que esses dados foram alterados que você me pediu para monitorar e o NCache servidor naquele momento pode decidir se deve remover esse item do cache ou recarregá-lo do banco de dados. E, para recarregá-lo, você precisa realmente passar pelo recurso de leitura.
Ok! Então, essa é uma maneira de fazer isso. É realmente poderoso. É orientado a eventos. Assim que a mudança acontece, o banco de dados notifica o cache, o cache imediatamente executa a ação. No entanto, há uma sobrecarga no final do servidor de banco de dados porque toda vez que você faz uma dependência de cache SQL, uma estrutura de dados precisa ser criada no servidor SQL para monitorar esse conjunto de dados. Agora, se você tivesse 1 milhão desses, posso garantir que seu servidor SQL vai travar. Então, novamente, já que estamos falando de escalabilidade, você precisa pensar em termos de números realmente grandes. Então, se você tiver milhares ou dezenas de milhares deles, não há problema. Mas se você tiver centenas de milhares ou milhões deles, uma estratégia diferente seria uma estratégia melhor.
Dependência de banco de dadosUma outra estratégia é chamada de dependência de banco de dados, que é nossa NCache recurso que é uma dependência baseada em polling. Implementamos isso onde. Existe uma tabela especial e pedimos que você modifique os gatilhos para que você possa atualizar o sinalizador nessa tabela para essa linha correspondente e sempre que você fizer uma dependência de banco de dados do cache, o cache cria uma entrada nessa tabela e depois em uma busca , o cache pode buscar milhares de linhas onde o sinalizador é verdadeiro, a atualização ocorreu. Então, é como nossa própria maneira de acompanhar. É baseado em pesquisas, portanto não é instantâneo. Por padrão, cerca de 15 segundos de atraso, mas você pode reconfigurar isso. Você também não quer puxar com muita frequência. Então, esse é o outro, mas mesmo aí você tem limitação de, e se você tiver 1 milhão de linhas nessa tabela com um sinalizador de verdadeiro e falso, o índice ficaria bem grande, certo? Há um índice verdadeiro e um falso, esses são os dois nós de uma árvore. Portanto, a dependência de banco de dados é mais eficiente que a dependência de SQL, mas não em tempo real, mas tem limitações.
Procedimentos CLRO terceiro são os procedimentos CLR, onde você pode realmente chamar um procedimento CLR de um gatilho no banco de dados, então sempre que qualquer item for adicionado, atualizado ou excluído, você chama o procedimento. O procedimento faz uma chamada assíncrona para o cache. Diz por favor, adicione ou atualize ou exclua este item do cache. A razão pela qual o Async é crítico é porque você não quer atrasar a transação, a transação do banco de dados. Ele vai começar a expirar de outra forma. Portanto, uma chamada Async retornará imediatamente e pelo menos a transação do banco de dados poderá ser confirmada e o cache poderá ser atualizado. Portanto, a sincronização do cache com o banco de dados é um recurso crítico.
Sincronizar Cache com Não Relacional
Você deve ter isso e a mesma coisa se tiver não relacional ou tiver mainframe ou legado ou qualquer outra fonte de dados, pode ter uma fonte de dados em nuvem, pode querer fazer chamadas de método web para até verificar se esses dados está atualizado ou não e NCache permite que você tenha esse recurso de dependência personalizado onde é o seu código que pode monitorar NCache, chama seu código a cada pequeno intervalo, você vai e monitora sua fonte de dados para ver se esses dados mudaram, se você notificou NCache e NCache irá remover ou recarregar novamente da mesma maneira.
Manipulação de Dados Relacionais
Portanto, manter o cache atualizado é fundamental. Qualquer cache que não permite que você faça isso, limita sua capacidade de se beneficiar. Vou pular a manipulação de dados relacionais embora, mesmo que não seja e o que, deixe-me dizer rapidamente, você tem relacionamentos um-para-muitos, relacionamentos um-para-um. Portanto, se você tiver um item no cache e muitos itens também no cache, quando você remover um item no cache, logicamente, muitos itens também devem ser removidos, porque e se você excluiu isso do banco de dados. Portanto, o cache deve ser capaz de acompanhar tudo isso. Você poderia fazer isso em seu aplicativo, mas isso apenas complica o crédito do aplicativo, porque agora você está fazendo muita contabilidade para o cache. É como se você estivesse construindo sincronização de banco de dados ou código de integridade de dados dentro do aplicativo, que não é o trabalho do seu aplicativo. Você não faz isso para o banco de dados. O banco de dados faz isso por você, então o cache também deve fazer isso por você.
Read-thru e Write-thru
Portanto, leitura e gravação são outro recurso muito poderoso que seu cache deve ter. A leitura é basicamente, novamente, o conceito é muito simples.
Você implementa uma interface, no caso de NCache você implementa uma interface chamada provedor de leitura, bem aqui. Você consegue ver isso?
Sim e tem três métodos. Há um Init que é chamado quando o cache é iniciado para que você possa se conectar à sua fonte de dados. Há um descarte quando o cache para você pode fazer sua limpeza e na maioria das vezes você chamará essa carga da fonte. Então, ele passa a sua chave. A chave é a sua chave para saber qual item em sua fonte de dados buscar e então você devolve, em caso de NCache um item de cache do provedor. E você pode especificar expirações e ressincronizar na expiração, todos os tipos de sinalizadores aqui e depois passá-los para NCache. NCache o armazena em cache.
Então, como funciona a leitura? A forma como trabalhamos é, sua aplicação sempre pede o cache. Ele diz Cache.Get. Se o cache não tiver os dados, ao invés de dizer que não tenho, ele vai e pega no banco de dados. Assim, sua aplicação de repente se torna muito mais simples. Muito do código de persistência, você acabou de retirar do seu aplicativo. Então, um benefício da leitura é que você simplificou o código, você encapsulou tudo na camada de cache. A camada de cache agora tem cada vez mais sua camada de persistência. Nem todo código pode ser feito através de leitura, mas muito pode ser.
Recarregar na expiração
O segundo benefício da leitura é sobre o que falei anteriormente, que é o recurso de recarregamento. Agora imagine, se você tem um aplicativo de comércio eletrônico e seus preços mudam e toda vez que os preços mudam, esses itens precisam ser removidos do cache e recarregados, mas é um tráfego muito pesado, então, enquanto eles são removidos, muitas solicitações de clientes atingirão o banco de dados. O primeiro irá buscá-lo e colocá-lo no cache, mas até esse momento o cache de repente tem muito tráfego desnecessário e se isso continuar acontecendo, se você tiver muito disso acontecendo, o banco de dados receberá muitos acessos desnecessários o que você poderia ter evitado se apenas dissesse recarregar na expiração. Então, recarregue uma expiração, o que isso faz? Não remove o item na expiração. Ele apenas o recarrega para que, quando a expiração ocorrer, o cache chame a leitura e o obtenha da sua fonte de dados e apenas atualize. Portanto, há apenas uma operação de atualização acontecendo. Não há operação de remoção e adição e, por isso, os dados ou o item estão sempre no cache. Então, o cache de repente se torna. Ele pode cuidar de si mesmo e pode se recarregar sempre que os dados precisarem ser recarregados.
Gravação
Então, essa é uma capacidade realmente poderosa de leitura. Então, quando você combina isso com a expiração, pode fazer isso também com a sincronização do banco de dados. Quando a sincronização do banco de dados acontece, novamente, por que removê-la? Basta recarregar. O outro recurso é o write-through, que funciona exatamente como um read-through, exceto pelo fato de escrever. Há mais uma coisa que ele faz, também pode fazer gravação em massa. E, a razão pela qual ele escreve em massa, explicarei em breve. Então, da mesma forma que há um Init, há um descarte e agora há uma gravação em fontes de dados. A escrita não significa apenas adicionar ou inserir. Ele também pode ser excluído para que a gravação tenha um tipo de operação que pode ser adicionado, atualizado ou removido. E isso depende de qual foi a operação de cache. E, então, você também pode fazer isso em massa. Portanto, o write-through tem os mesmos benefícios do read-through em termos de simplificar seu código, mas novamente tem mais um benefício. Assim, o read-through teve o benefício de recarregar o write-through tem o benefício onde você pode write-behind.
write-behind
E, write-behind é um recurso muito poderoso. Por quê? Porque as atualizações do banco de dados são um gargalo. Novamente, banco de dados é aquele mal necessário com o qual você tem que conviver. Você não pode viver sem ele, mas está causando todos os tipos de gargalos em seu aplicativo. Portanto, quanto menos você puder depender disso, melhor será sua aplicação. O fato de que você não pode viver sem ele você ainda tem que tê-lo. Então, o que um write-behind faz? Ele diz que você atualiza o cache que é super rápido, dez vezes pelo menos mais rápido que o banco de dados, se não mais, e então o cache cuida da atualização do banco de dados. Então, há um write-through assíncrono, que é um write-behind. Então, você vai e atualiza o cache, volta e continua suas coisas e o cache vai e atualiza o banco de dados.
Claro, há muitos problemas que o cache deve resolver. Assim que você diz que o cache precisa atualizar o banco de dados, e se o servidor de cache travar? O que acontece com essa fila? Então, em caso de NCache, a própria fila é replicada para vários servidores, se algum servidor ficar inativo, você não perderá a fila. Depois, há também novas tentativas. E se essa atualização falhar, você pode tentar novamente. Você também pode fazer atualização em lote. Então, há um monte deles que você pode fazer uma atualização em massa. Assim, pode otimizar ainda mais as coisas. Portanto, write-through e read-through são recursos muito, muito poderosos. Isso é chamado de código do lado do servidor. Este é o seu código que reside no cluster de cache. Ele mora aqui e manter esse código no servidor simplifica seu aplicativo. Portanto, quanto mais código você empurra para baixo, mais simples o aplicativo se torna.
Agrupamento de dados
Ok! Agora que, digamos, você está convencido de que deve usar o cache. Você tem os diferentes casos de uso em que agora está confiante em armazenar em cache muitos dados. Então agora, o cache começou a se parecer com o banco de dados. está começando a ter muitos, Você vai ter milhões de itens no cache. Então, quando você tem milhões de itens no cache, é bom apenas ler as coisas com base em uma chave? Não! se a única maneira de ler itens do cache for com base na chave, seu aplicativo seria muito, muito desafiador em comparação com se você pudesse fazer as coisas, bem, me dê todas as coisas com base neste critério de pesquisa.
Assim, pesquisar e agrupar torna-se uma necessidade muito poderosa ou uma necessidade muito importante de um cache. Novamente, como eu disse, o objetivo é que você entenda quais são os benefícios. O benefício é se você puder armazenar em cache mais e mais dados. Quanto mais dados você armazenar em cache, mais você precisará vê-los ou ter mais recursos do tipo de banco de dados. Um desses recursos é poder fazer metadados. No banco de dados, você pode ter índices em vários atributos diferentes. Aqui você pode fazer tags, tags nomeadas e, na verdade, quando você armazena em cache os objetos, no caso de NCache também permite criar índices. Assim, você pode indexar um objeto. Digamos que um cliente possa ser indexado no atributo cidade porque você vai pesquisar na cidade, então ela deve ser indexada. Se não estiver indexado, a pesquisa será realmente dolorosa. Imagine milhões de itens que você precisa primeiro desserializar para inspecionar cada objeto apenas para saber quais clientes em Orlando. Não é uma boa imagem, não é uma visão bonita.
Portanto, agrupar tags de subagrupamento e tags de nome novamente de uma perspectiva de codificação muito simples. Eu só vou mostrar isso rapidamente. Da perspectiva de gravação muito fácil de usar. Você adiciona um monte de itens e atribui tags e então, me desculpe! grupo e subgrupo, grupo subgrupo e então você diz obter dados do grupo ou também pode fazer uma pesquisa SQL e dizer me dê todo o objeto do produto onde o nome do grupo é eletrônico. Portanto, tags e tags de agrupamento e subagrupamento também são algo que AppFabric fornecido, aliás AppFabric está sendo descontinuado em fevereiro. Temos mais minutos, vou acelerar.
Encontrando dados
Novamente, encontrar dados está relacionado a agrupar dados, você deseja poder pesquisar dados com base em SQL, então acho que… onde está a linguagem de consulta de objetos? Aí está. Então, eu poderia, basicamente, ter um monte de dados e emitir uma instrução SQL e especificar vários atributos e passar parâmetros e obter um registro definido de volta no caso de NCache e assim como o SQL Server, embora seja um subconjunto do SQL completo. Ele não faz articulações, mas em vez de fazer junção, você pode agrupar e marcar e é assim que você pode agrupar vários objetos.
Então, no caso de LINQ, NCache implementou um provedor LINQ para a interface Iqueryable. Você vai e pega aquela coleção de NCache e então você faz uma consulta LINQ exatamente como você faz em relação a qualquer outra coleção de objetos e ela irá em frente e obterá uma coleção desses objetos, os objetos do produto de volta. Portanto, se o LINQ é realmente sua zona de conforto em termos de pesquisa, use o LINQ para pesquisar. Quando você emite essa consulta, você está indo para o cluster, a mesma consulta será enviada para todos os servidores e os resultados virão e serão mesclados e mostrados a você. Então, pode, embora pareça muito simples aqui, nos bastidores há muito trabalho sendo feito por NCache.
Então, temos SQL e LINQ. Também temos bulk e como eu disse, você pode fazer Indexação.
Compartilhamento de dados em tempo de execução
Estou indo muito rapidamente… há eventos baseados em chave, há eventos de nível de cache, há sub eventos pub, há uma consulta contínua.
A consulta contínua é um recurso semelhante a um recurso de dependência SQL, exceto que está no cache. Você está pedindo ao cache para monitorar um conjunto de dados para você. Então, assim como estávamos usando a dependência do SQL e solicitando ao servidor SQL para monitorar esse conjunto de dados e dissemos que se esse conjunto de dados mudar, por favor, avise-me. Agora, você está perguntando NCache, dizendo por favor, aqui está minha instrução SQL, selecione clientes em que Customer.City é igual a Nova York e você está dizendo que se algum cliente que corresponda a esse critério for adicionado, atualizado ou excluído do cache, avise-me e isso pode estar em qualquer lugar a rede, qualquer lugar no cluster de cache e você pode ser qualquer outro cliente. Você será notificado. Então, tendo esses tipos de recursos agora, você pode monitorar de repente o que está acontecendo com o cache e ser notificado em vez de pesquisar coisas e é isso que eu estava dizendo, o cache se torna uma plataforma de compartilhamento de dados em tempo de execução realmente poderosa.
High Availability
Ok! Vou pular isso também. Quero dizer, qualquer cache que você usa tem que ter dinâmico. Tem que fornecer alta disponibilidade que em caso de NCache, tem uma arquitetura ponto a ponto.
Cache de cliente
Há um recurso que eu quero que você saiba que é chamado cache do cliente. Algumas pessoas chamam de perto de cache.
Na verdade, este é um cache que fica localmente na caixa do servidor de aplicativos. É como um cache autônomo, exceto que não é autônomo. Então, pode até ser InProc. Pode estar dentro do seu processo de aplicação, o que significa que você está realmente buscando coisas como em seu heap de objetos. Seu heap tem dados em forma de objeto. Nada supera esse desempenho, certo? Se você pode apenas obter esses dados do heap versus ir para uma caixa local de cache OutProc, porque quando você passa por processos, ele precisa passar por IPC, tem que fazer serialização, desserialização, quando você atravessa a rede é ainda mais, quando você vai para o banco de dados é fenomenalmente caro, comparativamente.
Portanto, este é um cache local dentro do seu processo de aplicativo ou localmente na caixa. Mas, ele permanece sincronizado. Você não faz nenhuma programação de API especial para o cache do cliente. Você apenas faz as chamadas para o cache, em caso de NCache, ele apenas se conecta à mudança de configuração e intercepta as chamadas e o que quer que você esteja buscando mantém uma cópia localmente. Portanto, da próxima vez que você buscá-lo, ele o obterá automaticamente do cache local. Grande aumento no desempenho. Isso é algo que só NCache tem no lado .NET. No lado do Java, existem outros produtos que possuem cache de cliente, mas no .NET disse que isso é apenas. Isso é como um cache em cima de um cache e essa é a razão pela qual muitas pessoas, quando passam do cache InProc autônomo para um cache distribuído, reclamam, meu desempenho realmente caiu, meu aplicativo está mais lento, pensei que o cache distribuído era deveria aumentar meu desempenho e dizemos a eles que não, deveria aumentar a escalabilidade. Nada corresponde a um cache InProc local, ninguém pode. Quero dizer, isso não é algo que podemos inventar e fazer alguma coisa. Você está passando por processos, isso é um custo.
Então, dizemos bem, uma maneira de superar esse desafio é usar um cache de cliente. Portanto, um cache de cliente novamente é um subconjunto. Normalmente, você teria de 16 a 32 GB em cada servidor de cache. Então, se você tem de três a quatro servidores, você tem cerca de mais de cem giga de dados em cache potencialmente e o cache do cliente talvez um giga, talvez dois giga, talvez três ou quatro giga, no máximo cada e depende de quantos processos de trabalho você tenho. Se você tiver apenas um processo de trabalho, faça quatro shows. Se você tiver oito processos de trabalho, que muitos de nossos clientes de ponta têm em sua camada da Web, você não quer ter quatro vezes oito apenas no cache do cliente. Então, talvez, seja bom ter um cache de quatro gigas fora do processo, o que ainda é melhor do que ir para a camada de cache. Ainda é mais rápido ou você pode ter um cache menor de um show ou menos de um show, que é o InProc. Agora, você tem oito cópias, mas elas também estão sincronizadas. Portanto, definitivamente um cache de cliente é algo que você deve considerar usar se quiser obter o valor de um cache.
Agora, meu objetivo e isso não é vender nenhum recurso de cache, mas dizer o que um bom cache deve ter e muitos desses recursos você encontrará no lado do Java. Java é um mercado muito mais maduro no lado do cache. Eles usam a palavra grade de dados na memória em vez de cache distribuído, mas qualquer recurso que você esteja vendo NCache, você verá muitos deles também no lado Java, mas no lado .NET NCache é o único.
Replicação de WAN
Outro recurso é que, se você tiver vários data centers, deseja que seu banco de dados seja replicado, então por que não o cache? O que você vai fazer? Você vai reconstruir todo o cache? E o carrinho de compras? E as sessões? Assim, vários data centers são uma realidade e a nuvem tornou isso ainda mais fácil porque não há nenhum esforço de sua parte. Basta ir e dizer região um e região dois e você tem dois data centers, certo? Mas o problema subjacente não desaparece, ou seja, se você usar um cache distribuído que não oferece suporte à replicação de WAN, ficará preso. Você não pode ter uma solução de multi data center ativo-ativo ou mesmo ativo-passivo sem que o cache seja replicado, um recurso muito importante.
NCache claro que tem isso. Eu já lhe dei a demonstração prática. NCache é o cache .NET mais antigo do mercado. Fomos lançados em 2005, muito mais velhos.
NCache vs Redis
Então, eu vou passar rapidamente NCache contra Redis, nível muito, muito alto e isso porque Redis muitas pessoas vêm e nos perguntam como você se compara com Redis desde que a Microsoft os escolheu para o Azure.
Redis, é um ótimo produto. É super-rápido. Ele vem principalmente do lado do Linux. Não tem muitos recursos. Ele não ganha em recursos. Ele só ganha pelo fato de ter vindo do lado do Linux e a Microsoft queria capturar o mercado da AWS para que eles não pudessem adotar uma solução .NET. Eles tiveram que adotar, multiplataforma. Então, a versão Linux deles é muito estável, muito boa, mas a versão do Windows que a Microsoft fez é meio que uma versão órfã. A Microsoft não o usa. Quando você está no Azure e usa Redis, você não está usando a porta Windows de Redis, você está usando a versão Linux. Portanto, se você não estiver no Azure e for usar a porta Windows do Redis, cuidado. Quer dizer, ninguém é dono. Redis labs, se você for ao site deles, eles nem terão um download do Windows. Quero dizer, eles só têm downloads do Linux, que é o criador do Redis. A Microsoft, como eu mesmo disse, não colocou seu dinheiro onde sua boca estava em termos de uso do compromisso.
então, NCache é a única opção viável para você e é de código aberto, portanto, se você não tiver dinheiro, vá com a versão gratuita de código aberto. Se o seu projeto é importante e você deseja suporte e mais recursos quais são os recursos corporativos. A empresa NCache é construído em cima de código aberto. Não é como uma coisa separada. O código aberto não é órfão. Quero dizer, nós a possuímos, nós a mantemos e a empresa é construída em cima. Portanto, o código aberto deve ser estável, mas se você deseja suporte e mais recursos, basta comprar a Enterprise Edition.
Somos .NET nativos. Desenvolvemos em c-sharp e temos certificação Windows Server 2012 r2. Vamos receber o próximo também em breve. Então, queremos dizer que não estamos no topo do jogo no que diz respeito à Microsoft. Somos praticamente .NET, é isso que somos. Temos um cliente Java, mas quase todos os nossos usos Java por clientes que compram NCache para .NET e, como eles o possuem internamente, também o utilizam em Java. Então, nosso pão com manteiga, toda a nossa sobrevivência está no .NET. Então, sempre seremos os mais recentes e os melhores, os primeiros e os mais fáceis.