NCache Arquitetura

Cluster ponto a ponto (autocorreção)

NCache cluster tem uma arquitetura de cluster ponto a ponto. Isso significa que não há nós Mestre/Escravo e cada servidor é um par. Há um nó Coordenador de Cluster que é o nó mais antigo do cluster. Se o nó Coordenador de Cluster ficar inativo, o próximo mais antigo se tornará automaticamente o coordenador.

O Coordenador de Cluster gerencia todas as operações relacionadas ao cluster, incluindo a associação ao cluster quando os nós são adicionados ou removidos, mapa de distribuição para Cache Particionado / Cache de réplica de partição topologia e outras informações de configuração de cache. O Coordenador de Cluster também gerenciou a integridade do cluster e remove à força quaisquer servidores de cache que estejam parcialmente conectados a todos os outros servidores no cluster.

Clustering dinâmico

NCache tem um arquitetura de cluster dinâmico. Isso significa que você pode adicionar or remover qualquer servidor de cache do cluster sem interromper o cache ou os aplicativos. Sempre que você adiciona ou remove um servidor de cache, a associação ao cluster é atualizada imediatamente no tempo de execução e propagada para todos os servidores no cluster, bem como para todos os clientes conectados ao cluster. Esta atualização e propagação em tempo de execução permitem NCache estar sempre em funcionamento, mesmo quando tais alterações estão sendo feitas.

O clustering dinâmico permite que você faça o seguinte:

• - Adicionar/remover servidores de cache em tempo de execução: sem parar o cache ou seu aplicativo
• - Associação ao cluster: é atualizado em tempo de execução e propagado para todos os servidores no cluster e todos os clientes conectados ao cluster.

Manipulação de cluster cerebral dividido

Outra parte de NCache Clustering Dinâmico é seu inteligente Detecção e recuperação de cérebro dividido capacidade. A divisão cerebral ocorre essencialmente quando, devido a alguns problemas de rede, a conexão de rede é interrompida entre esses servidores de cache e isso resulta em vários subclusters independentes, onde cada subcluster assume que todos os outros servidores de cache ficaram inativos e é o cluster restante correto .

Em tais casos, NCache os servidores percebem que os outros servidores de cache deixaram o cluster abruptamente e continuam tentando se reconectar a eles. Então, quando o problema da rede desaparecer, esses NCache os servidores são capazes de se reconectar com os outros servidores de cache. Porém, agora cada subcluster atualizou o cache em paralelo sem sincronizar com outros servidores de cache e, portanto, existem várias versões dos dados nos subclusters.

NCache fornece uma maneira de se recuperar dessa “divisão cerebral”, decidindo automaticamente quais servidores de cache devem ceder seus dados e outros servidores de cache devem manter seus dados. Há alguma perda de dados, mas o resultado final é uma restauração rápida do cluster de cache sem qualquer intervenção humana.

Conexões de cliente dinâmicas

NCache também permite que você adicionar ou remover clientes de cache em tempo de execução sem parar o cache ou outros clientes. Quando você adiciona um cliente, esse cliente só precisa saber sobre qualquer servidor de cache no cluster ao qual se conectar. Depois de se conectar a esse servidor, ele recebe informações de associação ao cluster e de topologia de cache com base nas quais decide a quais outros servidores se conectar.

• - Adicionar/remover clientes em tempo de execução: sem parar o cache ou seu aplicativo.
• - Cache Particionado/Cache de Réplica de Partição: o cliente se conecta a todas as partições em todos os servidores de cache (não às réplicas porque as partições se comunicam com suas réplicas). Isso permite que o cliente vá diretamente para onde estão os dados para leituras e gravações. E, se um novo servidor for adicionado ao cluster, o cliente receberá informações atualizadas de associação ao cluster e também se conectará a esse servidor de cache recém-adicionado.
• - Cache replicado: no caso de Cache replicado, o cliente apenas se conecta a um servidor de cache no cluster, mas com balanceamento de carga para garantir que todos os servidores de cache tenham o mesmo número de clientes. O cliente obtém as informações de balanceamento de carga desse servidor de cache e, com base nisso, se necessário, ele se reconecta ao servidor de cache apropriado. O cliente se conecta a apenas um servidor de cache porque cada servidor tem todo o cache, então todas as leituras e gravações são possíveis ali mesmo.
• - Cache espelhado: no caso de Cache espelhado, o cliente se conecta apenas ao nó ativo neste cluster de 2 nós. Se o cliente se conectar ao nó passivo, o nó passivo informará ao cliente sobre o nó ativo e o cliente se reconectará automaticamente ao nó ativo. Se o nó ativo ficar inativo e o nó passivo se tornar ativo, todos os clientes se conectarão automaticamente ao novo nó ativo.

Configuração dinâmica

NCache também fornece configuração dinâmica do cache e dos clientes. O objetivo é permitir que você faça alterações posteriormente quando o cache estiver em execução sem interromper o cache ou seu aplicativo.

• - Propague para todos os servidores e clientes em tempo de execução: inclui todas as configurações e suas alterações e também o Mapa de Distribuição.
• - Configuração de cache: quando uma configuração de cache é criada por meio de ferramentas administrativas, essas informações de configuração são copiadas para todos os servidores de cache conhecidos naquele momento. E qualquer novo servidor adicionado em tempo de execução recebe toda essa configuração de cache e a copia para seu disco local.
• - Mudanças de configuração de aplicação a quente: você pode alterar algumas configurações de cache em tempo de execução através de um "Aplicação a quente"característica de NCache. Ao fazer isso, as informações de configuração atualizadas são propagadas para todos os servidores de cache em tempo de execução e salvas em seus discos. Uma parte desta informação também é enviada a todos os clientes que sejam relevantes para as suas necessidades.
• - Mapa de Distribuição (Cache Particionado/Réplica de Partição): é criado quando o cache é iniciado e depois copiado para todos os servidores e clientes de cache. Este Mapa de Distribuição contém informações sobre quais buckets (de um total de 1000 buckets no cache clusterizado) estão localizados em qual partição.

Failover de conexão no cluster

Todos os servidores de cache no cluster estão conectados uns aos outros por meio de TCP. E cada servidor de cache está conectado a todos os outros servidores de cache no cluster, incluindo quaisquer novos servidores adicionados em tempo de execução. NCache fornece várias maneiras de garantir que todas as conexões dentro do cluster sejam mantidas vivas apesar da quebra de conexão. A quebra de conexão geralmente ocorre devido a uma falha de rede devido a um roteador ou firewall ou a um problema com a placa de rede ou driver de rede.

• - Novas tentativas de conexão: se a conexão entre dois servidores de cache for interrompida, NCache servidor faz automaticamente várias tentativas para estabelecer esta conexão. Essas novas tentativas são feitas até que o período de “tempo limite” se esgote. Na maioria das situações, isso restabelece a conexão.
• - Batimento cardíaco mantido vivo: NCache também tem um recurso para que cada servidor de cache continue enviando alguns pequenos pacotes de dados como batimentos cardíacos para todos os outros servidores. Isso garante que, se houver um problema de quebra de soquete de rede, os servidores de cache saberão sobre ele e o corrigirão por meio de novas tentativas.
• - Servidores Parcialmente Conectados: apesar das novas tentativas, há momentos em que uma conexão não é restaurada dentro do período de tempo limite e um servidor de cache assume que um ou mais dos outros servidores de cache estão inativos. Então, continua funcionando sem eles. Mas, na realidade, os outros servidores não estão inativos e são vistos por alguns outros servidores do cluster. Isso é chamado de servidores parcialmente conectados. Quando isso acontece, o Coordenador do Cluster toma nota disso e remove à força o servidor "Parcialmente Conectado" do cluster. Ao fazer isso, o cluster fica íntegro novamente. E o servidor removido pode ingressar novamente no cluster por meio de intervenção manual.

Failover de conexão com clientes

Todos os clientes de cache estão conectados a um ou mais servidores de cache no cluster por meio de TCP, dependendo das topologias de cache. Para Cache Particionado/Réplica de Partição, cada cliente está conectado a todos os servidores de cache. Para o Cache Replicado, cada cliente é conectado a apenas um dos servidores de cache, geralmente por meio de um algoritmo de balanceamento de carga usado pelos servidores de cache. E, para o Cache Espelhado, todos os clientes são conectados apenas ao Nó Ativo e só se conectam ao Nó Passivo quando o Nó Ativo fica inativo e o Nó Passivo se torna o Nó Ativo.

• - Novas tentativas de conexão: se uma conexão entre um cliente e servidores de cache for interrompida, NCache cliente faz automaticamente múltiplas tentativas de conexão para estabelecer essa conexão. Essas novas tentativas são feitas até que o período de "tempo limite" seja esgotado. Na maioria das situações, isso restabelece a conexão sem que o aplicativo cliente perceba. Se uma conexão não puder ser estabelecida, uma exceção será lançada para o aplicativo cliente para que ele possa tratá-la.
• - Batimento cardíaco mantido vivo: NCache também tem um recurso para que cada cliente continue enviando alguns pequenos pacotes de dados como batimento cardiaco para todos os servidores de cache aos quais está conectado. Isso garante que, se houver um problema de quebra de soquete de rede, o cliente saberá sobre ele e o corrigirá por meio de novas tentativas de conexão.
• - Clientes Parcialmente Conectados (Cache Particionado/Réplica de Partição): apesar das novas tentativas, há momentos em que uma conexão não é restaurada dentro do período de tempo limite e um cliente de cache assume que não consegue acessar um ou mais dos outros servidores de cache, mesmo que eles não estejam inativos. Assim, no caso do Cache Particionado / Réplica de Partição, ele interage com outros servidores para ler ou gravar todos os dados, mesmo que seu Mapa de Distribuição informe que o servidor com o qual ele não pode se comunicar possui os dados. Nesse caso, o outro servidor de cache atua como intermediário para executar a operação com sucesso.
• - Desconexão com Servidor (Cache Replicado/Espelhado): no caso de Cache Replicado, o cliente está conectado apenas a um servidor e se esta conexão for interrompida, o cliente se conecta automaticamente a um dos outros servidores de cache. No caso de Cache Espelhado, se o cliente não conseguir se conectar ao Nó Ativo, ele assume que está inativo e tenta se conectar ao Nó Passivo.

Topologias de cache (escalabilidade linear)

NCache fornece uma variedade de topologias de armazenamento em cache para permitir escalabilidade linear, mantendo a consistência e a confiabilidade dos dados. O objetivo disso é atender às necessidades de aplicativos executados com caches de dois servidores muito pequenos para clusters de cache muito grandes que consistem em dezenas ou até centenas de servidores de cache. Uma topologia de cache é essencialmente uma estratégia de armazenamento de dados, replicação de dados e conexões de cliente em um cache clusterizado que abrange vários servidores de cache.

Dados de referência versus dados transacionais

Dados de referência são dados que não são alterados com muita frequência e você os armazena em cache para alcançá-los repetidamente e ocasionalmente atualizá-los. Os dados transacionais, por outro lado, são dados que mudam com muita frequência e você pode atualizá-los com a mesma frequência que os lê.

No início, um cache era considerado bom principalmente para dados de referência porque os dados que eram alterados com frequência ficavam obsoletos e fora de sincronia com os dados mais recentes do banco de dados. No entanto, NCache agora fornece recursos muito poderosos que permitem que o cache mantenha seus dados em cache sincronizados com o banco de dados.

Todas as topologias de cache são boas para dados de referência, mas apenas algumas topologias de cache são especialmente melhores para dados transacionais. Você precisa determinar quantas leituras versus gravações você fará para descobrir qual topologia é melhor para você. Além disso, algumas topologias de cache não são tão escalonáveis, especialmente para atualizações, portanto, lembre-se disso também.

Abaixo está uma lista de topologias de cache junto com seu impacto em leituras versus gravações.

• - Cache particionado (sem replicação): muito bom. Super rápido para leituras e gravações e também dimensiona linearmente adicionando servidores. A topologia mais rápida, mas não replica dados, portanto, há perda de dados se um servidor de cache ficar inativo.
• - Cache de réplica de partição (Mais popular): muito bom. Super rápido para leituras e gravações e também pode ser dimensionado linearmente adicionando servidores. Segunda topologia mais rápida, mas replica dados para confiabilidade sem comprometer a escalabilidade linear. A melhor combinação de velocidade/escalabilidade e confiabilidade de dados.
• - Cache replicado: Muito bom para ambientes menores. Super rápido e linearmente escalonável para leituras. Moderadamente rápido para gravações em um cluster de 2 nós, mas não é dimensionado à medida que você adiciona mais servidores porque as gravações são feitas de forma síncrona em todos os servidores de cache.
• - Cache espelhado: Muito bom para ambientes menores. Super rápido para leituras. As gravações são mais rápidas que o cache replicado para ativo/passivo de 2 nós. Mas não vai além disso.
• - Cache de cliente: Muito bom para uso intensivo de leitura com todas as topologias de cache. Permite atingir a velocidade do InProc com um cache distribuído.

Cache Particionado

O Cache Particionado é a topologia de cache mais rápida e escalável para leituras e gravações. Destina-se a clusters de cache maiores e o desempenho de leituras e gravações permanece muito bom mesmo sob cargas de pico. No entanto, ele não replica dados e, portanto, há perda de dados se um servidor de cache ficar inativo.

Aqui estão algumas características do Cache Particionado.

• - Partições Dinâmicas: o cache é dividido em partições em tempo de execução, com cada servidor de cache tendo uma partição. Há um total de 1000 buckets por cache clusterizado que são distribuídos uniformemente por todas as partições. Adicionar/remover servidores de cache resulta na criação/exclusão de partições em tempo de execução. A atribuição de buckets às partições não muda quando os dados são adicionados ao cache. Em vez disso, ele só muda quando partições são adicionadas ou excluídas ou quando ocorre balanceamento de dados (veja abaixo).
• - Mapa de Distribuição: o cluster de cache cria um Mapa de Distribuição que contém informações sobre quais buckets existem em quais partições. O Mapa de Distribuição é atualizado sempre que partições são adicionadas ou excluídas ou quando ocorre balanceamento de dados (veja abaixo). O Mapa de Distribuição é propagado para todos os servidores e clientes. Os clientes usam isso para descobrir com qual servidor de cache conversar para ler ou gravar um determinado item em cache.
• - Balanceamento Dinâmico de Dados: como todos os buckets são, na verdade, buckets HashMap onde os dados são armazenados com base em um algoritmo Hashing nas chaves, há uma chance de que alguns buckets tenham mais dados do que outros, dependendo de quais chaves foram usadas. Se esse desequilíbrio ultrapassar um limite configurável, NCache automaticamente desloca os baldes para equilibrar essa carga.
• - Clientes se conectam a TODAS as partições: os clientes se conectam a todos os servidores de cache para que possam ler ou gravar dados diretamente em uma solicitação do servidor. Se a conexão de um cliente com um servidor de cache cair, ele solicitará a um dos outros servidores que leia ou grave um item em cache que existe no servidor e que ele não pode acessar. E esse servidor ajuda o cliente a conseguir isso.

Cache de réplica de partição

NOTA: tudo mencionado em Partitioned Cache é verdade aqui também.

Assim como Cache Particionado, Partition-Replica Cache é uma topologia de cache extremamente rápida e linearmente escalável para leituras e gravações. Destina-se a clusters de cache maiores e o desempenho de leituras e gravações permanece muito bom mesmo sob cargas de pico. Além disso, o Cache de Réplica de Partição também replica dados e, portanto, não há perda de dados, mesmo que um servidor de cache fique inativo.

O Cache de Réplica de Partição é nosso topologia de cache mais popular porque oferece o melhor dos dois mundos, desempenho/escalabilidade linear e confiabilidade de dados.

Abaixo estão algumas das características do Cache de Réplica de Partição.

• - Partições Dinâmicas: igual ao cache particionado.
• - Réplicas Dinâmicas: quando partições são criadas ou excluídas em tempo de execução, suas réplicas também são criadas ou excluídas. As réplicas estão sempre em um servidor de cache diferente e há apenas uma réplica para uma partição.
• - Replicação Assíncrona: por padrão, a replicação da partição para a réplica é assíncrona. Isso significa que o cliente pode adicionar, atualizar ou excluir quaisquer dados na partição e todas essas operações serão colocadas na fila. E então eles são replicados em GRANEL na réplica. Isso melhora o desempenho, mas apresenta um pequeno risco de perda de dados caso uma partição falhe e nem todas as atualizações tenham sido replicadas para a réplica. Mas, na maioria das situações, isso é perfeitamente normal.
• - Sincronizar replicação: se seus dados forem muito confidenciais (por exemplo, dados financeiros) e você não puder se dar ao luxo de ter dados obsoletos, poderá escolher a opção “Sincronizar Replicação” na configuração. Quando selecionada, todas as operações de gravação são executadas de forma síncrona na partição e na réplica até serem consideradas concluídas. Dessa forma, se a operação falhar na Réplica, também falhará na Partição. E você pode ter certeza de que todos os dados no cache (na partição e na réplica) serão sempre consistentes. No entanto, isso tem implicações no desempenho, pois é mais lento que a replicação assíncrona.
• - Mapa de Distribuição: igual ao cache particionado.
• - Balanceamento dinâmico de dados (partições e réplicas): igual ao cache particionado. No entanto, no cache de réplica de partição, o balanceamento de dados também ocorre nas réplicas quando os dados das partições são balanceados.
• - Clientes se conectam a TODAS as partições: igual ao cache particionado. Além disso, no cache de réplica de partição, os clientes se comunicam apenas com partições e não com suas réplicas. Isso ocorre porque as réplicas são passivas e somente as partições se comunicam com suas réplicas ao replicar dados para elas.

Cache replicado

O Cache Replicado fornece confiabilidade de dados por meio da replicação em dois ou mais servidores de cache. É muito rápido e escalável para leituras. Porém, ele não é dimensionado para gravações porque elas são síncronas com todos os servidores do cluster. Para um cluster de 2 nós, as gravações são mais rápidas que o seu banco de dados, mas não tão rápidas quanto o cache de réplica de partição. Para 3 ou mais clusters de servidores, o desempenho de gravação diminui e eventualmente se torna pouco atraente.

Abaixo estão algumas das características do Cache Replicado.

• - Nós replicados dinâmicos: você pode adicionar ou remover servidores de cache em tempo de execução para um cache existente sem interromper o cache ou seu aplicativo. O servidor recém-adicionado faz uma cópia (réplica) de todo o cache para si mesmo. E o servidor removido atualiza a associação ao cluster e todos os seus clientes são movidos para outros servidores.
• - Cache inteiro em cada nó: todo o cache é copiado para todos os servidores do cluster.
• - As leituras são escaláveis: as leituras são super rápidas e escaláveis ​​quando você adiciona mais servidores. No entanto, adicionar mais servidores não aumenta o tamanho do cache, pois o servidor recém-adicionado é apenas mais uma cópia de todo o cache.
• - As gravações são síncronas: as gravações são muito rápidas para um cluster de 2 nós e mais rápidas que o seu banco de dados. Porém, as gravações são síncronas, o que significa que cada operação de gravação não é concluída até que todos os servidores de cache sejam atualizados de forma síncrona. Devido a isso, as gravações não são tão rápidas quanto outras topologias e seu desempenho diminui quando você aumenta o tamanho do cluster além de 2 nós.
• - O cliente se conecta apenas a um servidor: cada cliente de cache se conecta apenas a um servidor no cluster com base em um algoritmo de balanceamento de carga determinado pelos servidores de cache. Se este servidor de cache ficar inativo, o cliente se conectará ao próximo servidor da lista. Você também pode especificar manualmente o servidor ao qual se conectar no arquivo de configuração de cache se não quiser usar o balanceamento de carga.

Cache espelhado

Cache Espelhado é um cluster de cache ativo/passivo de 2 nós destinado a ambientes menores. Ele fornece confiabilidade de dados por meio de replicação/espelhamento assíncrono do nó ativo para o nó passivo. É muito rápido para leituras e gravações (na verdade, as gravações são mais rápidas que o Cache Replicado), mas não escala além deste cluster ativo/passivo de 2 nós.

Abaixo estão algumas das características do Cache Espelhado.

• - 1 servidor ativo e 1 servidor passivo: O cache espelhado possui apenas dois servidores. Um é Ativo e o outro é Passivo. Ambos têm uma cópia de todo o cache. Se o Servidor Ativo ficar inativo, o Servidor Passivo se tornará automaticamente Ativo. E, se o servidor ativo anteriormente desativado voltar a funcionar, ele será tratado como um servidor passivo, a menos que você altere essa designação por meio de ferramentas administrativas em tempo de execução.
• - Conexões de clientes com suporte a failover: cada cliente de cache se conecta apenas ao Active Server no cluster para realizar suas operações de leitura e gravação. Se este Servidor Ativo falhar, todos os clientes se conectarão automaticamente ao Servidor Passivo que já se tornou Ativo. Esse suporte de failover garante que o Mirrored Cache esteja sempre ativo e funcionando, mesmo se um servidor ficar inativo.
• - Espelhamento Assíncrono: quaisquer gravações feitas no Servidor Ativo são espelhadas/replicadas de forma assíncrona para o Servidor Passivo. Isso garante que o Servidor Passivo esteja sempre sincronizado com os dados mais recentes, caso o Servidor Ativo fique inativo e o Servidor Passivo precise se tornar Ativo. O espelhamento assíncrono também significa desempenho mais rápido porque múltiplas gravações são executadas como uma operação BULK no Servidor Passivo.

Cache do cliente (velocidade InProc)

O Client Cache é local para seu servidor web/app e fica muito próximo ao seu aplicativo e permite armazenar em cache os dados que você está lendo do cache distribuído (qualquer topologia de cache). Você pode ver isso como um "cache em cima de um cache" e melhora ainda mais o desempenho e a escalabilidade do seu aplicativo. Se você usar o Client Cache no modo InProc, poderá obter a velocidade InProc.

Embora seja local para seu aplicativo, um Cache de Cliente não é autônomo. Em vez disso, ele é sempre sincronizado com o cache clusterizado. Isso garante que os dados no cache do cliente nunca fiquem obsoletos.

Abaixo estão algumas das características do Cache Espelhado.

• - Bom para casos de leitura intensiva: o cache do cliente só é bom se você tiver um caso de uso com uso intensivo de leitura, em que o número de leituras é muitas vezes maior que o de gravações. Se o número de gravações for igual ao de leituras, o cache do cliente será realmente mais lento porque uma gravação envolve atualizá-lo em dois locais.
• - Velocidade mais rápida como um cache local (InProc/OutProc): um cache de cliente existe dentro do processo do seu aplicativo (modo InProc) ou localmente no seu servidor web/aplicativo (modo OutProc). Em ambos os casos, isso aumenta significativamente o desempenho do seu aplicativo em comparação com apenas a obtenção desses dados do cache clusterizado. O modo InProc permite armazenar objetos em cache em seu “heap de aplicativo”, o que fornece “velocidade InProc” que não pode ser igualada por nenhum cache distribuído.
• - Não é um cache independente: O cache do cliente pode ser um cache local, mas não é um cache independente. Em vez disso, ele se mantém sincronizado com o cache clusterizado. O que isso significa é que se outro cliente atualizar dados no cache clusterizado que você possui em seu Cache do Cliente, o cache clusterizado notificará o Cache do Cliente para se atualizar com a cópia mais recente desses dados. E isso é feito de forma assíncrona, mas imediatamente.
• - Sincronização Otimista/Pessimista: Por padrão, o Cache do Cliente usa Sincronização Otimista, o que significa que NCache client assume que quaisquer dados que o Client Cache tenha são a cópia mais recente. Se o Cache do Cliente não tiver dados, o Cliente os buscará no Cache Clusterizado, os colocará no Cache do Cliente e os retornará ao aplicativo cliente. Sincronização Pessimista significa que o Cliente de Cache primeiro verifica se o Cache Clusterizado possui uma versão mais recente de um item armazenado em cache. Se isso acontecer, o cliente o buscará, o colocará no Cache do Cliente e o retornará ao aplicativo cliente. Caso contrário, ele retorna o que estiver no Client Cache.
• - Plug-in sem qualquer alteração de código: a melhor coisa sobre o Client Cache é que ele não envolve nenhuma alteração de código em seu aplicativo. Em vez disso, basta conectá-lo por meio de uma alteração na configuração. E, NCache A API do cliente nos bastidores sabe o que fazer sobre o uso do Cache do Cliente.

O que fazer a seguir?

• NCache Adicionar ao carrinho
• Baixar NCache
• Comparação de edições