Documentação do Oracle Cloud Infrastructure

Melhores Práticas do Cliente do OCI Cache

As melhores práticas a seguir se aplicam a todas as interações do cliente do OCI Cache, independentemente de o cluster de destino operar no modo não particionado ou com sharding. Seguir essas diretrizes garante um comportamento consistente e reduz os riscos operacionais comuns. Essas recomendações fornecem orientação geral e não se destinam à documentação exaustiva. Para obter informações detalhadas sobre suas bibliotecas específicas e casos de uso do Redis ou Valkey, consulte os recursos apropriados.

Recomendações de dimensionamento e configuração do cluster

A seleção do tamanho de cache correto para seu cluster ajuda a otimizar o desempenho e o uso de recursos. O tamanho do cache deve refletir as cargas de trabalho de aplicativos esperadas e se ajustar às alterações durante os períodos de pico dos negócios. O OCI Cache permite que você expanda ou reduza seu cluster para atender às suas necessidades.

Antes de dimensionar o cluster de cache, considere os padrões de carga de trabalho do aplicativo e as expectativas de crescimento futuro.

Responda às seguintes perguntas para escolher o melhor tamanho e configuração para o cluster de cache:
  • Seu aplicativo é pesado ou pesado?
    • Se o tamanho dos seus dados não exceder 500 GB, use um cluster não fragmentado e adicione réplicas de leitura suficientes para distribuir o tráfego.
    • Gravação pesada: Se você planeja armazenar grandes quantidades de dados no cache, considere um cluster com sharding. O sharding distribui o tráfego de gravação entre nós, resultando em maior throughput e evitando gargalos.
    • Leitura e gravação: Use um cluster com sharding com réplicas de leitura para cada shard. Essa configuração fornece alta disponibilidade e escalabilidade para ambas as cargas de trabalho.
  • Como você escolhe o tamanho correto do cache?

    Defina o tamanho do cache para pelo menos 50% maior que o tamanho de dados atual. Esse buffer ajuda a tratar picos inesperados em cargas de trabalho até que você redimensione o cluster.

    Para obter orientação sobre como selecionar um padrão de dimensionamento para sua carga de trabalho, incluindo réplicas, sharding, definições de tempo de vida útil (TTL), políticas de remoção e gerenciamento de conexão, consulte Dimensionando o Cache da OCI: Escolhendo o padrão certo para sua carga de trabalho.

  • Quanto de memória você deve reservar para uso sem cache?

    Você pode usar o parâmetro reserved-memory-percentage para reservar uma parte da memória de cache de cada nó para o headroom operacional que não é contado para Redis ou Valkey maxmemory. Para a maioria das cargas de trabalho de produção, comece com 25%.

    Para cargas de trabalho com carga de gravação, que retornam respostas grandes, têm altas contagens de conexão, exigem backups frequentes ou envolvem replicação significativa, use uma porcentagem maior. Para clusters com replicação entre regiões, defina o valor para pelo menos 35%. Para usar o reserved-memory-percentage, crie ou copie uma configuração personalizada, adicione o parâmetro reserved-memory-percentage à configuração e anexe a configuração ao cluster.

  • Como você pode planejar futuros aumentos na capacidade de armazenamento ou gravação?

    Crie um cluster com sharding para flexibilidade. Os clusters com sharding facilitam o dimensionamento da capacidade de armazenamento e gravação à medida que suas necessidades aumentam.

  • Quando você deve usar vários bancos de dados no cache?

    Se seu aplicativo precisar separar dados no mesmo cache para diferentes finalidades, como armazenamento em cache e gerenciamento de sessão, escolha um cluster não fragmentado e ajuste o parâmetro de bancos de dados conforme necessário. O suporte para vários bancos de dados só está disponível em clusters não fragmentados.

  • Você pode executar scripts Lua em um cluster com sharding?

    Sim, você pode executar scripts Lua em um cluster com sharding. No entanto, recomendamos que você use um cluster não fragmentado para scripts Lua. Os scripts Lua exigem que todas as chaves referenciadas residam no mesmo slot, o que é mais fácil de gerenciar em um cluster não fragmentado.

Compatibilidade da biblioteca do cliente

Use bibliotecas de clientes totalmente compatíveis com o OCI Cache. As versões mínimas recomendadas incluem Lettuce (6.x ou posterior, especialmente para suporte a cluster com sharding) e Redisson (3.36.0 ou posterior), que oferecem suporte a recursos como TLS (Transport Layer Security) e mecanismos de autenticação exigidos pelo OCI Cache. Sempre teste novas versões de biblioteca em um ambiente de preparação antes de implantar em produção para garantir compatibilidade e estabilidade.

A tabela a seguir lista as versões mínimas compatíveis das bibliotecas do cliente para várias linguagens de programação que suportam o modo de cluster (sharding) no OCI Cache, juntamente com observações relevantes sobre os recursos de suporte ao cluster.

Matriz de compatibilidade para bibliotecas de clientes
Biblioteca (Idioma) Link GitHub Versão Mínima Compatível Observações de Suporte ao Cluster
redis-py (Python) redis/redis-py 5+ Suporte ao modo de cluster nativo desde a versão 5.0.0
Alface (Java) alface 6,3 Suporte a cluster completo
Jedis (Java) jedis 3,1 Cluster suportado via JedisCluster
Redisson (Java) redisson 3,36 Suporta totalmente o cluster Redis
redis-rb (Ruby) redis-rb 5,3 Requer joia de clusterização redis
redis-rs (Rust) redis-rs 0,26 Suporte parcial; o modo de cluster pode variar conforme o caso de uso
phpredis (PHP) phpredis 6+ Suporte a cluster via RedisCluster
Go-Redis (Ir) go-redis v9.6.1 Suporta totalmente o modo de cluster
StackExchange.Redis (Nº C) StackExchange.Redis Não Suportado Requer AllowAdmin=true, falta compatibilidade total do cluster; comunicação de nome de host não suportada
ServiceStack.Redis (Nº C) ServiceStack.Redis Não Suportado Sem suporte ao modo de cluster
contratadois-cluster (C) contratadois-cluster Não Suportado Sem suporte para comunicação de nome de host

Otimização de conexão

As dicas a seguir sugerem ações que você pode executar no código do aplicativo. Você também pode implementar backoff exponencial.

  • Ativar pool de conexões: reutilize as conexões existentes para reduzir a sobrecarga de estabelecer novas conexões para cada solicitação. Essa abordagem evita a exaustão de recursos e melhora o desempenho do aplicativo. Ajuste os tamanhos dos pools com base na simultaneidade de aplicativos e na capacidade do cluster. Defina parâmetros como conexões ociosas mínimas ou máximas, timeouts de conexão e tempos de espera máximos para conexões.
  • Otimizar conexões simultâneas: cada nó do OCI Cache suporta até 40.000 conexões de cliente. Dimensione pools de conexões com base na carga de trabalho, nos padrões de comando e no comportamento do cliente e evite manter mais conexões do que o necessário. Conexões simultâneas excessivas podem aumentar a latência de carga e resposta do processo.
  • Defina tempos limite apropriados: defina valores de tempo limite adequados para comandos e conexões, geralmente entre 2000 ms e 5000 ms, para evitar atrasos durante interrupções de rede ou atrasos no servidor.
  • Configurar mecanismos de repetição: Estabeleça políticas de repetição para tratar falhas transitórias, como interrupções de rede. Por exemplo, configure três tentativas de repetição com um intervalo de 1000 ms entre as tentativas para ajudar a garantir a recuperação.
  • Gerenciar conexões ociosas: Feche conexões não utilizadas para evitar vazamentos e liberar recursos, o que impede que o nó do cache exceda seu limite de conexão.

Segurança e conformidade com TLS

  • O OCI Cache exige TLS para todas as conexões de cliente por padrão. O TLS sempre está ativado na porta 6379. Você pode permitir acesso TCP adicional na porta 7379, se necessário. Certifique-se de que as bibliotecas do cliente ofereçam suporte ao TLS versão 1.2 ou posterior e usem conjuntos de cifras atuais para manter canais de comunicação seguros.
  • Se o desempenho for crítico, colabore com as equipes de suporte e segurança da OCI para avaliar o impacto da sobrecarga de TLS. A desativação do TLS em ambientes de produção é desencorajada devido a vulnerabilidades de segurança.

Melhores práticas de segurança

Proteja o OCI Cache desde o início para evitar acesso não autorizado e vulnerabilidades. Embora o OCI Cache obrigue o TLS para todas as conexões de cliente por padrão, medidas de segurança adicionais são críticas para ambientes de produção.

  • Restringir o acesso: Configure políticas de rede para permitir conexões apenas de redes confiáveis ou localhost. Evite expor pontos finais do OCI Cache à internet pública.
  • Definir autenticação forte: Garanta que senhas robustas ou mecanismos de autenticação estejam em vigor de acordo com as diretrizes de segurança da OCI para evitar acesso não autorizado. Além disso, use o Roteamento de Pacote de Confiança Zero e o suporte a NSG (grupo de segurança de rede) no serviço para impor o acesso baseado em política às instâncias do OCI Cache. Essa abordagem aumenta ainda mais a segurança, restringindo o acesso apenas a entidades autorizadas.
  • Desativar comandos perigosos: Limite o acesso a comandos potencialmente prejudiciais, como FLUSHALL e CONFIG, para evitar perda acidental ou maliciosa de dados no Redis.
  • Aproveite as configurações protegidas: Use os recursos de segurança integrados do OCI Cache e revise regularmente os controles de acesso para manter um ambiente seguro.

Gerenciamento e expiração de chaves

Não é necessário definir um TTL (time-to-live) para cada chave. Algumas chaves podem persistir indefinidamente. No entanto, recomendamos a definição de valores TTL razoáveis para a maioria das chaves. A definição de TTLs ajuda a evitar que dados obsoletos ou órfãos permaneçam no cache. Essa abordagem garante a atualização dos dados e o uso eficiente da memória.

Quando o cache atingir seu limite de memória, você poderá configurar o parâmetro maxmemory-policy para remover automaticamente as chaves de acordo com a política de remoção selecionada. Essa configuração ajuda a otimizar o gerenciamento de memória.

Monitoramento e configuração de alertas

  • Monitore as principais métricas, como utilização de memória, e defina alertas para limites (por exemplo, quando a utilização exceder 80% por 30 minutos) para evitar condições de falta de memória e falhas de cluster. O monitoramento contínuo é essencial para manter o desempenho do OCI Cache à medida que as cargas de trabalho evoluem.
    • Ativar registro em log detalhado: Use ferramentas como SLOWLOG para identificar comandos lentos antes que eles afetem o desempenho.
    • Revise logs regularmente: Verifique se há avisos, erros ou padrões incomuns nos logs do OCI Cache para antecipar problemas.
    • Monitore as taxas de remoção e memória: Rastreie a frequência de remoção principal juntamente com as métricas existentes, como a utilização da memória (por exemplo, acima de 80% por 30 minutos) para ajustar os limites ou políticas de memória proativamente.
  • Rastreie métricas, incluindo clientes conectados, conexões rejeitadas e latência de comandos, para identificar e resolver gargalos ou anomalias. Monitore os índices de ocorrências e falhas do cache para detectar o uso ineficiente e ajustar as políticas de chave ou remoção conforme necessário.
  • Defina alarmes para outras métricas, como eventos de remoção e contagem de conexões, para manter a integridade do cluster.
  • Redimensione o cluster se a utilização de memória violar consistentemente o limite ou se a utilização da CPU indicar operações de gravação mais altas.

Uso de comando otimizado

  • Minimize o uso de comandos O(n), como KEYS. Em vez dela, use SCAN, HSCAN ou SSCAN.
  • Evite usar comandos como KEYS ou SMEMBERS em conjuntos de dados grandes, pois eles podem congelar as operações Redis. Em vez dele, use comandos iterativos, como SCAN, SSCAN e HSCAN, para percorrer dados sem bloquear o sistema
  • Consulte a lista de comandos não suportados na documentação do OCI Cache para garantir a conformidade com os requisitos de compatibilidade para clusters com sharding.
  • Armazene dados relacionados em hashes em vez de várias chaves únicas para economizar memória e acelerar pesquisas em ambientes Redis.
  • Utilize pipelining para enviar vários comandos de uma só vez, reduzindo os tempos de ida e volta, e configure o pool de conexões para manter baixos tempos de resposta e minimizar a sobrecarga

Melhores práticas de backup e restauração

Garanta a durabilidade dos dados e o mínimo de tempo de inatividade no OCI Cache implementando estratégias robustas de backup e restauração, especialmente para cargas de trabalho de produção.

Backup

  • Trate backups gerenciados como snapshots RDB completos, não como snapshots incrementais ou progressivos.
  • Para programar backups, use um job cron ou outro scheduler externo para chamar a API de criação de backup.
  • Marque backups por ambiente ou data para organizá-los e facilitar o gerenciamento e a recuperação de backups específicos.
  • Crie backups durante períodos de baixo tráfego de gravação para reduzir o impacto operacional do processo de snapshot. Os backups do OCI Cache usam a mecânica de snapshot do Redis ou Valkey RDB. A criação de backup pode aumentar temporariamente o uso da CPU, a E/S de disco, a latência e a sobrecarga de memória.
  • Para clusters de produção com réplicas, prefira fazer backups de uma réplica quando possível, especialmente para conjuntos de dados maiores, sensíveis à latência ou com muita gravação. Essa abordagem reduz o impacto no nó primário enquanto ainda captura um instantâneo quase atual do conjunto de dados. Use um backup principal quando a atualização for a prioridade e a carga de trabalho puder tolerar o impacto extra no caminho de gravação.
  • Para clusters com sharding, a consistência de backup é por shard, não globalmente atômica. Se seu aplicativo precisar de consistência entre shards, deixe de gravar ou use um processo de transferência no nível do aplicativo antes de fazer o backup.
  • Monitore políticas de retenção para evitar a exclusão automática de backups críticos e garantir que os dados sejam retidos pela duração necessária de acordo com as necessidades organizacionais ou de conformidade. Retenção de 1 a 35 dias.
  • Somente uma criação de backup pode ser executada para um cluster de origem por vez. Algumas operações de cluster, como exclusão e atualização, são bloqueadas enquanto um backup está em andamento.

Restaurar

  • Você só pode restaurar dados de backups que ainda estão retidos e no estado ACTIVE.
  • Certifique-se de que o cluster de destino corresponda à configuração do cluster de origem, incluindo o modo do cluster, a contagem de shards (para clusters com sharding) e a memória por nó.
  • As restaurações só são suportadas entre versões compatíveis do mesmo mecanismo de cache. Restaurações cross-engine (Redis para Valkey ou Valkey para Redis) e combinações de versão não suportadas não são suportadas.
  • Testar restaurações em ambientes de não produção para verificar a integridade dos backups e ajudar as equipes a se familiarizarem com o processo de recuperação sem arriscar os dados de produção.
  • Quando você restaurar um backup em um novo cluster, valide o ambiente restaurado antes do cutover. Verifique a conectividade, os pontos finais, os usuários associados do OCI Cache, os controles de segurança de rede (como NSG ou listas de segurança) e o comportamento do aplicativo. Execute testes de fumaça e testes de leitura ou gravação representativos. Mantenha o cluster de origem disponível até que a validação seja concluída.

Importar e Exportar

Para fluxos de trabalho de importação e exportação, use arquivos RDB completos: um único objeto RDB para clusters não sharded ou um objeto RDB por shard para clusters sharded.

Melhores Práticas do Cliente para Clusters Não Fragmentados

Os clusters não fragmentados no OCI Cache operam com um nó principal e nós de réplica opcionais, replicando dados em todos os nós para garantir alta disponibilidade. Use essas práticas para maximizar a disponibilidade e o desempenho.

Configuração de alta disponibilidade

  • Implante clusters com pelo menos três nós (um principal e duas réplicas) para garantir alta disponibilidade. O OCI Cache distribui nós entre domínios de falha e domínios de disponibilidade para aumentar a resiliência contra falhas localizadas.
  • Operações de gravação direta no ponto final principal e usar pontos finais de réplica para operações de leitura a fim de distribuir a carga e melhorar a redundância.
  • Torne os aplicativos flexíveis especificando pontos finais em arquivos de configuração para suportar alterações de cluster por causa de failovers ou eventos de dimensionamento.

Melhores Práticas do Cliente para Replicação entre Regiões

Para clusters que participam da replicação entre regiões:

  • Configure aplicativos para que você possa redirecionar o tráfego de gravação para o cluster gravável no momento após um switchover ou recuperação de desastre.
  • Armazene os pontos finais para clusters regionais na configuração do aplicativo ou na descoberta de serviço, em vez de incorporar um único ponto final regional no código do aplicativo.
  • Teste a conectividade do aplicativo, a autenticação e o redirecionamento de tráfego na região secundária antes de confiar no cluster para recuperação de desastres.
  • Use leituras do cluster secundário apenas para cargas de trabalho que toleram consistência eventual.

Para obter detalhes sobre comportamento de replicação, requisitos operacionais, monitoramento e procedimentos de recuperação, consulte Replicação entre Regiões do Cache do OCI.

Melhores Práticas do Cliente para Clusters Fragmentados

Clusters fragmentados em dados de partição do OCI Cache em vários shards, cada um com um nó principal e réplicas opcionais para escalabilidade e desempenho. As práticas a seguir são específicas para clientes que fazem interface com clusters fragmentados, abordando os desafios exclusivos do gerenciamento de dados distribuídos.

Seleção de clientes compatíveis com cluster

Para obter desempenho e escalabilidade ideais, use bibliotecas clientes que suportem o modo de cluster e a resolução de nomes de host. Ao selecionar um cliente, priorize bibliotecas com suporte explícito para o modo de cluster Redis e resolução de nome de host, como Lettuce (versão 6.x ou posterior) ou Redisson (versão 3.36.0 ou posterior).

Além das bibliotecas mencionadas na matriz de compatibilidade, como Lettuce (versão 6.x ou posterior) e Redisson (versão 3.36.0 ou posterior), outras bibliotecas estão disponíveis para várias linguagens de programação que podem suportar clusters com sharding. Para obter uma lista abrangente de bibliotecas de clientes compatíveis, consulte a documentação da Valkey.

Certifique-se de que o cliente selecionado possa gerenciar dinamicamente alterações de topologia e mapeamento de slot sem intervenção manual. Esse recurso é essencial para operações de cluster contínuas.

Configuração de ponto final para resiliência

  • Configure aplicativos para especificar pontos finais principais para pelo menos três shards distintos (por exemplo, nós com nomes de host terminados em -1-1, -2-1 e -3-1) para garantir a conectividade se um shard ou nó estiver indisponível.
  • Torne os aplicativos flexíveis especificando pontos finais nos arquivos de configuração. Essa abordagem permite que o aplicativo se adapte a alterações de cluster resultantes de failovers ou eventos de dimensionamento.
  • Use o ponto final de descoberta, que não muda durante o tempo de vida do cluster.

Descoberta automática de topologia

  • Ative bibliotecas de clientes para recuperar e atualizar periodicamente informações de topologia de cluster na inicialização ou no runtime. Essa abordagem permite que os clientes se adaptem ao failover do nó ou ao redimensionamento do cluster sem atualizar as configurações.
  • Use o ponto final de descoberta, que permanece o mesmo durante toda a vida útil do cluster.

Suporte de escalabilidade e alta disponibilidade

  • Use bibliotecas clientes que suportem a reconexão automática e o resharding para manter os aplicativos em execução durante o redimensionamento do cluster (por exemplo, ao adicionar ou remover shards).
  • Configure cada shard com pelo menos duas e até quatro réplicas para suportar failover e alta disponibilidade. O OCI Cache distribui shards entre domínios de disponibilidade e domínios de falha para melhorar a resiliência.

Monitoramento de métricas de cluster fragmentado

  • Defina alertas para métricas críticas, incluindo utilização de memória (por exemplo, acima de 80% por 30 minutos) e disponibilidade de nós.
  • Monitore métricas no nível do nó para cada shard, como uso de memória, para decidir a melhor distribuição de dados entre shards e garantir um desempenho equilibrado do cluster.