Topologias de cache para 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.

Abaixo estão as principais topologias de cache que NCache fornece:

1. Cache Particionado
2. Cache de réplica de partição
3. Cache replicado
4. Cache espelhado (2-nós ativo/passivo)
5. Cache de cliente (Velocidade InProc; Cache Local conectado ao Cache Clusterizado)

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ê.

O armazenamento em cache de um catálogo de produtos onde os preços não mudam com muita frequência é um dado de referência. Por outro lado, ASP.NET Core O armazenamento de sessões é considerado um uso transacional porque uma sessão é lida e atualizada uma vez a cada solicitação da Web, o que pode ocorrer a cada poucos segundos.

No início, um cache era considerado bom principalmente para dados de referência porque os dados que mudavam com frequência se tornavam obsoletos e fora de sincronia com os dados mais recentes no banco de dados. Mas, 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 fará para descobrir qual topologia é melhor para você. Além disso, algumas topologias de cache não são dimensionadas tanto 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.

1. 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.
2. Cache de réplica de partição (Mais popular): muito bom. Super rápido para leituras e gravações e também dimensiona linearmente adicionando servidores. Segunda topologia mais rápida, mas replica dados para confiabilidade sem comprometer a escalabilidade linear. Melhor combinação de velocidade/escalabilidade e confiabilidade de dados.
3. Cache replicado: Muito bom para ambientes menores. Super rápido e linearmente escalá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.
4. Cache espelhado: Muito bom para ambientes menores. Super rápido para leituras. As gravações são mais rápidas do que o cache replicado para ativo/passivo de 2 nós. Mas, não escala além disso.
5. Cache de cliente: Muito bom para uso intensivo de leitura com todas as topologias de cache. Permite atingir a velocidade do InProc com 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.

1. Partições dinâmicas: 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 para todas as partições. Adicionar/remover o servidor de cache resulta na criação/exclusão de partições em tempo de execução. A atribuição de buckets a partições não muda quando os dados estão sendo adicionados ao cache. Em vez disso, ele só muda quando as partições são adicionadas ou excluídas ou quando ocorre o balanceamento de dados (veja abaixo).
2. 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 as partições são adicionadas ou excluídas ou quando ocorre o 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.
3. 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 de hash nas chaves, há uma chance de que alguns buckets possam ter mais dados do que outros, dependendo de quais chaves foram usadas. Se esse desequilíbrio cruzou um limite configurável, NCache automaticamente desloca os baldes para equilibrar essa carga.
4. 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 para ler ou gravar um item em cache que existe no servidor ao qual 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.

1. Partições dinâmicas: mesma Cache Particionado.
2. 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.
3. 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 são enfileiradas. E, então, são replicados em BULK na réplica. Isso melhora o desempenho, mas apresenta um pequeno risco de perda de dados caso uma Partição vá e nem todas as atualizações tenham sido replicadas para a Réplica. Mas, na maioria das situações, isso está perfeitamente bem.
4. Replicação de sincronização: se seus dados forem muito sensíveis (por exemplo, dados financeiros) e você não puder ter dados obsoletos, então você pode escolher a opção “Sync Replication” 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, ela 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) sempre serão consistentes. No entanto, isso tem implicações no desempenho, pois é mais lento que a Replicação Assíncrona.
5. Mapa de Distribuição: mesma Cache Particionado.
6. Balanceamento dinâmico de dados (partições e réplicas): mesma Cache Particionado. No entanto, no Cache de Réplica de Partição, o balanceamento de dados também ocorre nas Réplicas quando as partições são balanceadas com dados.
7. Clientes se conectam a TODAS as partições: mesma Cache Particionado. Além disso, no Cache de Réplica de Partição, os clientes falam apenas com partições e não com suas réplicas. Isso ocorre porque as réplicas são passivas e apenas as partições conversam 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. Mas não é dimensionado para gravações porque elas são síncronas com todos os servidores no cluster. Para um cluster de 2 nós, as gravações são mais rápidas que seu banco de dados, mas não tão rápidas quanto Cache de réplica de partição. Para 3 ou mais clusters de servidor, o desempenho das gravações diminui e, eventualmente, torna-se pouco atraente.

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

1. 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. Além disso, o servidor removido atualiza a associação do cluster e todos os seus clientes são movidos para outros servidores.
2. Cache inteiro em cada nó: todo o cache é copiado para cada servidor no cluster.
3. 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 outra cópia do cache inteiro.
4. As gravações são síncronasus: as gravações são muito rápidas para um cluster de 2 nós e mais rápidas que seu banco de dados. Mas 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.
5. Cliente se conecta a um servidor apenas: 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 do que Cache replicado), mas não é dimensionado além desse cluster ativo/passivo de 2 nós.

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

1. 1 servidor ativo e 1 passivo: O Cache Espelhado tem 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á Ativo automaticamente. E, se o Active Server anteriormente inativo 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.
2. Conexões de clientes com suporte a failover: cada cliente de cache só se conecta ao Active Server no cluster para fazer suas operações de leitura e gravação. Se este Servidor Ativo ficar inativo, todos os clientes se conectarão automaticamente ao Servidor Passivo que já se tornou Ativo. Esse suporte a failover garante que o Cache Espelhado esteja sempre ativo e em execução, mesmo que um servidor fique inativo.
3. Espelhamento assíncrono: todas as gravações feitas no Active Server são espelhadas/replicadas de forma assíncrona para o Passive Server. Isso garante que o Servidor Passivo esteja sempre sincronizado com os dados mais recentes, caso o Servidor Ativo fique inativo e o Servidor Passivo tenha que se tornar Ativo. O espelhamento assíncrono também significa desempenho mais rápido porque várias 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.

1. Bom para casos de leitura intensiva: O Cache do Cliente é bom apenas se você tiver um caso de uso de leitura intensiva em que o número de leituras é muitas vezes maior que o de gravações. Se o número de gravações for o mesmo que o de leituras, o cache do cliente será realmente mais lento porque uma gravação envolve atualizá-lo em dois locais.
2. Velocidade mais rápida como um cache local (InProc / OutProc): um Client Cache existe dentro do seu processo de aplicação (modo InProc) ou local para o seu servidor web/app (modo OutProc). Em ambos os casos, ele aumenta significativamente o desempenho do seu aplicativo em comparação com apenas buscar esses 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 correspondido por nenhum cache distribuído.
3. Não é um cache autônomo: O Cache do Cliente pode ser um Cache Local, mas não é um cache autônomo. 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 de Cliente, o cache clusterizado notificará o Cache de Cliente para atualizar-se com a cópia mais recente desses dados. E isso é feito de forma assíncrona, mas imediatamente.
4. 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.
5. Plug-in sem qualquer alteração de código: o melhor do 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 de 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