NCache Arquitetura
Hoje vou falar sobre NCache Arquitetura. NCache é um armazenamento distribuído na memória para aplicativos .NET e Java. É extremamente rápido e escalável. E você pode usá-lo em seus aplicativos de servidor de alta transação para aumentar o desempenho e a escalabilidade de seu aplicativo.
Usos comuns de NCache
Cache Distribuído
As duas maneiras comuns NCache é usado. O número um é como um Cache Distribuído onde você armazena em cache os dados do aplicativo para reduzir as dispendiosas viagens ao banco de dados e, o número dois é um Mensagens e fluxos plataforma. Examinarei ambos brevemente antes de entrar na arquitetura.
-
Cache de dados do aplicativo
Portanto, no cache distribuído, o cache de dados do aplicativo significa que você usa um NCache API geralmente apenas armazena em cache os dados do seu aplicativo, então você não precisa ir ao banco de dados com tanta frequência porque o cache é muito mais rápido que o banco de dados. Também é mais escalável porque está na memória, portanto é rápido. Está próximo do seu aplicativo, por isso é rápido e distribuído, por isso é escalonável. E, se você tiver um aplicativo .NET e estiver usando o EF Core, poderá usar NCache através do EF Core também e também do NHibernate e EF 6. Se você tiver aplicativos Java, poderá usar NCache como um cache de segundo nível do Hibernate. Você também pode usar with como Spring Cache ou programá-lo no JCache. -
Cache de aplicativo da Web
A segunda parte do uso do cache distribuído é que, se você tiver aplicativos da Web, poderá armazenar seus sessões em NCache e então NCache replica essas sessões para vários servidores, de modo que, se houver algum NCache servidor que fica inativo, você não perde nenhum dado, mas essas sessões são novamente escalonáveis porque é um armazenamento distribuído e é obviamente super-rápido. Há também recurso de sessão multi-site disponível em todas as linguagens .NET, Java, Nodejs, etc. Além de sessões, por exemplo, para .NET 6, ASP.NET Core aplicativos podem armazenar seus Cache de resposta em NCache e eles também podem usar NCache como o backplane para SignalR. SignalR é para aplicativos da web ao vivo, onde o aplicativo da web precisa enviar eventos aos clientes. E então, se você estiver usando o .NET 4.8, você também pode armazenar seu estado de sessão, Ver estado, Cache de saídae também SignalR.
NCache para aplicativos de missão crítica
Deixe-me mostrar rapidamente o que NCache parece. Aqui está o que é um cache distribuído para aplicativos de missão crítica. Eu uso a palavra missão crítica porque na maioria dos casos vemos que há clientes que usam NCache em aplicações muito sensíveis voltadas para o cliente e que são muito importantes para seus negócios. Então, NCache é, você sabe, parte de sua infraestrutura muito crítica nesse caso.
E esses são, como eu disse, aplicativos de servidor com alta transação. Estes são aplicativos da web. São microsserviços, APIs da Web ou outros aplicativos de servidor. Obviamente, você pode usar .NET, Java, Node.js ou Python. E esses aplicativos estão tentando acessar seu banco de dados como SQL Server, Oracle, Db2, MySQL ou qualquer outro banco de dados relacional, ou estão acessando talvez seus dados legados de mainframe ou talvez estejam usando um NoSQL database como Mongo DB, Cosmos DB, Cassandra ou outros. Nesta situação, NCache torna-se um cache distribuído por… você usa NCache como dois ou mais servidores como uma camada de cache separada, embora você não precise ter uma camada de cache separada, seu aplicativo pode ser executado na mesma caixa que NCache e funciona perfeitamente bem, mas a arquitetura de implantação mais popular é ter uma camada de cache separada, que é apenas uma maneira mais limpa de usar NCache.
Então, digamos que você comece com um cluster de cache de 2 servidores, NCache cluster, NCache agrupa a memória, a CPU e os recursos da placa de rede de todos esses servidores em uma capacidade lógica e, digamos, você está colocando mais carga de transação em seus aplicativos NCache e esses dois servidores estão no máximo, você pode facilmente adicionar um terceiro servidor, ou um quarto servidor, ou um quinto servidor e, assim por diante, NCache nunca se torna um gargalo. Isso é algo que você não pode fazer com seus bancos de dados. Os bancos de dados não são escalonáveis. NoSQL é escalável, mas, na maioria dos casos, descobrimos que as pessoas precisam usar bancos de dados relacionais por diversos motivos de negócios e também possuem mainframes legados. Então, como a camada de armazenamento de dados não é escalonável NCache ajuda a escalar seu aplicativo, permitindo armazenar em cache o máximo de dados possível. O objetivo geral é ter cerca de 80% do tempo em que você deve encontrar os dados de NCache em vez de ir para o seu banco de dados. Se você conseguir atingir essa proporção, você sabe, você tirou a pressão dos bancos de dados e seu aplicativo será escalado.
Mensagens e fluxos
O segundo caso de uso comum, ou uso de NCache é usá-lo como uma plataforma de mensagens e fluxos onde você pode ter vários aplicativos que podem se comunicar entre si através Mensagens do Pub/Sub, Através Consulta Contínuaou NCache eventos baseados. Deixe-me mostrar como é isso. Então, por exemplo, se você tiver um aplicativo de servidor de alta transação que precisa fazer muitas mensagens em tempo real ou processamento de fluxo, você pode usar NCache. Agora o mesmo NCache que era um cache distribuído agora se torna uma plataforma de mensagens e streams. Novamente, é um armazenamento distribuído na memória. Ele é dimensionado linearmente. Ele replica as mensagens em vários servidores. Na verdade, NCache também tem Persistência nele.
Então, com isso, você pode ter diferentes aplicações, por exemplo, o sistema de mensagens Pub/Sub é uma forma muito popular, é uma metodologia, é um paradigma onde você tem vários editores e vários assinantes que podem se comunicar entre si de forma desacoplada. Desacoplado significa que o editor não sabe quem é o assinante, apenas publica mensagens sobre determinados tópicos e esses assinantes podem obtê-las. Consultas contínuas são da mesma maneira. Então, essas são as duas maneiras comuns NCache é usado.
Aplicativos .NET x Java
Agora vamos falar sobre como NCache lida com aplicativos .NET vs. Java. NCache tem uma capacidade multiplataforma nativa única que você achará muito interessante, deixe-me falar sobre isso.
Edição .NET
NCache tenta fornecer uma solução nativa para .NET e Java. E, com isso, quero dizer que quando você tem um aplicativo .NET, toda a sua pilha de aplicativos experimenta o .NET, você não está usando nada além do .NET. Então, por exemplo, NCache tem um cliente .NET nativo que é o que seu aplicativo usará em seu aplicativo. Isso é executado em seu servidor de aplicativos e NCache desenvolveu isso em 'C Sharp' (C#), 100%.
Da mesma forma, se você tiver código do lado do servidor como leitura, gravação, direita atrás, carregador/atualização que você escreveu em .NET, NCache executará esse código em seu próprio processo .NET CLR. Deixa-me mostrar-te como. E voltarei a este diagrama de um lado para outro. Então, por exemplo, aqui está um NCache arquitetura você tem um aplicativo .NET aqui que pode estar rodando no Windows ou Linux. Tem um nativo NCache Cliente .NET. E isso é falar com um NCache cluster que é uma edição .NET NCache Conjunto. Então, isso significa que o código do lado do servidor também é .NET.
Agora o caminho NCache é arquitetado e é por isso que o que o torna realmente poderoso para suporte nativo multiplataforma é que existe um processo de cache, existe um processo de gerenciamento, que são separados do processo de código do lado do servidor. E há um RPC de alto desempenho. É um RPC na memória que NCache usa, que NCache desenvolveu seu próprio RPC proprietário que é super rápido. Então é assim que o cache se comunica com o código do lado do servidor. Então, por exemplo, se for necessário chamar o Read-through Handler, seu Read-through Handler estará sendo executado dentro deste processo .NET CLR para ir ao seu banco de dados para obter os dados e então passá-los para o cache. E o mesmo vale para Write-through, Loader e Refresher. Portanto, toda a experiência que sua aplicação possui é .NET.
Edição Java
Bem, vamos mudar para o lado Java. Novamente, da mesma forma, você tem um código Java do lado do servidor. NCache possui um cliente 100% Java que roda no seu servidor de aplicação e da mesma forma que o .NET. Aqui está a edição Java. Digamos que você tenha um aplicativo Java que provavelmente está rodando no Linux, ou talvez até no Windows, talvez no Docker, talvez no Kubernetes. Então, esse aplicativo irá incorporar o NCache Cliente Java que é como eu disse aqui 100% Java nativo, e então este Cliente Java é idêntico ao Cliente .NET. Também conversa com NCache Cluster da mesma maneira que o cliente .NET faz usando NCachepróprio protocolo de soquete proprietário e o NCache O servidor é arquitetado para que o código Java do lado do servidor seja executado em sua própria JVM.
Portanto, todo o desenvolvimento, teste e depuração que você fará serão todos em processos JVM nativos. E esse processo de cache chamará, digamos, o manipulador Read-through que irá para, digamos, talvez Oracle ou Db2, ou mesmo banco de dados SQL Server e obterá os dados e os entregará ao processo de cache. Novamente, o mesmo RPC na memória de alto desempenho é usado. Então, por ter uma arquitetura que encapsula o código .NET e Java em seus próprios processos nativos, NCache é capaz de fornecer uma pilha nativa para Java e .NET.
E novamente no caso de uma aplicação Java você pode querer fazer seu desenvolvimento no Windows ou Mac OS e NCache suporta completamente, ou mesmo Linux e, então é mais provável que você use Docker e Kubernetes, do que o pessoal do .NET NCache fornece as imagens Docker e também suporte completo para Kubernetes, Azure AKS, AWS EKS, Google GKE ou Red Hat OpenShift. Você pode usá-lo de uma forma muito simples.
então, NCache é muito único. Ele oferece uma experiência nativa em .NET e, ao mesmo tempo, uma experiência nativa em Java. Então, se você é uma loja Java, você não sente que está usando um produto não-Java e se você é uma loja .NET, você não sente que está usando um produto não .NET. Produto NET. Essa é a beleza de NCache a forma como é arquitetado.
Cluster Dinâmico
Ok, vamos agora entrar no Clustering dinâmico parte de NCache Arquitetura que é para alta disponibilidade. E, um segundo, ok. Então, a primeira parte é o Cluster Dinâmico. Quando uso a palavra cluster, não me refiro ao cluster Kubernetes, qualquer outro cluster em nível de sistema operacional. Isso é NCachedo próprio cluster baseado em TCP. E este cluster tem uma arquitetura ponto a ponto. O que ponto a ponto significa é que não há mestre, não há escravo. O problema do mestre/escravo é que, se o mestre falhar, o escravo se tornará inoperante ou limitado, enquanto em uma arquitetura ponto a ponto, cada nó é igualmente capaz. Obviamente, existe um nó coordenador de cluster, que é o nó mais antigo e, se esse nó ficar inativo, o próximo mais antigo será automaticamente selecionado como o coordenador do cluster. O coordenador do cluster faz a associação ao cluster. Ele gerencia o mapa de distribuição, a integridade do cluster e um monte de outras coisas que discutirei um pouco sobre isso.
O Cluster Dinâmico significa que você pode adicionar ou remover servidores do cluster em tempo de execução sem parar o cache ou seu aplicativo. Não há interrupção. E, quando você, digamos, adiciona um novo servidor ao cluster, a associação ao cluster é obviamente atualizada em tempo de execução e essas informações de tempo de execução são então propagadas para os clientes. E falarei um pouco mais sobre isso no próximo slide.
Há também um recurso de failover de conexão de cluster. Portanto, como são soquetes, embora os servidores do cluster geralmente estejam na mesma sub-rede, bastante próximos uns dos outros, isso nem sempre é o caso. Temos clientes que possuem servidores implantados em regiões diferentes e funciona perfeitamente bem, embora recomendemos que na maioria dos casos, o NCache os servidores devem estar bem próximos uns dos outros. Mas ainda pode haver falha na conexão. Se esse é o caso NCache tem uma lógica de novas tentativas e há tempos limites. Existe uma lógica de pulsação, tudo isso para garantir que tudo seja dinâmico.
Clientes dinâmicos e configuração dinâmica
Conexões de cliente dinâmicas
A outra parte da arquitetura dinâmica são os Clientes Dinâmicos. Assim, assim, o cluster tinha a capacidade de adicionar ou remover servidores em tempo de execução e você também tinha a capacidade de adicionar ou remover clientes em tempo de execução. O que significa um cliente? Um cliente é o NCache Cliente que roda no seu servidor de aplicação, seu servidor web, é a parte com a qual sua aplicação se comunica. Então, você pode adicionar um cliente em tempo de execução, você pode remover um cliente em tempo de execução sem parar NCache, o cache ou seu aplicativo sem qualquer interrupção. Então, essa é a primeira parte.
Configuração dinâmica
A segunda parte é a Configuração Dinâmica. Então, como mencionei no último slide, quando você adiciona um servidor ao cluster, a associação ao cluster muda. Bem, isso é propagado para todos os clientes existentes que estão conectados, de modo que agora eles sabem que há um novo servidor ao qual precisam se conectar. Portanto, se optarem por isso com base na topologia de cache, eles também poderão se conectar a esse servidor. Adicionalmente, dependendo da topologia pode haver um Mapa de Distribuição. Um Mapa de Distribuição é mais para cache particionado e cache de réplica particionada. Mas, conforme você adiciona um servidor, ele é atualizado e propagado em tempo de execução. E também várias outras alterações de configuração. Há um recurso de aplicação a quente que você pode fazer e que é propagado em tempo de execução. Então, essa é a segunda parte.
Failover de conexão do cliente
A terceira parte é: novamente, há um failover de conexão do cliente, que é da mesma forma que o failover de conexão do cluster. Mas, na verdade, isso é ainda mais necessário porque os clientes provavelmente não estarão sempre muito próximos dos servidores do cluster. E podem ser alguns roteadores ou firewalls intermediários. Portanto, é mais provável que a conexão entre os clientes e o cluster seja interrompida. Então, NCache tem capacidade de repetição bastante inteligente, tempo limite. Também existe a capacidade de manter ativo, para que o cliente permaneça conectado mesmo que a conexão seja interrompida, o cliente se reconecte ao NCache Conjunto.
Detecção e recuperação de cérebro dividido
Outro tópico importante do aspecto dinâmico da NCache Arquitetura é o Cérebro Dividido. O Split Brain é um fenômeno que pode ocorrer no cluster.
A divisão do cérebro ocorre no rompimento da conexão
E Split Brain ocorre sempre, digamos, se você tiver um cluster íntegro de seis servidores, um split-brain ocorre quando a conexão entre alguns desses servidores é interrompida por algum motivo e, sempre que você tiver conexões de rede, elas podem ser interrompidas. E vemos isso o tempo todo. Então, quando isso acontece, os subclusters são formados. Digamos que neste caso haja uma divisão 1, divisão 2, divisão 3. Cada subcluster pensa que é o sobrevivente. Assim, ele cria seu próprio coordenador de cluster e se torna um cluster independente.
Detecção de cérebro dividido
Porém, todas essas divisões lembram que faziam parte de um cluster íntegro e esses servidores não saíram por vontade própria, não saíram de maneira tranquila. Você não fez um 'nó de saída' do NCache Ferramenta de gerenciamento, em vez disso, a conexão foi interrompida. Assim, eles continuarão procurando esses servidores para ver se a conexão de rede foi restaurada. E, na maioria das vezes, talvez cinco, dez minutos, meia hora, uma hora depois, essa conexão provavelmente será restaurada.
Recuperação do cérebro dividido
Quando isso acontece, é feita uma recuperação do cérebro dividido. E é aí que essas divisões são mescladas. Esses subclusters são mesclados de forma iterativa, do maior para o menor, e há alguma perda de dados, obviamente, porque eles se tornaram clusters independentes e agora alguns dos dados precisam ser perdidos. Mas tudo é feito automaticamente com base nas regras que você especifica.
Há mais detalhes sobre o cérebro dividido em um separado vídeo mas isso dá uma visão geral. É um recurso muito importante que garante que seu NCache cluster permanece saudável e pode se recuperar sempre que ocorrer uma divisão cerebral.
Topologias de cache
Ok, agora vamos passar para Topologias de cache. Topologias de cache são essencialmente armazenamento de dados, estratégias de replicação e também estratégias de conexão do cliente. Existem quatro topologias, uma é Cache Particionado, Réplica de Partição, Cache Replicado e Cache Espelhado. Vamos com o cache particionado.
Cache Particionado
Cache Particionado é basicamente que todo o cache é dividido em partições, cada servidor possui uma partição. E existe esse conceito de baldes. Portanto, cada partição possui buckets. Um total de 100 buckets para todo o cache. Portanto, dependendo de quantas partições você tiver, esses buckets serão divididos igualmente entre eles.
E essas partições são criadas em tempo de execução, essa é a parte importante disso. Assim, conforme você adiciona um servidor, uma partição é criada. Digamos que você comece com um servidor, há apenas uma partição, todos os 100 buckets estão nessa partição. Se você adicionar um segundo servidor em tempo de execução, não apenas as informações de associação do cluster serão atualizadas, como mencionei nos slides anteriores, mas agora o mapa de distribuição também será atualizado. Um mapa de distribuição é essencialmente um mapa de qual partição contém quais buckets. Então, digamos que se você adicionou uma segunda partição, o mapa de distribuição será alterado. Um mapa de distribuição é, na verdade, um mapeamento de mapa hash para buckets. O valor do mapa hash varia até buckets. E isso não muda com base na quantidade de dados que você adicionou, muda apenas quando você altera o número de servidores, o número de partições ou faz o rebalanceamento de dados. Portanto, as partições são dinâmicas.
Balanceamento Dinâmico de Dados
A segunda parte é que existe balanceamento dinâmico de dados. Portanto, como tudo isso é baseado em mapas de hash, é muito possível que, com base no tipo de chaves que você usou, alguns dos buckets obtenham mais dados do que outros. E você vai acabar com algumas partições quase cheias e outras quase vazias. E, quando isso acontece NCache tem esse recurso onde você pode definir um limite. Digamos que se uma partição ficar mais de 80% cheia, remova 20% dela, ou 10% dela, ou 5% dela. Não remover, quero dizer, equilibrar dinamicamente. Portanto, balanceamento de dados significa pegar esses buckets da partição 1 e copiá-los para outra, ou movê-los para outras partições. Portanto, o balanceamento de dados garante que os dados e todas as partições sejam bastante uniformes.
Cliente se conecta a todas as partições
No cache particionado, cada cliente se conecta a todas as partições ou a todos os servidores. A razão pela qual isso é feito é porque ele deseja acessar diretamente qualquer item desejado em uma chamada. Se ele estivesse conectado apenas a um servidor, digamos, e quisesse o item número 3, ele falará com o servidor 1, o Servidor 1 irá para o servidor 2 e o pegará. E essa é uma operação de dois saltos que não é tão otimizada como se o cliente pudesse ir diretamente para onde os dados estavam. E o cliente sabe disso por causa de um mapa de distribuição. É por isso que o mapa de distribuição é criado para ajudar os clientes a saber onde estão os dados, para que possam ir buscá-los diretamente a partir daí.
Portanto, o cache particionado não tem replicação. Portanto, se algum servidor cair, você perderá esses dados. Não tem como, exceto se você usar 'Persistência', sobre o qual falarei daqui a pouco. Assim, mesmo o cache particionado não perde nenhum dado.
Cache de réplica de partição
Réplicas de Partições (Dinâmicas)
A próxima topologia é o cache de réplica de partição. A propósito, esta é nossa topologia mais popular porque oferece o melhor dos dois mundos. Dá a você o particionamento, que é a escalabilidade. E também oferece replicação, que é a alta disponibilidade. Portanto, não há perda de dados. Então, por exemplo, é da mesma forma que o Cache Particionado, tudo é igual, mas cada partição agora tem uma réplica em um servidor diferente. Então, a partição um está no Servidor 1, então sua réplica é chamada de Réplica 1, que é, digamos, neste caso, no Servidor 2. Assim, assim como as partições foram criadas dinamicamente no momento, as réplicas também são criadas em tempo de execução, quando as partições são adicionados ou removidos. E obviamente eles estão sempre localizados em um servidor diferente.
A outra parte é que todas as réplicas são passivas. Passivo significa que nenhum cliente fala diretamente com eles. Os clientes significam que eles apenas conversam com as partições e as partições atualizam sua réplica. Portanto, sempre que você atualiza algo na partição, a partição atualiza na réplica. E essa atualização por padrão é assíncrona. Assíncrono é, para que possa ser mais rápido. Em primeiro lugar, o cliente não precisa esperar que a replicação aconteça; em segundo lugar, você pode fazer uma replicação em massa. Assim, você pode combinar centenas ou milhares dessas atualizações e movê-las ou enviá-las para a réplica de uma só vez. Porque o custo dessa viagem de rede é muito mais rápido ou muito mais caro do que combinar dados.
Replicação assíncrona/sincronizada
No entanto, a replicação assíncrona obviamente nem sempre é consistente. Eventualmente, é consistente, o que é bom o suficiente para talvez 95% a 99% das vezes e há talvez 1 a 5% dos casos em que você está lidando com dados muito confidenciais. Então, você não quer replicação assíncrona, você quer replicação síncrona. Portanto, há um recurso chamado Sync Replication que você pode ativar e, quando fizer isso, sempre que o cliente atualizar itens na partição, essa operação não será concluída até que a partição atualize a réplica primeiro. Portanto, se essa replicação falhar, a operação falhará. Então, é assim que, se a operação foi bem-sucedida, a replicação também foi bem-sucedida. Então, essa é uma característica muito importante disso.
E, finalmente, assim como a topologia particionada, a topologia de cache particionado também há balanceamento dinâmico de dados nas réplicas. Portanto, quando as partições são balanceadas dinamicamente em termos de dados, as réplicas devem corresponder a isso porque as réplicas são sempre uma cópia idêntica da partição. Então, eles também passarão por um balanceamento de dados.
Particionamento dinâmico
Vamos agora ver rapidamente como o particionamento dinâmico realmente ocorre. Então, digamos, se você tivesse um cluster de dois servidores e tivesse 6 itens nele e quisesse adicionar um terceiro servidor, não estou adicionando mais dados ainda porque esse é outro caso de uso, é assim que os dados são transferido para outras partições conforme você adiciona outro nó.
Digamos que você adicione um nó. Então, há um terceiro servidor agora. Então, a Partição 3 é criada e a Partição 3 agora obtém dados da Partição 1 e da Partição 2. Então, ela obtém alguns dados de 1 e alguns de 2. Então, digamos, digamos que ele pega o Item 3 da Partição 1, o Item 4 da Partição 2 e se torna a Partição 3.
Agora que se tornou a Partição 3, sua réplica tem que estar em um servidor diferente, então, digamos, ela é colocada no Servidor 1. Então, o Servidor 1 costumava ter a Réplica 2, ele é convertido na Réplica 3 e então a Réplica 2 é movida no Servidor 3. Então, por exemplo, agora a Réplica 3 conterá 3, 4 em vez de 4, 5, 6, e a Réplica 2 conterá 5, 6. Tudo isso será feito dinamicamente em tempo de execução sem que seu aplicativo veja qualquer interrupção.
A mesma coisa acontece ao contrário: se um servidor cair, digamos, você tinha três partições NCache Cluster e, Servidor 3 caiu, ou você desligou ou caiu, assim que isso acontecer, porque a Partição 3 não está mais disponível. Réplica 3, como vocês podem ver mudei a cor, ela fica ativa. Normalmente, como falei, as réplicas não ficam ativas, certo? Apenas as partições estão ativas, mas agora isso se torna particionado. Mas é apenas temporário porque você não deseja ter duas partições na mesma caixa e nenhuma réplica.
Então, agora isso se funde aqui com a Partição 1, então, digamos, o Item 3 vai para a Partição 1, o Item 4 vai para a Partição 2, e sua situação é assim aqui e esta Réplica 3 agora se torna Réplica 2. Então, o a mesma coisa acontece ao contrário, tudo em tempo de execução, Particionamento Dinâmico, muito, muito flexível, muito dinâmico. Essa dinâmica adiciona o poder de alta disponibilidade do NCache.
Modo de Manutenção
Bem, embora esse particionamento dinâmico seja muito útil e poderoso, há alguns casos em que você não deseja reparticionar e um desses casos é a manutenção agendada. Digamos que você esteja fazendo um patch no sistema operacional e esse patch deixará o servidor inativo por cinco ou dez minutos. Bem, você sabe que todo o seu cluster de cache pode ter dezenas de gigabytes de dados. Portanto, você não deseja reparticionar apenas por cinco minutos e depois reparticionar novamente quando ativar o nó novamente. Assim, você pode ativar um recurso de manutenção agendada de NCache nesse caso, quando você desativa este nó, novamente você tem que desativá-lo através de sua ferramenta de gerenciamento, isso aciona que esta réplica se torna ativa, mas não há reparticionamento.
Portanto, ele permanece como configuração de dois servidores com Partição 1 Réplica 3, Partição 2 Réplica 1 e esta Réplica 3 é na verdade Partição 3, o que significa que está ativa e operando. Obviamente, não é alta disponibilidade porque embora o backup da Partição 1 seja feito aqui. A partição 2 não tem backup e a réplica 3 não tem backup. Mas isso é apenas temporário porque você só precisa dele por 5, 10 minutos. Assim, quando este servidor voltar a funcionar, ele voltará ao estado antigo e se tornará uma réplica novamente quando se tornar uma partição novamente. Então, é assim que o recurso de manutenção programada do NCache obras.
Cache replicado
A próxima topologia é chamada de Cache replicado. Nesta topologia você pode ter dois ou mais servidores onde cada servidor possui uma cópia inteira do cache e cada servidor está ativo, o que significa que cada servidor possui clientes conectados a ele. Mas aqui cada cliente se conecta apenas a um servidor. Porque esse servidor possui todo o cache. Portanto, não é necessário conectar-se a dois servidores como partição ou réplica de partição.
Nessa topologia, todas as leituras são super rápidas porque todo o cache está ali, mas as atualizações têm que ser feitas de forma síncrona. Porque ambos são servidores ativos, portanto, o mesmo item pode ser atualizado aqui e aqui simultaneamente e você obviamente não quer entrar em um problema de integridade de dados. Então, isso é feito de forma síncrona, onde há um esquema de indexação, há um índice, na verdade há um número de sequência que é emitido e cada item é atualizado na mesma sequência. Então, isso permite que as atualizações sejam feitas sempre de forma correta. No entanto, o custo é que uma atualização síncrona significa que se você tiver um cliente que atualiza o Item 1, este Servidor notificará o Item 2 para atualizar o Item 1. Quando ambos os servidores atualizarem o Item 1 com sucesso, somente então a atualização será bem-sucedida e o controle remonta. Então, isso significa que não é tão rápido quanto a topologia de Partição ou Réplica de Partição, mas a operação é garantida, se a atualização for bem-sucedida, isso significa que ela sempre será feita em todos os servidores.
Essa topologia é boa para operações com uso intensivo de leitura. Para um cluster de dois servidores, até mesmo as gravações são bastante rápidas, não tão rápidas quanto a réplica de partição, mas razoavelmente rápidas para a maioria das situações. No entanto, à medida que você adiciona mais servidores, o desempenho das atualizações diminui. Na verdade, fica mais lento porque mais servidores precisam ser atualizados de forma síncrona. Então, essa topologia tem usos próprios, por isso a mantemos. Muitos de nossos clientes o utilizam em situações especiais.
Cache espelhado
A quarta topologia é chamada de Cache espelhado. Esta é novamente uma topologia muito específica. É uma topologia de apenas 2 nós. Há um nó ativo e um nó passivo. Novamente, o nó ativo possui todo o cache e uma cópia do cache fica no nó passivo. Todos os clientes se conectam ao nó ativo e atualizam o nó ativo para todas as coisas, e as atualizações são espelhadas ou replicadas de forma assíncrona para o nó passivo. E isso assíncrono significa que também é muito rápido, assim como o Partition Replica.
Nesta topologia, se o nó ativo cair, o nó passivo torna-se automaticamente ativo e todos os clientes passam automaticamente para o nó passivo ou recém-ativo. E, dessa forma, não há tempo de inatividade, não há interrupção e, isso é chamado de suporte automático de failover, é isso que eu quis dizer com isso. E, obviamente, quando o nó ativo volta, ele se torna ativo novamente, a mesma coisa acontece ao contrário.
Portanto, Mirror Topology também é muito útil para casos especializados. Não é escalável além desses dois servidores, mas tem seu próprio uso devido ao fato de que todos os clientes se conectam aqui, e então você pode fazer uma réplica em uma caixa diferente. Quero dizer que isso poderia ser usado, por exemplo, em caso de situação de recuperação de desastres, por exemplo.
Persistência ao Vivo
Outro recurso muito poderoso do NCache é chamado Persistência ao Vivo. O Live Persistence está disponível apenas para topologias de partição e réplica de partição e é ativo, o que significa que à medida que você atualiza o cache em tempo de execução, o armazenamento de persistência também é atualizado imediatamente. A atualização do armazenamento persistente é assíncrona. Portanto, isso não interfere no desempenho do seu aplicativo ou NCache desempenho. Então é assim que seu aplicativo pode ficar muito rápido. A persistência é feita no nível do bucket. Portanto, existem 100 buckets que representam todo o cache que são mantidos em um NoSQL armazenamento de documentos. É um armazenamento baseado em arquivo, portanto não é um armazenamento baseado em servidor. Não é um NoSQL database servidor, é um NoSQL armazenamento de documentos que NCache usa. Você pode usá-lo em um local comum a todos os servidores do NCache cluster e, dessa forma, todos podem contar com o mesmo armazenamento persistente.
Alguns dos benefícios disso são, e a razão pela qual esse recurso é fornecido, o número um é que, seja o que for que você esteja persistindo, você pode, por exemplo, persistir todo o cache, e todo o cache sempre será persistido. Você pode dizer que tudo o que você está atualizando no cache, com a diferença de alguns milissegundos, também é mantido no armazenamento persistente. Portanto, você pode pegá-lo e recarregá-lo em um cache diferente ou, se todos os servidores ficarem inativos, você poderá reiniciá-los a partir dos armazenamentos persistentes. Você não perde nenhum dado, exceto uma quantidade muito pequena de dados. Ou talvez você queira levar o cache de um ambiente para outro, você pode fazer isso facilmente.
O outro benefício é que ele realmente adiciona mais alta disponibilidade às topologias de partição e de réplica de partição. Bem, topologia de partição, e abordarei isso aqui. Então, o Cache Particionado como mencionei anteriormente não tem nenhuma replicação, então, se alguma partição, algum servidor cair você perde essa partição, certo? Bem, se você tiver persistência, então não. Porque uma cópia desses dados também está sendo mantida nesses buckets. Então, se este servidor cair, os buckets na memória serão reatribuídos, mas obviamente sem dados para outros servidores e agora esses servidores sabem que esses são buckets vazios cujos dados existem no armazenamento de persistência, então, eles irão recarregar esses dados do armazenamento de persistência loja.
Então, é assim que você não perde nenhum dado, mesmo se um servidor cair, mesmo que você esteja usando o Partitioned-Cache. E você tem o mesmo benefício de uma réplica de partição que um cache particionado.
O benefício que você obterá aqui é que poderá usar mais memória. Você pode armazenar mais dados no cache porque aqui você precisa alocar mais memória para a réplica, que não precisa alocar aqui, mas precisa alocar o armazenamento de persistência. Então, esse é o benefício do cache particionado. Também há benefícios no Partition-Replica. E é interessante que, embora isso já esteja proporcionando alta disponibilidade, mas se a alta capacidade acontecer apenas se um servidor cair em qualquer momento, mas, digamos, se dois servidores caírem simultaneamente sem a persistência, mesmo no Partition-Replica você perderia dados. Porque, você sabe, há apenas uma cópia de cada partição e se dois servidores caírem, você perderá mais servidores do que pode. Bem, com persistência você não tem nenhum problema, basta recarregar todos os dados do armazenamento de persistência.
Obviamente, em ambos os casos, você deve ter em mente que sempre que você carrega dados do armazenamento de persistência, você tem três servidores e agora tem dois. Bem, os dados podem valer muito para caber nos dois servidores. Outro problema com o qual você precisa lidar é garantir que você tenha memória suficiente nesses dois servidores restantes para que possa acomodar o equivalente a todos os três. servidores. Então, essa é a única limitação. Caso contrário, a persistência realmente agrega valor ao cache particionado e à réplica de partição.
Cache de cliente
Ok, outra característica muito importante do NCache é chamado Cache de cliente. Oferece velocidade InProc em um ambiente de loja distribuída. Então, por exemplo, você tem um distribuído NCache cluster, seu aplicativo está sendo executado aqui, geralmente é um cache no topo do seu banco de dados ou qualquer outra coisa que você esteja fazendo, um cache de cliente geralmente é usado quando você tem um cenário de cache distribuído e um cache de cliente é um cache em cima de esse cluster de cache e fica muito próximo do seu aplicativo. Ele fica no servidor de aplicativos ou no NCache caixa do cliente. E pode até ser InProc ou OutProc dependendo da sua preferência. Um cache InProc é super rápido porque, na verdade, mantém os dados em um formato de objeto desserializado em seu heap. Então, é como ter esse objeto na sua pilha. Pode ser mais rápido que isso.
Portanto, um cache InProc é super rápido, mas ao mesmo tempo a beleza é que ele é sincronizado com o NCache conjunto. E a forma como é sincronizado é o que é mantido no Cache do Cliente que o cluster conhece. Portanto, se algo que foi mantido neste Cache do Cliente outro Cliente for atualizado no cluster, o cluster notificará esse Cache do Cliente para se atualizar. E então esse Cache do Cliente se atualiza de forma assíncrona. Obviamente, há um atraso de alguns milissegundos, mas isso, como eu disse, a consistência eventual é o modelo na maioria dos casos, e isso geralmente é aceitável em 99% dos casos.
Se isso não for aceitável então NCache fornece a você... e a sincronização otimista é o padrão, onde há um atraso de alguns milissegundos e pode haver tecnicamente uma situação em que você tenha dados obsoletos, o que é bom, como eu disse, 99% das vezes. Mas, digamos, se não estivesse tudo bem e seus dados fossem muito confidenciais, mas você ainda quisesse usar o Cache do Cliente, você poderia usar um recurso de sincronização pessimista, onde garante que antes de seu aplicativo buscar qualquer coisa do Cache do Cliente, o Cliente O cache verifica apenas se há uma versão mais recente desses dados, é uma chamada mais rápida do que obter os dados em si porque, NCache em seguida, mantém várias informações de controle de versão. E, se houver uma versão mais recente desses dados, o Cache do Cliente os buscará; caso contrário, ele apenas os retornará do Cache do Cliente.
Um cache de cliente que você pode usar sem nenhuma alteração de código. Ele simplesmente se conecta ao seu ambiente e é bom para situações de leitura intensiva. Onde você faz muito mais leituras, pelo menos 5:1, 10:1 é o ideal, mas quando há 1:1, digamos, no caso de sessões da Web, o Cache do Cliente na verdade não ajuda em nada. Na verdade, não é nada recomendado.
Replicação de WAN
Multizona/Multirregião
Ok, outra parte NCache é o onde NCache parece Replicação de WAN para lidar com a implantação multizona ou multirregião de seus aplicativos. Assim, por exemplo, você poderia ter seu aplicativo implantado em dois sites diferentes para DR, para recuperação de desastres, um ativo e outro passivo. E você tem esse aplicativo, um NCache rodando com ele, e você tem um aplicativo aqui que não está rodando. Mas você quer ter certeza de que, se este site cair, ele será capaz de pegar a carga imediatamente. Então, você pode colocar uma ponte. Uma ponte é um cluster de 2 nós que pode estar nas mesmas caixas que o NCache main, ou pode ser um dedicado separado, depende de você. E tudo o que você atualizar nesse cache será replicado de forma assíncrona na WAN para o outro cache. Então, esse é o ativo-passivo.
Você pode fazer a mesma coisa com um ativo ativo. Digamos que se você tiver uma situação em que até mesmo este site esteja ativo, você pode fazer exatamente a mesma coisa com um ativo-ativo, onde ambos os sites podem atualizar um ao outro. Nesse caso, há também uma situação em que o conflito pode ser resolvido, pode surgir. E o que significa conflito é que o mesmo item, a mesma chave, está sendo atualizado em ambos os sites simultaneamente. Se isso acontecer, a ponte, por padrão, aplica a lógica 'última atualização vence'. Portanto, o que tiver o carimbo de data/hora posterior em que a atualização vencerá. Mas, por exemplo, se você quiser, também pode fornecer um manipulador de resolução de conflitos e de resolução de conflitos, que é o seu código .NET ou Java que a ponte chamará e passará ambas as cópias dos dados ou do objeto para esse manipulador de resolução e então você pode analisar o conteúdo para determinar qual é o mais correto e então dizer, ok, esta atualização vence e então essa atualização é aplicada a ambos os sites. Desde que isso seja aplicado a ambos os lados, não haverá conflito.
A NCache tem a capacidade de fornecer três ou mais sites em modo ativo-ativo, ou ativo-passivo, ou alguma combinação deles. Então, por exemplo, você precisa de pelo menos um ativo, mas todos podem ser passivos ou todos podem ser ativos ou podem ser uma combinação de ativo ou passivo. E, novamente da mesma forma, quando há mais de um ativo, isso pode ser uma resolução de conflito.
Contêineres (Docker e Kubernetes)
Finalmente, os contêineres se tornaram Docker e Kubernetes realmente populares. Então, NCache obviamente os suporta porque eles são mais populares no lado Java e Linux do que no lado .NET e Windows, mas tenho certeza que isso vai mudar, você sabe, com o tempo. Então, de qualquer forma, NCache é totalmente capaz de lidar com isso em ambos os ambientes. Então, por exemplo, aqui está um típico Implantação do Kubernetes de NCache.
Aqui está um NCache Implantação. Há NCache tem seu próprio serviço de descoberta. Esses são pods que podem ser escalonados e você tem aplicativos no cluster Kubernetes que são NCache clientes e podem ser Azure, AKS, AWS, EKS, Google GKE ou Red Hat OpenShift. O Red Hat OpenShift geralmente é outra nuvem como AWS, Azure ou Google ou talvez outra nuvem, mas NCache apoia todos eles. E este Pod pode ser Linux, que é o caso mais comum no Kubernetes, e NCache funciona perfeitamente bem. E o aplicativo também pode ser Linux ou Windows. Então, podem ser Linux ou Windows, Linux ou Windows.
Docker/Kubernetes (multizona)
Da mesma forma que a replicação WAN entra em ação, se você quiser, digamos, por causa da nuvem, você pode ter várias zonas de disponibilidade. Você queria fazer um Kubernetes multizona.
Então, a forma que recomendamos é você criar um cluster Kubernetes, ter dois NCache implantações, estas podem ser ativo-ativo ou ativo-passivo. E então a ponte pode ficar completamente aqui ou completamente aqui. Ou você pode até ter uma divisão de ponte onde uma parte está nesta zona e outra parte está naquela zona e então a replicação acontece de forma assíncrona.
Acho que isso cobre bastante o assunto hoje. Eu recomendo fortemente que você visite nosso site e dê uma olhada em NCache Playground que é realmente uma maneira muito rápida e fácil do seu navegador usar uma cópia ao vivo do NCache, e você pode até obter um 2 nós NCache Cluster com todas as ferramentas sem nenhum esforço de instalação. Ou se você estiver pronto, venha aqui e cadastre-se e baixe ou NCache Enterprise para edição .NET ou NCache Enterprise para edição Java. Como eu disse, você pode obter o .tar.gz para Linux, .msi ou também o Docker. Você pode simplesmente extrair uma imagem do Docker de NCache. Esse é o fim da minha apresentação. Muito obrigado.