Memorystore: Redis, Redis Cluster e Memcached

Um estudo comparativo para escolher cache, sessão ou datastore em memória sem deixar a fatura escolher por você.

Memorystore é o nome da família de serviços gerenciados em memória do Google Cloud. A comparação clássica envolve Memorystore for Redis, Memorystore for Redis Cluster e Memorystore for Memcached. A situação atual tem uma quarta opção importante: Memorystore for Valkey, recomendada pelo Google para novos projetos em muitos cenários.

1. O que está sendo comparado

“As três versões do Memorystore” é uma forma razoável de descrever a oferta que muita gente conheceu primeiro: Redis, Redis Cluster e Memcached. Porém, a página atual do Google Cloud lista quatro engines: Valkey, Redis Cluster, Redis e Memcached. Valkey é a adição mais recente e merece ser considerada, mesmo que a tabela principal deste estudo mantenha as três opções pedidas.

Também é importante separar dois eixos que costumam ser misturados:

• Engine e arquitetura: Redis, Redis Cluster ou Memcached.
• Topologia e disponibilidade: uma instância simples, réplicas, failover automático, shards e distribuição entre zonas.

2. Comparação rápida

Compatibilidade de protocolo não significa compatibilidade total de comandos, módulos, clientes, latência ou comportamento operacional. Migrar “porque fala Redis” ainda exige teste de carga e de comandos usados pela aplicação.

3. Memorystore for Redis

É a opção mais direta: uma instância Redis totalmente gerenciada, conectada por rede privada, com manutenção, monitoramento, patching e failover administrados pelo Google Cloud.

Basic e Standard

• Basic Tier: instância standalone. É a opção de menor custo, mas a falha da instância significa indisponibilidade até a recuperação.
• Standard Tier: replicação automática entre zonas e failover automático. A capacidade provisionada é cobrada por nó; réplicas adicionais de leitura elevam a conta.
• Read replicas: até cinco réplicas em tiers suportados, para escalar leitura. Não são uma desculpa para ignorar limites de escrita, hot keys ou desenho de dados.
• Capacidade: M1 a M5. O preço é por GiB provisionado, não pelo uso efetivo. Uma instância vazia continua cobrando.

4. Memorystore for Redis Cluster

Redis Cluster particiona o espaço de chaves em shards. Cada shard tem um nó primário e pode ter réplicas. O cliente precisa entender o protocolo de cluster e lidar corretamente com redirecionamentos, reconexão e mudanças de topologia.

Quando faz sentido

• O dataset ou throughput ultrapassa o que uma instância vertical consegue entregar.
• As chaves podem ser distribuídas de maneira razoavelmente uniforme.
• A aplicação já usa cliente Redis Cluster compatível e foi testada com MOVED/ASK, failover e resharding.
• O custo de vários nós é justificável pelo volume ou pela necessidade de escala horizontal.

O Cluster cobra por nó por hora. Um cluster com cinco shards e uma réplica por shard tem dez nós cobrados. A capacidade “de 100 GiB” não deve ser comparada diretamente com uma instância Redis M4: parte da capacidade é consumida por overhead, réplicas e reserva operacional.

Persistência, backups e rede

AOF acrescenta custo por GiB-hora. Backups acrescentam armazenamento, têm cobrança mínima de 24 horas e não são apagados automaticamente quando o cluster é excluído. O acesso usa Private Service Connect; tráfego entre zonas pode gerar cobrança de processamento de dados.

5. Memorystore for Memcached

Memcached é um cache distribuído simples: pares chave-valor, sem as estruturas, scripts, transações e semântica do Redis. A aplicação distribui as chaves entre nós, e deve aceitar que qualquer item desapareça.

• O preço combina vCPU e memória por nó, multiplicados pelo número de nós.
• Não há cobrança de ingress ou egress do serviço Memcached; outros serviços ainda podem cobrar tráfego.
• O tráfego deve permanecer dentro da região.
• Não é uma escolha adequada para sessão crítica sem estratégia de recuperação, locks ou dados que não podem ser perdidos.

6. A quarta opção: Memorystore for Valkey

Valkey é um fork open source do Redis, mantido pela comunidade Linux Foundation. O Google Cloud oferece Memorystore for Valkey com nós, réplicas, persistência AOF, backups, Private Service Connect e escala sem downtime. A documentação atual também informa SLA de 99,99% para Valkey e Redis Cluster.

Valkey não deve ser tratado como “Redis com outro nome” sem validação. Verifique comandos, módulos, versão do cliente, compatibilidade de serialização, comportamento de TTL e métricas. Ainda assim, para um sistema novo que precisa de protocolo e ecossistema semelhantes ao Redis, ele é o candidato natural a ser comparado com Redis Cluster.

Valkey é igual ao Redis Standard?

Não é 100% igual, mas é compatível o suficiente para muitas aplicações. Valkey nasceu como um fork open source do Redis e mantém o protocolo RESP, os tipos de dados, a maioria dos comandos usuais e o modelo mental de key-value. Para Laravel usando cache e sessões, a migração costuma ser pequena — principalmente quando o Valkey está em Cluster Mode Disabled.

“Compatível” não significa “internamente idêntico” nem “qualquer comando, módulo ou detalhe de versão é garantido”. É preciso validar a versão do engine, comandos suportados/bloqueados, módulos, scripts Lua, serialização, TTL, locks e comportamento de replicação. O que importa para a aplicação é a API observável, não apenas o fato de os dois projetos parecerem iguais por fora.

A conexão muda conforme o modo do Valkey

O nome do engine não determina sozinho o tipo de cliente. O modo do serviço é decisivo:

• Cluster Mode Disabled: a instância tem um único shard. Use cliente Redis/Valkey comum, endpoint primário para escrita e, quando necessário, endpoint reader para leitura. É o caminho mais parecido com Redis Standard.
• Cluster Mode Enabled: a instância é particionada em shards. Use cliente cluster-aware, conecte no discovery endpoint e permita que a biblioteca descubra os nós e os slots.

O Google informa que não é possível transformar uma instância criada em um modo no outro. Se começar com Cluster Mode Disabled e depois precisar de Cluster Mode Enabled, normalmente será necessário criar outra instância e migrar os dados/tráfego.

5A. Redis Cluster em profundidade

Esta é a parte que costuma gerar mais confusão. Um Redis Cluster não é simplesmente “uma máquina Redis com mais memória”. Ele é uma coleção de nós Redis que divide o espaço de chaves e coordena a topologia.

O que é um shard?

Um shard é uma partição do keyspace. Cada shard tem um nó primário e zero ou mais réplicas. O primário recebe as escritas daquela partição; as réplicas replicam o primário e podem atender leituras quando o cliente usa o modo apropriado.

O Redis Cluster divide as chaves em 16.384 hash slots. Para uma chave comum, a ideia é:

slot = CRC16(chave) % 16384

Os shards recebem conjuntos desses slots. Com três shards, por exemplo, um pode receber aproximadamente um terço dos slots, outro outro terço e assim por diante. O cliente cluster-aware mantém um mapa slot → nó e envia cada comando diretamente ao dono do slot.

Shards, réplicas e número de nós

A conta básica é:

nós primários = shards
nós de réplica = shards × réplicas_por_shard
nós totais     = shards × (1 + réplicas_por_shard)

O serviço suporta de 0 a 5 réplicas por nó primário. Para alta disponibilidade, a recomendação oficial é pelo menos uma réplica por shard. Réplica não aumenta a capacidade de escrita: ela aumenta principalmente redundância e capacidade de leitura, desde que o cliente use READONLY.

O que o número de shards importa?

• Memória total: cada shard adiciona a capacidade útil do tipo de nó escolhido.
• Escrita: comandos distribuídos entre vários primários podem aumentar a escrita agregada.
• CPU: cada nó traz seus próprios vCPUs; mais shards podem aumentar o processamento total.
• Disponibilidade: com réplicas, cada shard pode falhar e promover sua réplica sem derrubar o keyspace inteiro.
• Granularidade: muitos nós pequenos permitem crescer em passos menores, mas aumentam conexões, custo e complexidade.
• Distribuição: o ganho depende das chaves. Uma hot key ou um hash tag concentrado não escala apenas porque há mais shards.

Shard não é “pasta” nem “disco lógico”. É um primário Redis com um intervalo de slots. O serviço movimenta slots quando você escala, mas a aplicação precisa aceitar que endpoints de nós mudem.

Tipo de nó: memória útil, vCPU e conexões

Todos os shards do cluster usam o mesmo tipo de nó. A documentação oficial separa capacidade total da capacidade gravável padrão, porque parte da memória é reservada para overhead e operação.

Para um cluster de três shards usando redis-standard-small, a capacidade gravável padrão aproximada é 3 × 5,2 = 15,6 GB antes de considerar réplicas — réplicas não duplicam a capacidade gravável, mas duplicam o número de nós e o custo. Com uma réplica por shard, seriam seis nós.

O Google também informa que o tipo redis-shared-core-nano não tem SLA e que clusters sem HA ou consistentemente sobrecarregados em CPU/memória podem ficar fora da cobertura do SLA. “Cabe na memória” não é o mesmo que “está dimensionado”.

Disco, SSD, HDD e persistência

O Redis Cluster é um serviço in-memory. A capacidade principal cobrada é memória do nó, não um volume de disco que você escolhe como “SSD de 100 GB” ou “HDD de 100 GB”. A documentação do produto não oferece uma seleção de tipo de disco HDD/SSD para o keyspace operacional.

Há mecanismos de persistência, mas eles não transformam o serviço em um banco de dados de disco tradicional:

• AOF: registra operações para recuperação e tem cobrança adicional por GB-hora. O custo e a latência de escrita devem entrar no benchmark.
• Backups: são cópias gerenciadas com cobrança de armazenamento e mínimo de 24 horas. Excluir o cluster não exclui automaticamente seus backups.
• RDB: snapshots são usados em operações como adicionar réplicas. O processo fork/copy-on-write pode elevar temporariamente o uso de memória, em alguns padrões até perto do dobro do dataset do nó.

Resize: aumentar shards, trocar máquina e reduzir

Sim, é possível alterar a especificação depois da criação:

• Scale out/in horizontal: aumentar ou reduzir o número de shards. Isso altera a memória, CPU e distribuição dos slots.
• Scale up/down vertical: trocar o node type para um tipo maior ou menor.
• Réplicas: alterar a quantidade de réplicas por shard, de 0 a 5.

O comando documentado para shards é:

gcloud redis clusters update INSTANCE_ID \
  --region=southamerica-east1 \
  --shard-count=NOVO_NUMERO

Para mudar o tipo do nó:

gcloud redis clusters update INSTANCE_ID \
  --region=southamerica-east1 \
  --node-type=redis-highmem-medium

O scaling é desenhado para manter a instância disponível, mas não é invisível: ao mudar shards, o serviço rebalanceia slots e pode haver aumento de latência; em alta pressão de escrita, a operação pode falhar por falta de memória temporária ou ficar mais pesada. A recomendação é escalar em janela de baixa escrita e manter headroom.

Reduzir é mais perigoso que aumentar. A nova forma precisa comportar todas as chaves. A documentação recomenda dimensionar pelo menos 1,5× a memória efetivamente usada quando a intenção é não perder chaves durante scale-in. Chaves individuais muito grandes ou slots desequilibrados podem impedir a operação.

Existe indisponibilidade?

Durante manutenção programada: o serviço usa rollout gradual, create-before-destroy e failover coordenado. A proposta é zero downtime, desde que o cliente cluster-aware faça refresh de topologia, siga redirecionamentos e reconecte.

Durante failover inesperado: conexões podem ser resetadas. A eleição e promoção de uma réplica pode levar dezenas de segundos; o reparo do nó pode levar minutos. Escritas reconhecidas podem ser perdidas em uma falha inesperada, pois a replicação é assíncrona. O comando WAIT pode melhorar a segurança prática, mas não oferece semântica transacional mágica.

Durante outage de zona: em um cluster multi-zona com HA, o keyspace continua disponível para leitura e escrita, mas parte da capacidade de leitura pode cair enquanto réplicas são restauradas. Sem réplicas, a porção do keyspace alojada na zona afetada pode ficar indisponível e sofrer flush. Uma zona não é um detalhe cosmético; ela é parte do modelo de falha.

Throughput: como funciona

Throughput é o volume de operações e bytes que o cluster consegue processar com uma latência aceitável. Não existe um número mágico independente do workload. Ele depende de:

• vCPUs e tipo de nó;
• número de shards e distribuição das chaves;
• tamanho dos valores e quantidade de bytes por operação;
• comandos usados — GET é diferente de HGETALL, SCAN, script ou lista grande;
• conexões, pipelining, TLS, rede e distância entre PHP-FPM e Memorystore;
• replicação, snapshots, AOF e pressão de memória;
• hot keys e hash tags que concentram carga em um único shard.

Como referência, a documentação do Redis Cluster relata aproximadamente 120.000–130.000 operações por segundo por nó de 2 vCPU em benchmark memtier, na região us-central1, com dados de 1 KiB e latência em microssegundos. Isso é uma referência do teste do Google, não uma garantia para Laravel, PHP-FPM, TLS, payloads reais ou São Paulo.

Aumentar shards pode elevar throughput agregado porque adiciona primários e CPU. Aumentar réplicas pode elevar throughput de leitura, mas somente se o cliente realmente direcionar leituras para réplicas com READONLY. Nenhum dos dois resolve uma chave quente isolada.

7. Laravel, PHP-FPM e o problema dos inodes

O seu caso é um bom candidato para tirar cache e sessões do filesystem. Arquivos de cache e sessão consomem inodes mesmo quando ocupam pouco espaço; com vários workers PHP-FPM, expiração, deploys e sessões simultâneas, o filesystem pode acabar em inodes antes de acabar em GB.

O que mover para Redis/Valkey

• Cache Laravel: objetos e resultados temporários, sempre com TTL e política clara de invalidação.
• Sessions: estado de sessão compartilhado entre réplicas do PHP-FPM, sem arquivos locais e sem depender de sticky session.
• Queues/Horizon: possível, mas exige atenção especial a nomes de filas e multi-key commands em cluster.

Cache e sessão não têm necessariamente o mesmo perfil. Uma prática segura é separar namespaces e, quando possível, logical connections/instâncias ou ao menos prefixes. Evite colocar dados de negócio que precisam ser preservados exclusivamente no cache.

Cliente PHP e Redis Cluster

Para Redis Cluster/Valkey em modo cluster, o cliente precisa ser cluster-aware: descobrir nós, manter o mapa de slots, reagir a MOVED, ASK, CLUSTERDOWN e READONLY, e reconectar com backoff. Uma conexão simples apontando para um único IP não é arquitetura suficiente.

O Laravel documenta suporte a clustering nativo, com REDIS_CLUSTER=redis, e também distingue isso de client-side sharding do Predis. Client-side sharding não oferece o mesmo failover e é indicado principalmente para cache transitório. Para sessões, prefira clustering nativo e teste o cliente real usado pelo projeto.

CACHE_STORE=redis
SESSION_DRIVER=redis
REDIS_CLIENT=phpredis
REDIS_CLUSTER=redis
REDIS_HOST=discovery-endpoint-do-cluster
REDIS_PORT=6379
REDIS_PASSWORD=...
# Se TLS/IAM estiver habilitado, configure os parâmetros exigidos
# pelo cliente e pelo produto, não apenas REDIS_URL.

Os nomes exatos das variáveis e o formato TLS dependem da versão do Laravel, PhpRedis/Predis e do modo de autenticação. Não copie esse bloco para produção sem validar config/database.php, o cliente instalado e a documentação da versão do Laravel.

Login, IP, porta e biblioteca: o que muda?

Você continua fornecendo credenciais e um endpoint, mas o endpoint inicial não é necessariamente o endereço de todos os nós. O Memorystore for Redis Cluster fornece um discovery endpoint: IP/hostname e porta usados como seed. O cliente conecta nesse endpoint, descobre a topologia, recebe os endereços dos nós e passa a rotear as chaves para o shard correto.

Não é recomendado cadastrar manualmente todos os IPs dos nós como configuração fixa. Endpoints de nós podem mudar após manutenção ou resize; o discovery endpoint permanece estável e o cliente deve manter a topologia atualizada.

É possível usar como Redis normal?

Para operações simples, sim: GET, SET, DEL, TTL, hashes e a maioria das operações de uma chave continuam com a mesma semântica. Como arquitetura de conexão, não: não trate o Cluster como uma instância única escondida atrás de um único socket.

As principais diferenças práticas são:

• O cliente deve ser cluster-aware e manter o mapa de slots.
• Operações com várias chaves podem falhar se as chaves estiverem em shards diferentes.
• Use hash tags quando uma operação realmente exigir co-localização, sem transformar todas as chaves em um único hot shard.
• O cliente deve atualizar a topologia durante failover, resize e manutenção.
• Não conte com múltiplos logical databases como em uma instância Redis convencional; em Redis Cluster, o desenho usual é o DB 0 com prefixes/namespaces.
• Leituras em réplicas exigem suporte explícito a READONLY; apontar o Laravel para o cluster não faz todas as leituras migrarem automaticamente.

Laravel + PHP-FPM: é compatível?

Sim, é uma combinação possível. Laravel documenta clustering nativo e permite usar PhpRedis ou Predis. O ponto essencial é escolher o modo de cluster nativo — REDIS_CLUSTER=redis nas configurações usuais — e confirmar que a versão do cliente PHP realmente suporta a conexão cluster, autenticação, TLS e reconexão exigidos pelo Memorystore.

Para PHP-FPM, cada worker pode manter ou abrir conexões Redis. O endpoint de descoberta pode ser usado como seed, mas a biblioteca precisa aprender os nós. Configure timeouts, keepalive, retry com backoff e pools de conexão; não deixe cada request criar conexões ilimitadas. O problema deixa de ser inode e pode virar tempestade de conexões. A humanidade troca um incêndio por outro com admirável consistência.

Cache e sessão Laravel normalmente trabalham com uma chave por operação e são candidatos melhores que operações arbitrárias multi-key. Ainda assim, teste o pacote e o fluxo real: serialização da sessão, locks, regeneração de ID, expiração, concorrência de duas requisições da mesma sessão e comportamento quando um nó é promovido.

Filas Redis exigem atenção especial. A própria documentação do Laravel usa nomes com hash tag, como {default}, para manter estruturas relacionadas no mesmo slot. Horizon, filas, rate limiting e locks devem ser testados separadamente; “cache funcionou” não prova que toda a stack Laravel funcionará em Cluster.

Riscos específicos do seu cenário

• Session locking: duas requisições simultâneas da mesma sessão podem precisar de bloqueio; teste concorrência e timeout, especialmente com PHP-FPM.
• Payload grande: sessão serializada grande consome memória e pode causar latência, pressão de snapshot e problemas de movimentação de slot.
• Prefixos: use prefixos por aplicação/ambiente; não deixe staging apagar chaves de produção.
• TTL: sessões e cache devem expirar. Redis Cluster não é lixeira infinita; TTL ausente transforma cache em vazamento lógico.
• Conexões: cada worker PHP-FPM pode abrir conexões; dimensione pools e não crie uma conexão nova a cada request sem necessidade.
• Deploy: valide rolling restart, troca de endpoint, DNS, TLS e reconexão antes de remover o driver de arquivos.

8. Brasil: região, zonas e localização

Para Brasil, a região relevante é southamerica-east1, descrita pelo Google como São Paulo. As zonas documentadas são:

• southamerica-east1-a
• southamerica-east1-b
• southamerica-east1-c

Redis tradicional e Memcached são documentados como instâncias que vivem em zonas dentro de uma região. Para a API do Memorystore, o campo de localização mapeia para a região. Redis Cluster e Valkey são descritos como implantados dentro da região e distribuem nós entre zonas quando a topologia exige.

8. Preços verificados em São Paulo

Valores abaixo foram lidos nas tabelas oficiais com a região Sao Paulo (southamerica-east1) selecionada. Estão em USD, pay-as-you-go, sem impostos, créditos, suporte, rede do cliente ou conversão para BRL. Para o mensal, usei a aproximação de 730 horas. O Google cobra em incrementos de segundo, portanto a fatura real varia.

Redis: preço por GiB-hora em São Paulo

Redis: cenários de 10 a 200 GiB

Estes exemplos assumem uma única instância, sem read replicas. O valor de 200 GiB cai no M5: o preço por GiB muda conforme a faixa inteira provisionada.

O Standard custa mais porque inclui alta disponibilidade. Se você adicionar uma read replica, o preço do nó é multiplicado pelo número de nós. Por exemplo, primário + uma réplica dobra o componente de instância.

Redis Cluster: preço por nó em São Paulo

O mensal acima é por um nó. Um exemplo didático de topologia com três shards e uma réplica por shard teria seis nós: aproximadamente $991.19/mês usando o nó de 6.5 GB, ou $1,337.65/mês usando o de 13 GB, antes de AOF, backups e rede. Não confunda esse exemplo com uma recomendação mínima universal: a topologia correta depende da documentação e do workload.

Memcached: componentes de preço em São Paulo

Exemplo com 1 vCPU e a memória total em um nó, apenas para comparação matemática: 10 GiB ≈ $161.70/mês; 35 GiB ≈ $420.85/mês; 100 GiB ≈ $1,094.63/mês; 200 GiB ≈ $2,131.24/mês. Em produção, múltiplos nós mudam a disponibilidade, a distribuição e o custo.

9. O que não está nessas tabelas

• Impostos e câmbio: os preços oficiais são exibidos em USD; a fatura pode usar a moeda e os SKUs aplicáveis à conta.
• Rede: clientes em outra região podem gerar egress inter-região. Em outra zona, pode haver custo de tráfego ou processamento do serviço cliente/PSC.
• Réplicas: Redis Standard com read replicas cobra nós adicionais.
• Cluster: AOF, backups, réplicas por shard e PSC podem adicionar valores.
• Observabilidade: métricas e logs podem ter custos nos serviços correspondentes, além dos limites de inclusão.
• CUD: desconto de 20% em compromisso de 1 ano e 40% em 3 anos, conforme a documentação consultada. Só faça compromisso quando o consumo for previsível; comprar desconto para um cache que deveria ser desligado é uma forma sofisticada de pagar aluguel de um imóvel vazio.

10. Como escolher

11. Checklist antes de contratar

1. Defina se o dado é cache descartável, sessão, fila, lock ou fonte de verdade.
2. Meça tamanho real, overhead, pico de memória, taxa de escrita/leitura, latência e hot keys.
3. Escolha São Paulo (southamerica-east1) se o workload e os clientes principais estão no Brasil.
4. Teste failover, reconexão, timeouts, TLS, DNS e comportamento do cliente.
5. Para Cluster, teste distribuição de slots, multi-key commands e resharding.
6. Configure alertas para memória, conexões, evictions, latência, erro de comandos e custo.
7. Use Budget e alertas de faturamento. O Google Cloud não adivinha que você esqueceu uma instância experimental.
8. Recalcule com a calculadora oficial antes de fechar compromisso ou arquitetura.

12. Conclusão

Os três produtos pedidos não são apenas três tamanhos do mesmo serviço. Redis é a escolha convencional e equilibrada; Redis Cluster compra escala horizontal ao preço de mais complexidade; Memcached é um cache simples, mas tem data de encerramento. E a decisão atual precisa incluir Valkey, que o Google apresenta como destino de migração para Memcached e como uma alternativa moderna compatível com o ecossistema Redis.

Para um sistema novo rodando em São Paulo, eu começaria com um benchmark entre Redis Standard e Valkey. Só subiria para Cluster quando os limites de uma instância vertical fossem demonstrados por métricas reais. Memcached, em 2026, entra na lista de migração — não na lista de apostas.

Fontes e data de verificação

Preços e disponibilidade mudam. Esta página foi pesquisada e publicada em 30 de julho de 2026; confirme os valores no console e nas páginas oficiais antes de contratar.

• Visão geral do Memorystore — engines e posicionamento do produto.
• Memorystore for Redis overview — tiers e operação.
• Memorystore for Redis pricing — preços, réplicas e rede.
• Redis regions and zones — São Paulo e zonas.
• Memorystore for Redis Cluster documentation — shards, nós e operação.
• Cluster and node specification — capacidade útil, vCPU, conexões, limites e performance.
• High availability and replicas — réplicas, failover, zonas, perda de writes e impacto de outage.
• Scale instance capacity e About maintenance — resize e manutenção sem downtime planejado.
• Operational guidelines — limites operacionais e cobertura de SLA.
• Memorystore for Redis Cluster pricing — nós, AOF, backups e rede.
• Redis Cluster locations — regiões e zonas.
• Memorystore for Memcached pricing — vCPU, memória e rede.
• Memcached regions and zones — disponibilidade no Brasil.
• Memcached deprecations — datas de depreciação e shutdown.
• Memorystore for Valkey pricing e Valkey locations — a quarta opção atual.
• Valkey Cluster Mode Enabled e Disabled — diferenças de shards, clientes, multi-key e databases.
• Valkey client library code samples — PhpRedis, Predis, clientes Redis/Valkey e endpoints.
• Connect to Memorystore for Valkey — discovery endpoint, primary endpoint e reader endpoint.
• Redis Cluster specification — 16.384 hash slots e hash tags.
• Laravel Redis e Laravel Cache — clustering nativo, Predis/PhpRedis e drivers de cache.