Compartilhar via

Escale uma instância de Cache do Azure para Redis

  • Artigo

O Cache do Azure para Redis tem diferentes ofertas de camada de serviço que fornecem flexibilidade na escolha do tamanho e dos recursos de cache. Por meio da escala, você pode alterar o tamanho, a camada de serviço e o número de nós depois de criar uma instância de cache para atender às necessidades do aplicativo. Este artigo mostra como escalar seu cache no portal do Azure, além de ferramentas como o Azure PowerShell e a CLI do Azure.

Tipos de dimensionamento

Basicamente, existem duas maneiras de escalar uma Instância de Cache do Azure para Redis:

  • Escalar verticalmente aumenta o tamanho da VM (Máquina Virtual) que executa o servidor Redis, adicionando mais memória, CPUs virtuais (vCPUs) e largura de banda de rede. A escala vertical também é chamada de dimensionamento vertical. O oposto de escalar verticalmente é Reduzir verticalmente.

  • Reduzir verticalmente divide a instância de cache em mais nós do mesmo tamanho, aumentando a memória, as vCPUs e a largura de banda de rede por meio da paralelização. A redução vertical também é conhecida como escala horizontal ou fragmentação. O oposto de reduzir verticalmente é Reduzir horizontalmente. Na comunidade Redis, a redução vertical é frequentemente chamada de clustering.

Escopo de disponibilidade

Camada Básico e Standard Premium Enterprise e Enterprise Flash
Expansão Sim Yes Sim (versão prévia)
Reduzir verticalmente Sim Sim Não
Escalonamento horizontal Não Yes Sim (versão prévia)
Reduzir horizontalmente Não Sim Não

Quando dimensionar

Você pode usar os recursos de monitoramento do Cache Redis do Azure para monitorar a integridade e o desempenho do seu cache. Use essas informações para determinar quando escalonar o cache.

Você pode monitorar as métricas a seguir para determinar se é preciso escalonar.

  • Carga do Servidor Redis
    • Alta carga do servidor Redis significa que o servidor não consegue manter o ritmo das solicitações de todos os cliente. Como um servidor Redis é um processo encadeamento único, normalmente é mais útil escalar horizontalmente em vez de escalar verticalmente. Escalar horizontalmente permitindo o clustering ajuda a distribuir funções de sobrecarga em vários processos do Redis. O escala horizontal também ajuda a distribuir criptografia/descriptografia e conexão/desconexão TLS, acelerando as instâncias de cache usando TLS.
    • A escala vertical ainda pode ser útil para reduzir a carga do servidor porque as tarefas em segundo plano podem aproveitar mais vCPUs e liberar o thread para o processo principal do servidor Redis.
    • As camadas de serviço Enterprise e Enterprise Flash usam o Redis Enterprise em vez do Redis em código aberto. Uma das vantagens dessas camadas é que o processo do servidor Redis pode tirar proveito de várias vCPUs. Com várias vCPUs, escalar verticalmente e escalar horizontalmente nessas camadas pode ser útil para reduzir a carga do servidor. Para mais informações, confira Práticas recomendadas para as camadas de serviço Enterprise e Enterprise Flash do Cache do Azure para Redis.
  • Uso de Memória
    • O uso de memória alta indica que o tamanho dos dados é muito grande para o tamanho do cache atual. Considere a possibilidade de dimensionar para um tamanho de cache com memória maior. Escalar verticalmente ou escalar horizontalmente é eficaz aqui.
  • Conexões de cliente
    • Cada tamanho de cache tem um limite para o número de conexões de cliente às quais ele pode dar suporte. Se as conexões do cliente estiverem próximas do limite do tamanho do cache, considere escalar verticalmente para uma camada maior. Escalar horizontalmente não aumenta o número de conexões de cliente com suporte.
    • Para obter mais informações sobre os limites de conexão por tamanho do cache, confira Preço do Cache do Azure para Redis.
  • Largura de Banda de Rede
    • Se o servidor Redis exceder a largura de banda disponível, as solicitações de clientes poderão atingir o tempo limite porque o servidor não pode enviar dados por push para o cliente de forma rápida o suficiente. Para ver a quantidade de largura de banda do lado do servidor que está sendo usada, verifique as métricas "Leitura de Cache" e "Gravação de Cache". Se o servidor Redis estiver excedendo a largura de banda da rede disponível, considere a possibilidade de escalar horizontalmente ou verticalmente para um tamanho de cache maior com maior largura de banda de rede.
    • Para caches da camada de serviço Enterprise que usam a Política de cluster Enterprise, a escala horizontal não aumenta a largura de banda da rede.
    • Para obter mais informações sobre largura de banda disponível por tamanho do cache, confira Perguntas frequentes sobre o planejamento do Cache do Azure para Redis.
  • Verificações Internas do Defender
    • Nos caches C0 e C1, você pode ver picos curtos na carga do servidor não causados por um aumento nas solicitações algumas vezes por dia enquanto a verificação de vírus está em execução nas VMs. Você vê uma latência maior para solicitações enquanto as verificações internas do Defender são executadas nessas camadas algumas vezes por dia. Os caches nas camadas C0 e C1 têm apenas um núcleo para multitarefa, dividindo o trabalho de serviço de verificação de vírus e solicitações Redis. Você pode reduzir o efeito escalando para uma oferta de camada superior com vários núcleos de CPU, como C2.
    • O aumento do tamanho do cache nas camadas mais altas ajuda a resolver quaisquer preocupações de latência. Além disso, no nível de C2, você tem suporte para até 2.000 conexões de cliente.

Para obter mais informações sobre como determinar qual camada de preço de cache usar, confira Escolhendo o nível correto e Perguntas frequentes sobre o planejamento do Cache do Azure para Redis.

Observação

Para obter mais informações sobre como otimizar o processo de escalonamento, confira o guia de práticas recomendadas para colocação em escala

Pré-requisitos/limitações de escalonamento do Cache do Azure para Redis

Você pode escalar verticalmente/horizontalmente para um tipo de preço diferente com as restrições a seguir:

  • Você não pode dimensionar de uma camada de preços mais alta para uma camada de preços mais baixa.
    • Não é possível escalonar de um cache Enterprise ou Enterprise Flash para qualquer outra camada de serviço.
    • Você não pode dimensionar de um cache Premium para um cache Standard ou Básico.
    • Você não pode dimensionar de um cache Standard para um cache Básico.
  • É possível dimensionar de um cache Básico para um cache Standard, mas não é possível alterar o tamanho simultaneamente. Para um tamanho diferente, realize posteriormente uma operação de dimensionamento para o tamanho desejado.
  • Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione do Básico para o Standard em uma única operação de dimensionamento e do Standard para o Premium em uma operação de dimensionamento subsequente.
  • Não é possível escalar de um tamanho maior para o tamanho C0 (250 MB). No entanto, você pode fazer a redução horizontal para qualquer outro tamanho dentro do mesmo nível de preço. Por exemplo, você pode fazer a redução horizontal do C5 Standard para o C1 Standard.
  • Não é possível escalonar de um cache Premium, Standard ou Basic para um cache Enterprise ou Enterprise Flash.
  • Não é possível escalonar entre Enterprise e Enterprise Flash.

Você pode escalar horizontalmente/verticalmente com as seguintes restrições:

  • A escala horizontal só tem suporte nas camadas Premium, Enterprise e Enterprise Flash.
  • A redução horizontal só tem suporte na camada Premium.
  • Na camada Premium, o clustering deve ser habilitado primeiro, antes de escalar ou reduzir horizontalmente.
  • No nível Premium, há suporte em disponibilidade geral para escalar verticalmente até 10 fragmentos. O suporte para até 30 fragmentos está em versão prévia. (Para caches com duas réplicas, o limite de fragmentos é 20. Com três réplicas, o limite de fragmentos é 15.)
  • Somente as camadas de serviço Enterprise e Enterprise Flash podem escalar verticalmente e horizontalmente simultaneamente.

Como escalar – camadas de serviço Basic, Standard e Premium

Escalar e reduzir verticalmente usando o portal do Azure

  1. Para escalonar seu cache, navegue até ele no portal do Azure e selecione Escalar no menu Recurso.

    Captura de tela mostrando Escalar no menu d de recursos.

  2. Selecione um tipo de preço no painel de trabalho e escolha Selecionar.

    Captura de tela mostrando as camadas de serviço do Cache do Azure para Redis.

  3. Enquanto o cache escala para a nova camada, uma notificação Escalando o Cache Redis é exibida.

    Captura de tela mostrando a notificação de colocação em escala.

  4. Quando o dimensionamento for concluído, o status será alterado de Dimensionando para Executando.

Observação

Quando você escalar ou reduzir verticalmente um cache no portal, as configurações maxmemory-reserved e maxfragmentationmemory-reserved são reduzidas horizontalmente em proporção ao tamanho do cache. Por exemplo, maxmemory-reserved se for definido como 3 GB em um cache de 6 GB e você dimensionar para um cache de 12 GB, as configurações serão atualizadas automaticamente para 6 GB durante o dimensionamento. Quando você reduz verticalmente, o inverso acontece.

Escalar e reduzir verticalmente usando o PowerShell

É possível escalar as instâncias do Cache Redis do Azure com o PowerShell usando o cmdlet Set-AzRedisCache quando as propriedades Size ou Sku forem modificadas. O exemplo a seguir mostra como escalar um cache denominado myCache para um cache de 6 GB na mesma camada de serviço.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Para saber mais sobre o dimensionamento com o PowerShell, consulte Para dimensionar um Cache Redis do Azure usando PowerShell.

Escalar e reduzir verticalmente usando a CLI do Azure

Para escalar suas instâncias do Cache do Azure para Redis usando a CLI do Azure, chame o comando az redis update. Use a propriedade sku.capcity para escalar dentro de uma camada, por exemplo, de um cache Standard C0 para Standard C1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Use as propriedades "sku.name" e "sku.family" para escalar verticalmente para uma camada diferente, por exemplo, de um cache Standard C1 para um cache Premium P1:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Para saber mais sobre o dimensionamento com o CLI do Azure, consulte Alterar as configurações de um Cache Redis do Azure existente.

Observação

Quando você escala ou reduz verticalmente um cache de forma programada (por exemplo, usando o PowerShell ou a CLI do Azure), qualquer maxmemory-reserved ou maxfragmentationmemory-reserved é ignorado como parte da solicitação de atualização. Somente a alteração de escala é respeitada. Essas configurações de memória podem ser atualizadas após a conclusão da operação de colocação em escala.

Como escalar verticalmente e horizontalmente – camadas de serviço Enterprise e Enterprise Flash

As camadas de serviço Enterprise e Enterprise Flash são capazes de escalar verticalmente e horizontalmente em uma operação. Outras camadas de serviço exigem operações separadas para cada ação.

Cuidado

As camadas Enterprise e Enterprise Flash ainda não dão suporte a operações de redução vertical ou redução horizontal.

Escalar usando o portal do Azure

  1. Para escalonar seu cache, navegue até ele no portal do Azure e selecione Escalar no menu Recurso.

    Captura de tela mostrando a opção Escalar selecionada no menu Recurso de um cache Enterprise.

  2. Para escalar verticalmente, escolha um Tipo de cache diferente e escolha Salvar.

    Importante

    No momento, você só pode escalar verticalmente. Não é possível reduzir verticalmente.

    Captura de tela mostrando as camadas de serviço Enterprise no painel de trabalho.

  3. Para escalar horizontalmente, aumente o controle deslizante Capacidade. A capacidade aumenta em incrementos de dois. Esse número reflete quantos nós subjacentes do Redis Enterprise estão sendo adicionados. Esse número é sempre um múltiplo de dois para refletir os nós que estão sendo adicionados para fragmentos primários e de réplica.

    Importante

    Neste momento, você só pode escalar horizontalmente, aumentando a capacidade. Você não pode reduzir horizontalmente.

    Captura de tela mostrando a Capacidade no painel de trabalho uma caixa vermelha ao redor.

  4. Enquanto o cache escala para a nova camada, uma notificação Escalando o Cache Redis é exibida.

    Captura de tela mostrando a notificação de colocação em escala de um cache Enterprise.

  5. Quando o dimensionamento for concluído, o status será alterado de Dimensionando para Executando.

Dimensionar usando o PowerShell

É possível escalar as instâncias do Cache Redis do Azure com o PowerShell usando o cmdlet Set-AzRedisEnterpriseCache. Você pode modificar a propriedade Sku para escalar verticalmente a instância. Você pode modificar a propriedade Capacity para escalar horizontalmente a instância. O exemplo a seguir mostra como escalar um cache chamado myCache para uma instância do Enterprise E20 (25 GB) com capacidade de 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Dimensionar usando a CLI do Azure

Para escalar suas instâncias do Cache do Azure para Redis usando a CLI do Azure, chame o comando az redisenterprise update. Você pode modificar a propriedade sku para escalar verticalmente a instância. Você pode modificar a propriedade capacity para escalar horizontalmente a instância. O exemplo a seguir mostra como escalar um cache chamado myCache para uma instância do Enterprise E20 (25 GB) com capacidade de 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Perguntas frequentes sobre dimensionamento

A lista a seguir contém respostas para perguntas frequentes sobre o dimensionamento do Cache Redis do Azure.

Posso escalonar para um cache Premium, por meio dele ou nele?

  • Você não pode dimensionar de um cache Premium para um tipo de preço Básico ou Standard.
  • Você pode dimensionar de um tipo de preço de cache Premium para outro.
  • Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione do Básico para o Standard em uma única operação de dimensionamento e do Standard para o Premium em uma operação de dimensionamento subsequente.
  • Você não pode escalar de um cache Premium para um cache Enterprise ou Enterprise Flash.
  • Se você habilitou o clustering quando criou o cache Premium, será possível alterar o tamanho do cluster. Se o cache foi criado sem clustering habilitado, é possível configurar o clustering em um momento posterior.

Depois do dimensionamento, é necessário alterar minhas chaves de acesso ou o nome do cache?

Não, o nome do cache e as chaves permanecem inalterados durante uma operação de dimensionamento.

Como funciona o dimensionamento?

  • Quando você dimensiona um cache Basic para um tamanho diferente, o cache é desligado e um novo cache é provisionado usando o novo tamanho. Durante esse tempo, o cache não está disponível e todos os dados em cache são perdidos.
  • Quando você dimensiona um cache Básico para um cache Standard, um cache de réplica é provisionado e os dados são copiados do cache primário no cache de réplica. O cache permanece disponível durante o processo de dimensionamento.
  • Quando você escala um cache Standard, Premium, Enterprise ou Enterprise Flash para um tamanho diferente, uma das réplicas é desligada e provisionada novamente para o novo tamanho, os dados são transferidos e a outra réplica executa um failover antes de ser provisionada novamente, de forma semelhante ao processo que ocorre durante uma falha em um dos nós de cache.
  • Quando você escala horizontalmente um cache clusterizado, novos fragmentos são provisionados e adicionados ao cluster do servidor Redis. Os dados são então refragmentados em todos os fragmentos.
  • Quando você dimensiona em um cache clusterizado, os dados são refragmentados primeiro e o tamanho do cluster é reduzido para os fragmentos necessários.
  • Em alguns casos, como dimensionar ou migrar seu cache para um cluster diferente, o endereço IP subjacente do cache pode mudar. O registro DNS do cache muda e é transparente para a maioria dos aplicativos. No entanto, se você usar um endereço IP para configurar a conexão com seu cache ou para configurar NSGs ou firewalls que permitem o tráfego para o cache, seu aplicativo poderá ter problemas para se conectar algum tempo após a atualização do registro DNS.

Perco dados de meu cache durante a colocação em escala?

  • Quando você dimensiona um cache Básico para um novo tamanho, todos os dados são perdidos, e o cache fica indisponível durante a operação de colocação em escala.
  • Quando você dimensiona um cache Básico para um cache Standard, os dados no cache geralmente são preservados.
  • Quando você escala um cache Standard, Premium, Enterprise ou Enterprise Flash para um tamanho maior, geralmente, todos os dados são preservados. Quando você dimensiona um cache Standard ou Premium para um tamanho menor, os dados podem ser perdidos se o tamanho dos dados exceder o novo tamanho menor quando o cache for reduzido. Se dados forem perdidos ao se reduzir, as chaves serão removidas usando a política de remoção allkeys-lru .

Posso usar todos os recursos da camada Premium após a escala?

Não, alguns recursos só podem ser definidos quando você cria um cache na camada Premium e não estão disponíveis após o dimensionamento.

Esses recursos não podem ser adicionados depois que você cria o cache Premium:

  • Injeção da rede virtual
  • Adição da redundância de zona
  • Usando várias réplicas por primária

Para usar qualquer um desses recursos, você deve criar uma nova instância de cache na camada Premium.

A configuração dos meus bancos de dados personalizados foi afetada durante o dimensionamento?

Se você configurou um valor personalizado para a databases configuração durante a criação de cache, lembre-se que alguns tipos de preço têm limites de banco de dados diferentes. Algumas considerações ao dimensionar neste cenário:

  • Ao reduzir para um tipo de preço com um limite databases menor do que a camada atual:
    • Ao usar o número padrão de databases, que é 16 para todos os tipos de preços, nenhum dado será perdido.
    • Ao usar um número personalizado de databases, que se adequa aos limites do tipo para o qual você está dimensionando, essa configuração databases é mantida e nenhum dado é perdido.
    • Ao usar um número personalizado de databases, que excede os limites do novo tipo, a configuração databases é reduzida para os limites do novo tipo e todos os dados nos bancos de dados removidos são perdidos.
  • Ao reduzir para um tipo de preço com o mesmo limite ou com um limite superior do que o tipo atual para databases, sua configuração databases é mantida e nenhum dado é perdido.

Embora os caches Standard, Premium, Enterprise e Enterprise Flash tenham um SLA (Contrato de Nível de Serviço) para disponibilidade, não há SLA para perda de dados.

O cache estará disponível durante o dimensionamento?

  • Os caches Standard, Premium, Enterprise e Enterprise Flash permanecem disponíveis durante a operação de colocação em escala. No entanto, falhas de conexão podem ocorrer durante a colocação em escala desses caches e também durante a colocação em escala de caches Basic para Standard. Esses pontos de conexão devem ser pequenos e os clientes do Redis devem ser capazes de restabelecer a conexão imediatamente.
  • Para caches Enterprise e Enterprise Flash usando a replicação geográfica ativa, colocar em escala apenas um subconjunto de caches vinculados pode introduzir problemas ao longo do tempo em alguns casos. É recomendável colocar em escala todos os caches no grupo de replicação geográfica juntos, sempre que possível.
  • Os caches Basic ficam offline durante o dimensionamento de operações para um tamanho diferente. Os caches Básicos permanecem disponíveis ao dimensionar de Básico para Standard, mas poderão enfrentar um ponto de conexão pequeno. Se ocorrer um ponto de conexão, os clientes do Redis devem ser capazes de restabelecer a conexão imediatamente.

Há limitações de dimensionamento com a replicação geográfica?

Com a replicação geográfica passiva configurada, você pode observar que não é possível escalonar um cache ou alterar os fragmentos em um cluster. Um link de replicação geográfica entre dois caches impede que você dimensione a operação ou mude o número de fragmentos em um cluster. Desvincule o cache para executar esses comandos. Para obter mais informações, consulte Configurar Replicação geográfica.

Com a replicação geográfica ativa configurada, você não pode escalar um cache. Todos os caches em um grupo de replicação geográfica devem ter o mesmo tamanho e capacidade.

Operações sem suporte

  • Você não pode dimensionar de uma camada de preços mais alta para uma camada de preços mais baixa.
    • Você não pode dimensionar de um cache Premium para um cache Standard ou Básico.
    • Você não pode dimensionar de um cache Standard para um cache Básico.
  • É possível dimensionar de um cache Básico para um cache Standard, mas não é possível alterar o tamanho simultaneamente. Para um tamanho diferente, realize uma operação de dimensionamento subsequente para o tamanho desejado.
  • Você não pode dimensionar de um cache Básico diretamente para um cache Premium. Primeiro, dimensione de Básico para Standard em uma única operação de dimensionamento e de Standard para Premium em uma operação posterior.
  • Você não pode escalar de um cache Premium para um cache Enterprise ou Enterprise Flash.
  • Não é possível dimensionar de um tamanho maior para o tamanho C0 (250 MB) .

Se uma operação de dimensionamento falhar, o serviço tentará reverter a operação e o cache será revertido para o tamanho original.

Quanto tempo o dimensionamento leva?

O tempo de dimensionamento depende de alguns fatores. Aqui estão alguns fatores que podem afetar quanto tempo o dimensionamento leva.

  • Quantidade de dados: quantidades maiores de dados levam mais tempo para serem replicadas
  • Solicitações de gravação alta: maior número de gravações significa mais replicações de dados entre nós ou fragmentos
  • Alta carga do servidor: carga de servidor mais alta significa que o servidor Redis está ocupado e ciclos de CPU limitados estão disponíveis para concluir a redistribuição de dados

Em geral, dimensionar um cache sem dados leva cerca de 20 minutos. Para caches clusterizados, o dimensionamento leva cerca de 20 minutos por fragmento com dados mínimos.

Como saber quando o dimensionamento é concluído?

No portal do Azure, você pode ver a operação de dimensionamento em andamento. Quando o dimensionamento for concluído, o status do cache será alterado para Executando.

Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?

Importante

Ao usar as camadas de serviço Enterprise ou Enterprise Flash, você tem a opção de escolher entre o Modo de Cluster de Software de Código Aberto ou o Modo de Cluster Empresarial. O Modo de Cluster de Software de Código Aberto é o mesmo que o clustering na camada Premium e segue a especificação de clustering de código aberto. O Modo de Cluster Empresarial pode ter um desempenho menor, mas usa o clustering do Redis Enterprise, que não requer nenhuma alteração do cliente para ser usado. Para obter mais informações, confira o Clustering no Enterprise.

Como as chaves são distribuídas em um cluster?

De acordo com a documentação do Redis sobre o modelo de distribuição de chaves: o espaço da chave é dividido em 16.384 slots. Cada chave é resumida e atribuída a um desses slots, que são distribuídos entre os nós do cluster. Você pode configurar qual parte da chave é resumida para garantir que várias chaves estejam localizadas no mesmo fragmento usando hashtags.

  • Chaves com marca hash – se alguma parte da chave estiver entre { e }, somente essa parte da chave terá hash, a fim de determinar o slot de hash de uma chave. Por exemplo, as três chaves a seguir devem estar localizadas no mesmo fragmento: {key}1, {key}2 e {key}3, uma vez que apenas a parte key do nome está entre chaves. Para obter uma lista completa das especificações da marca hash de chaves, confira Keys hash tags.
  • Chaves sem uma marca de hash: todo o nome da chave é usado para hash, resultando em uma distribuição estatisticamente uniforme entre os fragmentos do cache.

Para obter um melhor desempenho e uma melhor taxa de transferência, recomendamos distribuir as chaves por igual. Se você estiver usando chaves com uma hashtag, é responsabilidade do aplicativo garantir que as chaves sejam distribuídas uniformemente.

Para saber mais, confira Keys distribution model, Redis Cluster data sharding e Keys hash tags.

Para obter um código de exemplo sobre como trabalhar com clustering e localizar chaves no mesmo fragmento com o cliente StackExchange.Redis, confira a parte clustering.cs da amostra Olá, Mundo.

Qual é o maior tamanho de cache que eu posso criar?

O maior tamanho de cache que você pode ter é de 4,5 TB. Isso resulta em um cache F1500 clusterizado com capacidade 9. Para obter mais informações, consulte Preço do Cache do Azure para Redis.

Todos os clientes do Redis dão suporte ao clustering?

Muitas bibliotecas de clientes dão suporte ao clustering do Redis, mas nem todas. Verifique a documentação da biblioteca que você está usando para verificar se a biblioteca e a versão usadas aceitam clustering. StackExchange.Redis é uma biblioteca que aceita as versões mais recentes do clustering. Para obter mais informações sobre outros clientes, confira a seção Playing with the cluster do Redis cluster tutorial.

O protocolo de clustering Redis requer que cada cliente se conecte a cada fragmento diretamente no modo de clustering e também define novas respostas de erro, como MOVED na CROSSSLOTS. Quando você tenta usar uma biblioteca de clientes que não dá suporte ao clustering com um cache de modo de cluster, isso pode resultar em um número excessivo de exceções de redirecionamento MOVED ou apenas interromper o aplicativo, caso você esteja fazendo solicitações de várias chaves entre slots.

Observação

Se você estiver usando o StackExchange.Redis como seu cliente, verifique se está usando a versão mais recente do StackExchange.Redis 1.0.481 ou posterior para que o clustering funcione corretamente. Para mais informações sobre problemas com as exceções move, confira exceções move.

Como posso me conectar ao meu cache quando o clustering estiver habilitado?

Você pode se conectar ao seu cache usando os mesmos pontos de extremidade, portas e chaves usados ao conectar-se a um cache que não tem o clustering habilitado. O Redis gerencia o clustering no back-end para que você não precise gerenciá-lo por meio de seu cliente.

Posso me conectar diretamente aos fragmentos individuais do meu cache?

O protocolo de clustering exige que o cliente faça as conexões de fragmento corretas, portanto, o cliente deve fazer conexões de compartilhamento para você. Dito isso, cada fragmento consiste em um par de cache primário/de réplica que é conhecido coletivamente como uma instância de cache. Você pode se conectar a essas instâncias de cache usando o utilitário Redis-CLI no branch instável do repositório do Redis no GitHub. Esta versão implementa o suporte básico quando iniciado com o switch -c . Para obter mais informações, consulte Experimentar com o cluster em https://redis.io no Tutorial do cluster do Redis.

Você precisa usar a opção -p para especificar a porta correta à qual se conectar. Use o comando CLUSTER NODES para determinar as portas exatas usadas para os nós primário e de réplica. Os seguintes intervalos de portas são usados:

  • Para caches da camada de serviço Premium não habilitados para TLS, as portas estão disponíveis no intervalo 130XX
  • Para caches da camada de serviço Premium habilitados para TLS, as portas estão disponíveis no intervalo 150XX
  • Para caches Enterprise e Enterprise Flash usando clustering de software de código aberto, a conexão inicial é por meio da porta 10000. A conexão com nós individuais pode ser feita usando portas no intervalo 85XX. As portas 85xx serão alteradas ao longo do tempo e não devem ser codificadas no seu aplicativo.

Posso configurar o clustering para um cache criado anteriormente?

Sim. Primeiro, certifique-se de que o cache está na camada Premium escalando-o verticalmente. Em seguida, você vê as opções de configuração de cluster, incluindo uma opção para habilitar o cluster. Altere o tamanho do cluster após a criação do cache ou depois que você habilitar o clustering pela primeira vez.

Importante

Não é possível desfazer a habilitação do clustering. Um cache com clustering habilitado e apenas um fragmento se comporta de maneira diferente de um cache do mesmo tamanho sem clustering.

Todos os caches das camadas de serviço Enterprise e Enterprise Flash são sempre clusterizados.

Posso configurar o clustering para um cache básico ou standard?

O clustering só está disponível para caches Premium, Enterprise e Enterprise Flash.

Posso usar clustering com os provedores de Estado de Sessão ASP.NET Redis e Caching de Saída?

  • Provedor de Cache de Saída Redis : sem necessidade de alterações.
  • Provedor de Estado de Sessão Redis: para usar o clustering, você deve usar RedisSessionStateProvider 2.0.1 ou superior; do contrário, uma exceção será lançada, que é uma alteração interruptiva. Para saber mais, confira Detalhes da alteração interruptiva v2.0.0.

Estou recebendo exceções MOVE ao usar StackExchange.Redis e clustering. O que devo fazer?

Se você estiver usando StackExchange.Redis e receber exceções MOVE ao usar clustering, verifique se está usando StackExchange.Redis 1.1.603 ou posterior. Para obter instruções sobre como configurar seus aplicativos .NET para usar StackExchange.Redis, confira Configurar os clientes de cache.

Qual é a diferença entre clustering de software de código aberto e clustering empresarial em caches da camada de serviço Enterprise?

O Modo de Cluster de Software de Código Aberto é o mesmo que o clustering na camada Premium e segue a especificação de clustering de código aberto. O Modo de Cluster Empresarial pode ter um desempenho menor, mas usa o clustering do Redis Enterprise, que não requer nenhuma alteração do cliente para ser usado. Para obter mais informações, confira o Clustering no Enterprise.

Quantos fragmentos os caches da camada de serviço Enterprise usam?

Ao contrário dos caches de camadas Basic, Standard e Premium, os caches Enterprise e Enterprise Flash podem aproveitar vários fragmentos em um único nó. Para obter mais informações, confira Fragmentação e utilização da CPU.

Próximas etapas