Dimensionar uma instância da Cache do Azure para Redis
O Cache Redis do Azure tem diferentes ofertas de camada que fornecem flexibilidade na escolha do tamanho e dos recursos do cache. Por meio do dimensionamento, você pode alterar o tamanho, a camada e o número de nós depois de criar uma instância de cache para corresponder às necessidades do seu aplicativo. Este artigo mostra como dimensionar seu cache usando o portal do Azure, além de ferramentas como o Azure PowerShell e a CLI do Azure.
Tipos de dimensionamento
Há fundamentalmente duas maneiras de dimensionar um Cache do Azure para Instância Redis:
A expansão aumenta o tamanho da máquina virtual (VM) que executa o servidor Redis, adicionando mais memória, CPUs virtuais (vCPUs) e largura de banda de rede. A expansão também é chamada de escala vertical. O oposto de aumentar é reduzir a escala.
O dimensionamento divide a instância de cache em mais nós do mesmo tamanho, aumentando a memória, as vCPUs e a largura de banda da rede por meio da paralelização. A expansão também é conhecida como dimensionamento horizontal ou fragmentação. O oposto de escalar é escalar em. Na comunidade Redis, o dimensionamento é frequentemente chamado de clustering.
Âmbito da disponibilidade
| Escalão de serviço | Básico e Standard | Premium | Flash Enterprise e Enterprise |
|---|---|---|---|
| Aumentar Verticalmente | Sim | Sim | Sim |
| Reduzir Verticalmente | Sim | Sim | No |
| Aumentar Horizontalmente | Não | Sim | Sim |
| Escala em | Não | Sim | No |
Quando dimensionar
Você pode usar os recursos de monitoramento do Cache Redis do Azure para monitorar a integridade e o desempenho do cache. Use essas informações para determinar quando dimensionar o cache.
Você pode monitorar as métricas a seguir para determinar se precisa dimensionar.
- Carga do servidor Redis
- Alta carga do servidor Redis significa que o servidor é incapaz de acompanhar o ritmo das solicitações de todos os clientes. Como um servidor Redis é um processo de thread único, normalmente é mais útil expandir em vez de aumentar a escala. A expansão habilitando o clustering ajuda a distribuir funções de sobrecarga em vários processos Redis. A expansão também ajuda a distribuir criptografia/descriptografia TLS e conexão/desconexão, acelerando instâncias de cache usando TLS.
- A expansão 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 Enterprise e Enterprise Flash usam Redis Enterprise em vez de Redis de 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, tanto o dimensionamento quanto o dimensionamento nessas camadas podem ser úteis para reduzir a carga do servidor. Para obter mais informações, consulte Práticas recomendadas para as camadas Enterprise e Enterprise Flash do Cache do Azure para Redis.
- Utilização de Memória
- O alto uso de memória indica que o tamanho dos dados é muito grande para o tamanho atual do cache. Considere dimensionar para um tamanho de cache com memória maior. A expansão ou a expansão são eficazes aqui.
- Conexões de cliente
- Cada tamanho de cache tem um limite para o número de conexões de cliente que ele pode suportar. Se as conexões do cliente estiverem próximas do limite para o tamanho do cache, considere dimensionar para uma camada maior. A expansão não aumenta o número de conexões de cliente suportadas.
- Para obter mais informações sobre limites de conexão por tamanho de cache, consulte Preços do Cache do Azure para Redis.
- Largura de banda da rede
- Se o servidor Redis exceder a largura de banda disponível, as solicitações dos clientes poderão atingir o tempo limite porque o servidor não pode enviar dados para o cliente com rapidez suficiente. Para ver quanta largura de banda do lado do servidor está sendo usada, verifique as métricas "Cache Read" e "Cache Write". Se o servidor Redis estiver excedendo a largura de banda de rede disponível, você deve considerar a expansão ou dimensionamento para um tamanho de cache maior com maior largura de banda de rede.
- Para caches de camada Enterprise usando a política de cluster Enterprise, o dimensionamento não aumenta a largura de banda da rede.
- Para obter mais informações sobre a largura de banda disponível na rede por tamanho de cache, consulte Perguntas frequentes sobre planejamento do Cache do Azure para Redis.
- Varreduras internas do Defender
- Nos caches C0 e C1 Standard, enquanto a verificação interna do Defender está sendo executada nas VMs, você pode ver pequenos picos na carga do servidor não causados por um aumento nas solicitações de cache. Você vê uma latência mais alta 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 único núcleo para multitarefa, dividindo o trabalho de atender às solicitações internas do Defender e do Redis. Você pode reduzir o efeito dimensionando para uma oferta de camada mais alta com vários núcleos de CPU, como C2.
- O aumento do tamanho do cache nas camadas mais altas ajuda a resolver quaisquer problemas de latência. Além disso, no nível C2 , você tem suporte para até 2.000 conexões de cliente.
Para obter mais informações sobre como determinar a camada de preço de cache a ser usada, consulte Escolhendo a camada certa e Perguntas frequentes sobre planejamento do Cache do Azure para Redis.
Nota
Para obter mais informações sobre como otimizar o processo de dimensionamento, consulte o guia de práticas recomendadas para dimensionamento
Pré-requisitos/limitações do dimensionamento do Cache do Azure para Redis
Você pode aumentar ou diminuir para um nível de preço diferente com as seguintes restrições:
- Não é possível escalar de um nível de preço mais alto para um nível de preço mais baixo.
- Não é possível dimensionar de um cache Enterprise ou Enterprise Flash para qualquer outra camada.
- Não é possível dimensionar de um cache Premium para um cache Standard ou Basic.
- Não é possível dimensionar de um cache padrão para um cache básico .
- Você pode dimensionar de um cache Básico para um cache Padrão , mas não pode alterar o tamanho ao mesmo tempo. Se você precisar de um tamanho diferente, poderá posteriormente fazer uma operação de dimensionamento para o tamanho desejado.
- Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, dimensione de Basic para Standard em uma operação de dimensionamento e, em seguida, de Standard para Premium na próxima operação de dimensionamento.
- Não é possível dimensionar de um tamanho maior para o tamanho C0 (250 MB). No entanto, você pode dimensionar para qualquer outro tamanho dentro do mesmo nível de preço. Por exemplo, você pode escalar de C5 Standard para C1 Standard.
- Não é possível dimensionar de um cache Premium, Standard ou Basic para um cache Enterprise ou Enterprise Flash .
- Não é possível dimensionar entre Enterprise e Enterprise Flash.
Você pode expandir/aumentar com as seguintes restrições:
- A expansão só é suportada nas camadas Premium, Enterprise e Enterprise Flash.
- A escala só é suportada no nível Premium .
- Na camada Premium, o clustering deve ser habilitado primeiro antes de aumentar ou diminuir a escala.
- No nível Premium, o suporte para escalabilidade horizontal de até 10 fragmentos está geralmente disponível. O suporte para até 30 fragmentos está em pré-visualização. (Para caches com duas réplicas, o limite de estilhaços é 20. Com três réplicas, o limite de estilhaços é 15.)
- Somente as camadas Enterprise e Enterprise Flash podem ser dimensionadas e expandidas simultaneamente.
Como dimensionar - níveis Básico, Standard e Premium
Aumente e diminua a escala usando o portal do Azure
Para dimensionar seu cache, navegue até o cache no portal do Azure e selecione Dimensionar no menu Recurso.
Escolha um nível de preço no painel de trabalho e, em seguida, escolha Selecionar.
Enquanto o cache está sendo dimensionado para a nova camada, uma notificação de Cache Redis de Dimensionamento é exibida.
Quando o dimensionamento estiver concluído, o status mudará de Dimensionamento para Execução.
Nota
Quando você dimensiona um cache para cima ou para baixo usando o portal, ambas as maxmemory-reserved configurações são maxfragmentationmemory-reserved dimensionadas automaticamente proporcionalmente ao tamanho do cache.
Por exemplo, se maxmemory-reserved estiver definido como 3 GB em um cache de 6 GB e você dimensionar para cache de 12 GB, as configurações serão atualizadas automaticamente para 6 GB durante o dimensionamento.
Quando você reduz a escala, acontece o inverso.
Aumente e diminua a escala usando o PowerShell
Você pode dimensionar seu Cache do Azure para instâncias Redis com o PowerShell usando o cmdlet Set-AzRedisCache quando as Sizepropriedades ou Sku forem modificadas. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para um cache de 6 GB na mesma camada.
Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB
Para obter mais informações sobre dimensionamento com o PowerShell, consulte Para dimensionar um Cache do Azure para Redis usando o PowerShell.
Aumente e diminua a escala usando a CLI do Azure
Para dimensionar seu Cache do Azure para instâncias Redis usando a CLI do Azure, chame o comando az redis update . Use a sku.capcity propriedade para dimensionar dentro de uma camada, por exemplo, de um cache C0 padrão para C1 padrão:
az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"
Use as propriedades 'sku.name' e 'sku.family' para escalar para uma camada diferente, por exemplo, de um cache C1 padrão para um cache P1 Premium:
az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"
Para obter mais informações sobre dimensionamento com a CLI do Azure, consulte Alterar configurações de um Cache do Azure para Redis existente.
Nota
Quando você dimensiona um cache para cima ou para baixo programaticamente (por exemplo, usando o PowerShell ou a CLI do Azure), qualquer maxmemory-reserved um ou maxfragmentationmemory-reserved é ignorado como parte da solicitação de atualização. Apenas a sua alteração de escala é honrada. Você pode atualizar essas configurações de memória após a conclusão da operação de dimensionamento.
Como aumentar e reduzir a escala - níveis Enterprise e Enterprise Flash
As camadas Enterprise e Enterprise Flash podem ser dimensionadas e expandidas em uma única operação. Outros níveis exigem operações separadas para cada ação.
Atenção
As camadas Enterprise e Enterprise Flash ainda não suportam redução ou dimensionamento em operações.
Dimensionar usando o portal do Azure
Para dimensionar seu cache, navegue até o cache no portal do Azure e selecione Dimensionar no menu Recurso.
Para aumentar a escala, escolha um tipo de cache diferente e, em seguida, escolha Salvar.
Importante
Você só pode aumentar a escala neste momento. Não é possível reduzir a escala.
Para dimensionar, aumente o controle deslizante Capacidade . A capacidade aumenta em incrementos de dois. Esse número reflete quantos nós Redis Enterprise subjacentes 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
Você só pode escalar, aumentando a capacidade, neste momento. Não é possível escalar.
Enquanto o cache está sendo dimensionado para a nova camada, uma notificação de Cache Redis de Dimensionamento é exibida.
Quando o dimensionamento estiver concluído, o status mudará de Dimensionamento para Execução.
Dimensionar usando o PowerShell
Você pode dimensionar seu Cache do Azure para instâncias Redis com o PowerShell usando o cmdlet Update-AzRedisEnterpriseCache . Você pode modificar a Sku propriedade para dimensionar a instância. Você pode modificar a Capacity propriedade para dimensionar a instância. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para uma instância 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 dimensionar seu Cache do Azure para instâncias Redis usando a CLI do Azure, chame o comando az redisenterprise update . Você pode modificar a sku propriedade para dimensionar a instância. Você pode modificar a capacity propriedade para dimensionar a instância. O exemplo a seguir mostra como dimensionar um cache nomeado myCache para uma instância 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 do Azure para Redis.
- Posso dimensionar para, de ou dentro de um cache Premium?
- Após o dimensionamento, tenho que alterar meu nome de cache ou chaves de acesso?
- Como funciona o dimensionamento?
- Perco dados do meu cache durante o dimensionamento?
- Posso usar todos os recursos do nível Premium após o dimensionamento?
- Minha configuração de bancos de dados personalizados é afetada durante o dimensionamento?
- Meu cache estará disponível durante o dimensionamento?
- Existem limitações de dimensionamento com a replicação geográfica?
- Operações que não são suportadas
- Quanto tempo demora o dimensionamento?
- Como posso saber quando o dimensionamento está concluído?
- Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?
- Como as chaves são distribuídas em um cluster?
- Qual é o maior tamanho de cache que posso criar?
- Todos os clientes Redis suportam clustering?
- Como faço para me conectar ao meu cache quando o clustering está habilitado?
- Posso me conectar diretamente aos fragmentos individuais do meu cache?
- Posso configurar o clustering para um cache criado anteriormente?
- Posso configurar o clustering para um cache básico ou padrão?
- Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching?
- Estou recebendo exceções MOVE ao usar o StackExchange.Redis e clustering, o que devo fazer?
- Qual é a diferença entre OSS Clustering e Enterprise Clustering em caches de camada empresarial?
- Quantos fragmentos os caches de camada Enterprise usam?
Posso dimensionar para, de ou dentro de um cache Premium?
- Não é possível dimensionar de um cache Premium para um nível de preço Básico ou Padrão .
- Você pode escalar de um nível de preço de cache Premium para outro.
- Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, dimensione de Basic para Standard em uma operação de dimensionamento e, em seguida, de Standard para Premium em uma operação de dimensionamento posterior.
- Não é possível dimensionar de um cache Premium para um cache Enterprise ou Enterprise Flash .
- Se você habilitou o clustering quando criou o cache Premium , pode alterar o tamanho do cluster. Se o cache foi criado sem clustering habilitado, você pode configurar o clustering posteriormente.
Após o dimensionamento, tenho que alterar meu nome de cache ou chaves de acesso?
Não, o nome e as chaves do cache permanecem inalterados durante uma operação de dimensionamento.
Como funciona o dimensionamento?
- Quando você dimensiona um cache básico para um tamanho diferente, o cache é desligado e um novo cache é provisionado usando o novo tamanho. Durante esse tempo, o cache fica indisponível e todos os dados no cache são perdidos.
- Quando você dimensiona um cache Básico para um cache Padrão , um cache de réplica é provisionado e os dados são copiados do cache primário para o cache de réplica. O cache permanece disponível durante o processo de dimensionamento.
- Quando você dimensiona um cache Flash Standard, Premium, Enterprise ou Enterprise para um tamanho diferente, uma das réplicas é desligada e reprovisionada para o novo tamanho e os dados transferidos e, em seguida, a outra réplica faz um failover antes de ser reprovisionada, semelhante ao processo que ocorre durante uma falha de um dos nós de cache.
- Quando você dimensiona um cache clusterizado, novos fragmentos são provisionados e adicionados ao cluster de servidor Redis. Os dados são então reharded em todos os fragmentos.
- Quando você dimensiona em um cache clusterizado, os dados são primeiro redimensionados e, em seguida, o tamanho do cluster é reduzido para fragmentos necessários.
- Em alguns casos, como dimensionamento ou migração do cache para um cluster diferente, o endereço IP subjacente do cache pode ser alterado. O registro DNS do cache é alterado e transparente para a maioria dos aplicativos. No entanto, se você usar um endereço IP para configurar a conexão com o cache, ou para configurar NSGs ou firewalls que permitam o tráfego para o cache, seu aplicativo poderá ter problemas para se conectar em algum momento após as atualizações do registro DNS.
Perco dados do meu cache durante o dimensionamento?
- 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 dimensionamento.
- Quando você dimensiona um cache Básico para um cache Padrão , os dados no cache geralmente são preservados.
- Quando você dimensiona um cache Flash Standard, Premium, Enterprise ou Enterprise para um tamanho maior, todos os dados normalmente 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 os dados forem perdidos durante a redução, as chaves serão removidas usando a política de remoção allkeys-lru .
Posso usar todos os recursos do nível Premium após o dimensionamento?
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.
Estes recursos não podem ser adicionados depois de criar o cache Premium:
- Injeção de rede virtual
- Adicionando redundância de zona
- Usando várias réplicas por principal
Para usar qualquer um desses recursos, você deve criar uma nova instância de cache na camada Premium.
Minha configuração de bancos de dados personalizados é afetada durante o dimensionamento?
Se você configurou um valor personalizado para a configuração durante a criação do databases cache, lembre-se de que algumas camadas de preços têm limites de bancos de dados diferentes. Aqui estão algumas considerações ao dimensionar neste cenário:
- Quando você escala para uma camada de preço com um limite menor
databasesdo que a camada atual:- Se você estiver usando o número padrão do , que é 16 para todos os níveis de
databasespreço, nenhum dado será perdido. - Se você estiver usando um número personalizado que esteja dentro dos
databaseslimites da camada para a qual você está dimensionando, essadatabasesconfiguração será mantida e nenhum dado será perdido. - Se você estiver usando um número personalizado que
databasesexceda os limites da nova camada, adatabasesconfiguração será reduzida aos limites da nova camada e todos os dados nos bancos de dados removidos serão perdidos.
- Se você estiver usando o número padrão do , que é 16 para todos os níveis de
- Quando você escala para um nível de preço com o mesmo limite ou maior
databasesdo que o nível atual, suadatabasesconfiguração é mantida e nenhum dado é perdido.
Embora os caches Flash Standard, Premium, Enterprise e Enterprise tenham um SLA para disponibilidade, não há SLA para perda de dados.
Meu cache estará disponível durante o dimensionamento?
- Os caches Flash Standard, Premium, Enterprise e Enterprise permanecem disponíveis durante a operação de dimensionamento. No entanto, blips de conexão podem ocorrer durante o dimensionamento desses caches e também durante o dimensionamento de caches básicos para padrão. Espera-se que esses blips de conexão sejam pequenos e os clientes redis geralmente podem restabelecer sua conexão instantaneamente.
- Para caches Enterprise e Enterprise Flash que usam replicação geográfica ativa, dimensionar apenas um subconjunto de caches vinculados pode introduzir problemas ao longo do tempo em alguns casos. Sempre que possível, recomendamos o dimensionamento de todos os caches no grupo de replicação geográfica.
- Os caches básicos ficam offline durante as operações de dimensionamento para um tamanho diferente. Os caches básicos permanecem disponíveis ao dimensionar do Basic para o Standard, mas podem ter um pequeno problema de conexão. Se ocorrer um blip de conexão, os clientes Redis geralmente podem restabelecer sua conexão instantaneamente.
Existem limitações de dimensionamento com a replicação geográfica?
Com a replicação geográfica passiva configurada, você pode notar que não é possível dimensionar 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 altere o número de fragmentos em um cluster. Você deve desvincular o cache para emitir esses comandos. Para obter mais informações, consulte Configurar a replicação geográfica.
Com a replicação geográfica ativa configurada, não é possível dimensionar um cache. Todos os caches em um grupo de replicação geográfica devem ter o mesmo tamanho e capacidade.
Operações que não são suportadas
- Não é possível escalar de um nível de preço mais alto para um nível de preço mais baixo.
- Não é possível dimensionar de um cache Premium para um cache Standard ou Basic.
- Não é possível dimensionar de um cache padrão para um cache básico .
- Você pode dimensionar de um cache Básico para um cache Padrão , mas não pode alterar o tamanho ao mesmo tempo. Se você precisar de um tamanho diferente, poderá fazer uma operação de dimensionamento para o tamanho desejado posteriormente.
- Não é possível dimensionar de um cache Básico diretamente para um cache Premium . Primeiro, dimensione de Basic para Standard em uma operação de dimensionamento e, em seguida, dimensione de Standard para Premium em uma operação posterior.
- Não é possível dimensionar 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 demora o dimensionamento?
O tempo de dimensionamento depende de alguns fatores. Aqui estão alguns fatores que podem afetar o tempo que o dimensionamento demora.
- Quantidade de dados: quantidades maiores de dados levam mais tempo para serem replicadas
- Solicitações de gravação altas: maior número de gravações significa mais dados replicados entre nós ou fragmentos
- Alta carga do servidor: maior carga do servidor significa que o servidor Redis está ocupado e ciclos de CPU limitados estão disponíveis para concluir a redistribuição de dados
Dimensionar um cache é uma ação não trivial e pode levar muito tempo.
Com base em exemplos do mundo real, o tempo para dimensionar o cache com um a dois fragmentos pode ser de 1 a 2 horas quando o cache não está sob cargas pesadas. Se você tiver mais fragmentos, o tempo para escalar não aumenta de forma linear.
Como posso saber quando o dimensionamento está concluído?
No portal do Azure, você pode ver a operação de dimensionamento em andamento. Quando o dimensionamento estiver concluído, o status do cache será alterado para Em execução.
Preciso fazer alguma alteração no meu aplicativo cliente para usar clustering?
Quando o clustering está habilitado, somente o banco de dados 0 está disponível. Se seu aplicativo cliente usa vários bancos de dados e tenta ler ou gravar em um banco de dados diferente de zero, a seguinte exceção é lançada:
Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6Para obter mais informações, consulte Especificação do cluster Redis - subconjunto implementado.
Se você estiver usando StackExchange.Redis, deverá usar 1.0.481 ou posterior. Você se conecta ao cache usando os mesmos pontos de extremidade, portas e chaves que usa ao se conectar a um cache onde o clustering está desabilitado. A única diferença é que todas as leituras e gravações devem ser feitas no banco de dados 0.
Outros clientes podem ter requisitos diferentes. Consulte Todos os clientes Redis suportam clustering?
Se seu aplicativo usa várias operações de chave em lote em um único comando, todas as chaves devem estar localizadas no mesmo fragmento. Para localizar chaves no mesmo fragmento, consulte Como as chaves são distribuídas em um cluster?
Se você estiver usando o Redis ASP.NET provedor de Estado de Sessão, deverá usar 2.0.1 ou superior. Consulte Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching?
Importante
Ao usar as camadas Enterprise ou Enterprise FLash, você tem a opção de Modo de Cluster OSS ou Modo de Cluster Empresarial. O Modo de Cluster OSS é 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 cluster Redis Enterprise, que não requer nenhuma alteração no cliente para ser usado. Para obter mais informações, consulte Clustering on 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 de chave é dividido em 16.384 slots. É aplicado um hash a cada chave e é atribuída a um desses blocos, que são distribuídos pelos nós do cluster. Pode configurar a que parte da chave é aplicado o hash para garantir que várias chaves estão localizadas na mesma extensão com etiquetas hash.
- Chaves com uma etiqueta hash – se alguma parte da chave estiver incluída em
{e}, o hash será aplicado apenas a essa parte da chave para efeitos de determinar o bloco hash de uma chave. Por exemplo, as três chaves que se seguem devem estar localizadas na mesma extensão:{key}1,{key}2e{key}3, dado que o hash apenas é aplicado à partekeydo nome. Para obter uma lista completa das especificações das etiquetas hash das chaves, veja Etiquetas das chaves hash. - Chaves sem etiqueta hash – o nome de chave completo é utilizado para hashing, o que resulta numa distribuição estatisticamente uniforme através das extensões da cache.
Para obter o melhor desempenho e rendimento, recomendamos distribuir as chaves uniformemente. Se estiver a utilizar chaves com uma etiqueta hash, é da responsabilidade da aplicação garantir que as chaves são distribuídas uniformemente.
Para obter mais informações, veja Modelo de distribuição de chaves, Extensão de dados do Cluster de Redis e Etiquetas hash das chaves.
Para obter um código de exemplo sobre como trabalhar com clustering e localizar chaves no mesmo fragmento com o cliente StackExchange.Redis, consulte a parte clustering.cs do exemplo Hello World .
Qual é o maior tamanho de cache que posso criar?
O maior tamanho de cache que você pode ter é de 4,5 TB. Esse resultado é um cache F1500 clusterizado com capacidade 9. Para obter mais informações, consulte Preços do Cache do Azure para Redis.
Todos os clientes Redis suportam clustering?
Muitas bibliotecas de clientes suportam clustering Redis, mas não todas. Verifique a documentação da biblioteca que está a utilizar para verificar se está a utilizar uma biblioteca e uma versão que suportem clustering. StackExchange.Redis é uma biblioteca que suporta clustering, em suas versões mais recentes. Para obter mais informações sobre outros clientes, consulte a seção Jogando com o cluster do tutorial do cluster Redis.
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 cliente que não oferece suporte a clustering, com um cache de modo de cluster, o resultado pode ser muitas exceções de redirecionamento MOVIDO, ou apenas quebrar seu aplicativo, se você estiver fazendo solicitações de várias chaves entre slots.
Nota
Se você estiver usando StackExchange.Redis como seu cliente, verifique se você está usando a versão mais recente do StackExchange.Redis 1.0.481 ou posterior para que o clustering funcione corretamente. Para obter mais informações sobre quaisquer problemas com exceções de movimentação, consulte Mover exceções.
Como faço para me conectar ao meu cache quando o clustering está habilitado?
Você pode se conectar ao cache usando os mesmos pontos de extremidade, portas e chaves que usa ao se conectar a um cache que não tem clustering habilitado. O Redis gerencia o clustering no back-end para que você não precise gerenciá-lo a partir do seu cliente.
Posso me conectar diretamente aos fragmentos individuais do meu cache?
O protocolo de clustering requer que o cliente faça as conexões de estilhaço corretas, portanto, o cliente deve fazer conexões de compartilhamento para você. Dito isso, cada fragmento consiste em um par de cache primário/réplica, conhecido coletivamente como instância de cache. Você pode se conectar a essas instâncias de cache usando o utilitário Redis-CLI na ramificação instável do repositório Redis no GitHub. Esta versão implementa suporte básico quando iniciado com o -c switch. Para obter mais informações, consulte Jogando com o cluster ativado https://redis.io no tutorial do cluster Redis.
Você precisa usar o -p switch 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 de nível Premium não-TLS, as
130XXportas estão disponíveis no intervalo - Para caches de camada Premium habilitados para TLS, as
150XXportas estão disponíveis no intervalo - Para caches Enterprise e Enterprise Flash usando cluster OSS, a conexão inicial é através da porta 10000. A conexão com nós individuais pode ser feita usando portas no intervalo 85XX. As portas 85xx mudarão com o tempo e não devem ser codificadas em seu aplicativo.
Posso configurar o clustering para um cache criado anteriormente?
Sim. Primeiro, certifique-se de que seu cache esteja na camada Premium dimensionando-o. Em seguida, você pode ver as opções de configuração do cluster, incluindo uma opção para habilitar o cluster. Altere o tamanho do cluster depois que o cache for criado ou depois de habilitar o clustering pela primeira vez.
Importante
Não é possível desfazer a ativação do clustering. E um cache com clustering habilitado e apenas um fragmento se comporta de forma diferente de um cache do mesmo tamanho sem clustering.
Todos os caches das camadas Enterprise e Enterprise Flash estão sempre agrupados.
Posso configurar o clustering para um cache básico ou padrão?
O clustering só está disponível para caches Premium, Enterprise e Enterprise Flash.
Posso usar clustering com os provedores Redis ASP.NET Session State e Output Caching?
- Provedor de Cache de Saída Redis - sem necessidade de alterações.
- Provedor de Estado de Sessão Redis - para usar clustering, você deve usar RedisSessionStateProvider 2.0.1 ou superior ou uma exceção é lançada, o que é uma alteração de quebra. Para obter mais informações, consulte v2.0.0 Breaking Change Details.
Estou recebendo exceções MOVE ao usar o StackExchange.Redis e clustering, o que devo fazer?
Se você estiver usando StackExchange.Redis e receber MOVE exceções ao usar clustering, certifique-se de estar usando StackExchange.Redis 1.1.603 ou posterior. Para obter instruções sobre como configurar seus aplicativos .NET para usar StackExchange.Redis, consulte Configurar os clientes de cache.
Qual é a diferença entre OSS Clustering e Enterprise Clustering em caches de camada Enterprise?
O Modo de Cluster OSS é 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 menos desempenho, mas usa o cluster Redis Enterprise, que não requer nenhuma alteração no cliente para ser usado. Para obter mais informações, consulte Clustering on Enterprise.
Quantos fragmentos os caches de camada Enterprise usam?
Ao contrário dos caches de nível Basic, Standard e Premium, os caches Enterprise e Enterprise Flash podem tirar proveito de vários fragmentos em um único nó. Para obter mais informações, consulte Compartilhamento e utilização da CPU.