Nesta página, você encontra orientação sobre o uso ideal do Memorystore para Redis Cluster. Essa página também indica possíveis problemas que devem ser evitados.
Práticas recomendadas de gerenciamento de memória
Esta seção descreve estratégias para gerenciar a memória da instância para que o Memorystore para Redis Cluster funcione de maneira eficiente para seu aplicativo.
Conceitos de gerenciamento de memória
Carga de gravação: o volume e a velocidade com que você adiciona ou atualiza chaves no cluster do Redis. A carga de gravação pode variar de normal a muito alta, dependendo do caso de uso do Redis e dos padrões de uso do aplicativo.
Política de remoção: o cluster do Memorystore para Redis usa a
volatile-lrupolítica de remoção. Você pode usar comandos como EXPIRE para definir remoções de chaves.
Monitorar um cluster com uma carga de gravação normal
Confira a métrica /cluster/memory/maximum_utilization. Se /cluster/memory/maximum_utilization estiver em 100% ou menos, seu cluster do Redis terá um bom desempenho quando você usar uma carga de gravação normal.
No entanto, se o uso de memória se aproximar de 100% e você esperar que o uso de dados aumente, aumente o tamanho do cluster para abrir espaço para novos dados.
Monitorar um cluster com uma alta carga de gravação
Confira a métrica /cluster/memory/maximum_utilization. Dependendo da gravidade da carga alta de gravação, o cluster pode ter problemas de desempenho nos seguintes limites:
Cargas de gravação muito altas podem ter problemas se
/cluster/memory/maximum_utilizationatingir 65% ou mais.Cargas de gravação moderadamente altas podem ter problemas se
/cluster/memory/maximum_utilizationatingir 85% ou mais.
Nesses cenários, aumente o tamanho do cluster para melhorar o desempenho.
Se você tiver problemas ou achar que sua instância tem uma carga de gravação alta, entre em contato com o suporte doGoogle Cloud .
Como escalonar fragmentos
Ao escalonar o número de fragmentos em uma instância, faça isso durante períodos de baixa gravação. O escalonamento durante períodos de alta carga de gravação pode colocar pressão de memória na instância devido à sobrecarga de memória causada pela replicação ou migração de slots.
Se o caso de uso do Redis usar remoções de chaves, o escalonamento para um tamanho de cluster menor poderá reduzir a proporção de ocorrência em cache. No entanto, nessa circunstância, não é preciso se preocupar com a perda de dados, já que a remoção de chaves é esperada.
Para casos de uso do Redis em que você não quer perder chaves, faça reduzir escala vertical apenas para um cluster menor que ainda tenha espaço suficiente para seus dados. A nova contagem de fragmentos desejada precisa permitir pelo menos 1,5 vez a memória usada pelos dados. Em outras palavras, provisione fragmentos suficientes para 1,5 vezes a quantidade de dados atualmente no cluster. Use a métrica /cluster/memory/total_used_memory para saber a quantidade de dados armazenados na sua instância.
Práticas recomendadas para uso da CPU
Se ocorrer uma interrupção zonal inesperada, isso vai reduzir os recursos de CPU do cluster devido à perda de capacidade dos nós na zona indisponível. Recomendamos o uso de clusters de alta disponibilidade. Usar duas réplicas por fragmento (em vez de uma) fornece recursos extras de CPU durante uma interrupção. Além disso, recomendamos gerenciar o uso da CPU do nó para que ele tenha sobrecarga suficiente para lidar com o tráfego extra da capacidade perdida se ocorrer uma interrupção zonal inesperada. Monitore o uso da CPU para primários e réplicas usando a métrica /cluster/cpu/maximum_utilization.
Dependendo de quantas réplicas você provisiona por nó, recomendamos as seguintes metas de uso da CPU /cluster/cpu/maximum_utilization:
- Para instâncias com uma réplica por nó, defina um valor de
/cluster/cpu/maximum_utilizationde 0,5 segundo para a principal e 0,5 segundo para a réplica, quando ela for designada como uma réplica de leitura. - Para instâncias com duas réplicas por nó, defina um valor de
/cluster/cpu/maximum_utilizationde 0,8 segundo para a réplica principal e 0,5 segundo para cada réplica.
Se os valores da métrica excederem essas recomendações, aumente o número de fragmentos ou réplicas na sua instância.
Comandos do Redis com uso intensivo de recursos
Recomendamos evitar o uso de comandos do Redis que exigem muitos recursos. O uso desses comandos pode resultar nos seguintes problemas de desempenho:
- Alta latência e tempos limite do cliente
- Pressão na memória causada por comandos que aumentam o uso da memória
- Perda de dados durante a replicação e sincronização de nós porque a linha de execução principal do Redis está bloqueada
- Verificações de integridade, observabilidade e replicação sem recursos
A tabela a seguir lista exemplos de comandos do Redis que consomem muitos recursos e oferece alternativas eficientes.
| Categoria | Comando que usa muitos recursos | Alternativa eficiente em termos de recursos |
|---|---|---|
| Executar para todo o keyspace | KEYS |
SCAN |
| Executar para um conjunto de chaves de comprimento variável | LRANGE |
Limite o tamanho do intervalo usado em uma consulta. |
ZRANGE |
Limite o tamanho do intervalo usado em uma consulta. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Bloquear a execução de um script | EVAL |
Verifique se o script não é executado indefinidamente. |
EVALSHA |
Verifique se o script não é executado indefinidamente. | |
| Remover arquivos e links | DELETE |
UNLINK |
| Publicar e assinar | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Práticas recomendadas para clientes Redis
Seu aplicativo precisa usar um cliente Redis compatível com cluster ao se conectar a uma instância do Memorystore para Redis Cluster. Para exemplos de clientes compatíveis com clusters e configurações de amostra, consulte Exemplos de código da biblioteca de cliente. O cliente precisa manter um mapa de slots de hash para os nós correspondentes no cluster a fim de enviar solicitações aos nós certos e evitar a sobrecarga de desempenho causada por redirecionamentos de cluster.
Mapeamento de clientes
Os clientes precisam receber uma lista completa de slots e nós mapeados nas seguintes situações:
Quando o cliente é inicializado, ele precisa preencher o slot inicial com o mapeamento de nós.
Quando um redirecionamento
MOVEDé recebido do servidor, como em uma situação de failover em que todos os slots atendidos pelo antigo nó principal são assumidos pela réplica ou em um refragmentação quando os slots estão sendo movidos da origem primária para o nó principal de destino.Quando um erro
CLUSTERDOWNé recebido do servidor ou as conexões com um servidor específico atingem tempos limite de forma persistente.Quando um erro
READONLYé recebido do servidor. Isso pode acontecer quando uma instância principal é rebaixada para réplica.Além disso, os clientes precisam atualizar periodicamente a topologia para manter os clientes ativos para qualquer mudança e saber sobre mudanças que podem não resultar em redirecionamentos / erros do servidor, como quando novos nós de réplica são adicionados. Conexões desatualizadas também precisam ser fechadas como parte da atualização da topologia para reduzir a necessidade de lidar com conexões com falha durante a execução do comando.
Descoberta de clientes
A descoberta de clientes geralmente é feita emitindo um comando CLUSTER SLOT, CLUSTER NODE ou CLUSTER SHARDS para o servidor Redis. Recomendamos usar o comando CLUSTER SHARDS. O CLUSTER SHARDS substitui o comando CLUSTER SLOTS (descontinuado) e oferece uma representação mais eficiente e extensível do cluster.
O tamanho da resposta para os comandos de descoberta de clientes do cluster pode variar com base no tamanho e na topologia do cluster. Clusters maiores com mais nós produzem uma resposta maior. Por isso, é importante garantir que o número de clientes que fazem a descoberta da topologia do cluster não cresça sem limites.
Essas atualizações de topologia são caras no servidor Redis, mas também são importantes para a disponibilidade do aplicativo. Portanto, é importante garantir que cada cliente faça uma única solicitação de descoberta a qualquer momento (e armazene o resultado na memória) e que o número de clientes que fazem as solicitações seja limitado para evitar sobrecarregar o servidor.
Por exemplo, quando o aplicativo cliente é iniciado ou perde a conexão com o servidor e precisa realizar a descoberta de cluster, um erro comum é que o aplicativo cliente faz várias solicitações de reconexão e descoberta sem adicionar espera exponencial na nova tentativa. Isso pode deixar o servidor Redis sem resposta por um longo período, causando uma utilização muito alta da CPU.
Evitar sobrecarga de descoberta no Redis
Para reduzir o impacto causado por um fluxo repentino de solicitações de conexão e descoberta, recomendamos o seguinte:
Implemente um pool de conexões de cliente com um tamanho finito e pequeno para limitar o número de conexões de entrada simultâneas do aplicativo cliente.
Quando o cliente se desconecta do servidor devido a um tempo limite, tente de novo com espera exponencial com jitter. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.
Use o endpoint de descoberta do cluster do Memorystore para Redis para realizar a descoberta de clusters. O endpoint de descoberta tem alta disponibilidade e é balanceado por carga em todos os nós do cluster. Além disso, o endpoint de descoberta tenta rotear as solicitações de descoberta de cluster para nós com a visualização de topologia mais atualizada.
Práticas recomendadas de persistência
Esta seção explica as práticas recomendadas para persistência.
Persistência do RDB e adição de réplicas
Para ter os melhores resultados ao fazer backup da sua instância com snapshots de RDB ou adicionar réplicas a ela, use as seguintes práticas recomendadas:
Gerenciamento de memória
Os snapshots do RDB usam um fork de processo e um mecanismo de cópia na gravação para criar um snapshot dos dados do nó. Dependendo do padrão de gravações nos nós, a memória usada deles aumenta à medida que as páginas afetadas pelas gravações são copiadas. A ocupação de memória pode ser até o dobro do tamanho dos dados no nó.
Para garantir que os nós tenham memória suficiente para concluir o snapshot, mantenha ou defina maxmemory em 80% da capacidade do nó para que 20% sejam reservados para sobrecarga. Essa sobrecarga de memória, além dos snapshots de monitoramento, ajuda você a gerenciar sua carga de trabalho para ter snapshots bem-sucedidos. Além disso, ao adicionar réplicas, reduza o tráfego de gravação o máximo possível. Consulte Monitorar um cluster com uma alta carga de gravação para saber mais.
Snapshots desatualizados
A recuperação de nós de um snapshot desatualizado pode causar problemas de desempenho no aplicativo, já que ele tenta reconciliar uma quantidade significativa de chaves desatualizadas ou outras mudanças no banco de dados, como uma mudança de esquema. Se você estiver preocupado com a recuperação de um snapshot desatualizado, desative o recurso de persistência do RDB. Depois que você reativar a persistência, um snapshot será criado no próximo intervalo programado.
Impacto no desempenho dos snapshots do RDB
Dependendo do padrão da carga de trabalho, os snapshots do RDB podem afetar o desempenho da instância e aumentar a latência dos aplicativos. Para minimizar o impacto na performance dos snapshots do RDB, programe a execução deles durante períodos de baixo tráfego de instâncias, se você não se importar com snapshots menos frequentes.
Por exemplo, se a instância tiver pouco tráfego das 1h às 4h, defina o horário de início como 3h e o intervalo como 24 horas.
Se o sistema tiver uma carga constante e exigir snapshots frequentes, avalie com cuidado o impacto na performance e pondere os benefícios de usar snapshots do RDB para a carga de trabalho.
Adicionar uma réplica
Para adicionar uma réplica, é necessário um snapshot do RDB. Para mais informações sobre snapshots de RDB, consulte Gerenciamento de memória.
Escolha uma instância de zona única se ela não usar réplicas
Ao configurar uma instância sem réplicas, recomendamos uma arquitetura de zona única para melhorar a confiabilidade. Geralmente, estes são os motivos:
Minimizar o impacto de interrupções
É menos provável que falhas zonais afetem sua instância. Ao colocar todos os nós em uma única zona, a chance de uma interrupção zonal afetar seu servidor cai de 100% para 33%. Isso acontece porque há uma chance de 33% de a zona em que sua instância está localizada ficar inativa, em vez de 100% de chance de os nós localizados na zona indisponível serem afetados.
Recuperação rápida
Se ocorrer uma interrupção temporária na zona, a recuperação será simplificada. Você pode responder provisionando rapidamente uma nova instância em uma zona em funcionamento e redirecionando seu aplicativo para operações minimamente interrompidas.
Práticas recomendadas para o Lettuce
Nesta seção, descrevemos as práticas recomendadas para usar o Lettuce para se conectar a uma instância do cluster do Memorystore para Redis.
Atualizar valores de parâmetro
Ao usar o Lettuce, mude o parâmetro validateClusterNodeMembership para
false. Caso contrário, quando a topologia mudar, você poderá receber erros unknownPartition.