Adobe Commerce 2.4.9 Valkey Redis não é apenas uma discussão sobre trocar o nome de um serviço de cache. A mudança afeta requisitos de infraestrutura, comandos de configuração, cache padrão, cache de página e procedimentos de deploy. Uma migração incompleta pode aparecer como lentidão, páginas desatualizadas, falhas intermitentes no Admin ou comportamento inesperado no checkout.
Antes de substituir o serviço em produção, a equipe deve confirmar a versão efetiva da plataforma, inventariar todos os usos do Redis e homologar a configuração do Valkey com tráfego representativo. As nove verificações abaixo ajudam a executar essa transição sem apagar evidências nem misturar problemas de aplicação e infraestrutura.
Adobe Commerce 2.4.9 Valkey Redis: o que mudou no suporte?
A documentação da Adobe informa que o Redis não é compatível com a configuração de cache do Adobe Commerce 2.4.9. A restrição também alcança patches posteriores a 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 e 2.4.8-p4. Nessas versões, o Valkey deve ser utilizado onde o Redis deixou de ser suportado, conforme as práticas recomendadas oficiais para Valkey e Redis.
Isso exige atenção até de lojas que não pretendem adotar imediatamente a linha 2.4.9. A aplicação de um patch em uma linha anterior pode alterar a combinação oficialmente aceita. Portanto, a decisão deve considerar o número completo da versão, incluindo o nível de patch, e não somente “2.4.7” ou “2.4.8”.
1. Confirme a versão instalada e o pacote do projeto
Não use apenas o rodapé do Admin como referência. Em uma cópia controlada do ambiente, registre a saída dos comandos abaixo:
bin/magento --version
composer show magento/product-community-edition
composer show magento/product-enterprise-editionUm dos dois últimos pacotes pode não existir, dependendo da edição. Consulte também o composer.lock e o histórico do último deploy. Se o projeto estiver planejando um upgrade mais amplo, revise em conjunto os demais requisitos do Adobe Commerce 2.4.9.
2. Mapeie onde o Redis é utilizado atualmente
Redis pode aparecer em mais de uma função. Faça um inventário separado de cache padrão, cache de página, sessões, filas ou recursos utilizados por extensões. Não presuma que trocar um endereço no app/etc/env.php migra automaticamente todos os consumidores.
Revise o arquivo sem copiar senhas ou credenciais para chamados e documentos públicos. Em ambientes gerenciados, examine também variáveis, relacionamentos de serviços, templates de infraestrutura e arquivos usados pelo pipeline. Registre host, porta, banco lógico, autenticação e finalidade de cada conexão, mas mantenha dados secretos em um cofre apropriado.
3. Separe cache padrão, cache de página e sessões
Uma loja pode manter esses componentes em conexões ou bancos lógicos distintos. Essa separação reduz o risco de uma limpeza de cache atingir sessões, mas somente funciona se a configuração estiver coerente em todos os nós da aplicação.
Crie uma tabela simples com quatro colunas: consumidor, configuração atual, destino no Valkey e teste de aceitação. Inclua pelo menos cache padrão, full page cache, sessões e qualquer módulo que abra conexão diretamente. Se a loja utiliza Varnish, lembre que ele não elimina o cache interno da aplicação; os dois precisam ser avaliados separadamente. Consulte também o roteiro para diagnosticar páginas antigas no Varnish.
4. Use os parâmetros próprios do Valkey
A partir do Adobe Commerce 2.4.9, o Valkey substitui oficialmente o Redis nas ferramentas de linha de comando, e a configuração do cache padrão e do cache de página deve utilizar os parâmetros destinados ao Valkey. Os nomes e exemplos aplicáveis estão no guia oficial para configurar Valkey no cache padrão e no cache de página.
Evite copiar um comando de outro projeto sem verificar a versão da aplicação. Antes de mudar o ambiente, consulte a ajuda disponível no próprio pacote instalado e compare-a com a documentação correspondente:
bin/magento setup:config:set --helpPrepare a alteração no repositório ou mecanismo oficial de configuração do ambiente. Uma edição manual emergencial do env.php pode ser sobrescrita no próximo deploy e criar diferenças entre os servidores.
5. Revise a implementação do cache L2
Para Adobe Commerce 2.4.9 e versões posteriores, a implementação moderna de cache L2 symfony_l2 é suportada somente com Valkey. A configuração legada RemoteSynchronizedCache não é suportada nesse cenário, segundo as recomendações de configuração publicadas pela Adobe.
Pesquise referências à implementação legada nos arquivos de configuração, automações de deploy e documentação interna. Se ela existir, trate a mudança como uma etapa explícita da migração, com plano de reversão e medição de comportamento, em vez de apenas substituir o endpoint.
6. Valide conectividade sem expor credenciais
O teste deve partir dos mesmos segmentos de rede usados pelos nós web, consumidores e tarefas cron. Confirme resolução de nome, porta, regras de firewall, autenticação, criptografia quando aplicável e limites de conexão. Um teste realizado somente a partir do computador de um administrador não demonstra que o PHP-FPM ou os workers alcançam o serviço.
Verifique também se todos os nós apontam para o destino planejado. Durante uma implantação gradual, parte da frota pode continuar usando Redis enquanto outra parte grava no Valkey, criando resultados inconsistentes difíceis de reproduzir.
7. Planeje a virada e a reversão
Defina janela, responsáveis, sequência de deploy e critérios de interrupção. Preserve uma cópia segura da configuração anterior, mas não conte com o reaproveitamento indiscriminado do conteúdo do cache como estratégia de reversão. Cache pode ser reconstruído; pedidos, sessões e dados de negócio exigem tratamento diferente.
Antes da virada, registre métricas básicas: tempo de resposta, erros da aplicação, conexões, consumo de memória, evicções e latência do serviço. Sem uma linha de base, a equipe pode atribuir ao Valkey uma lentidão causada por indexação, banco de dados ou integração externa. Se a loja já estiver lenta, use um diagnóstico por camadas antes de trocar a infraestrutura, como explicado no guia sobre gargalos de performance no Magento 2.
8. Homologue catálogo, Admin, sessão e checkout
Limitar o teste à página inicial é insuficiente. Em homologação, percorra páginas CMS, categorias, produtos simples e configuráveis, busca, login, Admin e atualização de conteúdo. Confirme se alterações de preço, estoque e blocos aparecem no momento esperado.
No checkout brasileiro, teste cliente visitante e autenticado, CEP, frete, cupom, PIX, cartão, antifraude e retorno do pagamento conforme os recursos realmente utilizados pela loja. Adicione um item, navegue por várias páginas, faça login e confirme que o carrinho permanece íntegro. Monitore logs da aplicação e da infraestrutura durante todo o fluxo.
9. Observe o ambiente após o deploy
Após a liberação, acompanhe erros de conexão, tempo de resposta, taxa de acerto do cache, memória, conexões e reinicializações do serviço. Compare os dados com a linha de base e separe falhas concentradas em uma rota de problemas que atingem toda a loja.
Não responda a qualquer anomalia limpando todos os caches ou reiniciando a frota. Registre horário, URL, nó, usuário e mensagem de erro antes da intervenção. Essa evidência ajuda a distinguir configuração incorreta, indisponibilidade de rede, extensão incompatível e capacidade insuficiente.
Conclusão
A transição Adobe Commerce 2.4.9 Valkey Redis precisa ser tratada como uma mudança de plataforma, não como uma simples renomeação de serviço. Confirme a versão completa, mapeie cada consumidor, utilize os parâmetros corretos, revise o cache L2 e valide catálogo, sessão e checkout antes de liberar a produção.
Se sua equipe precisa revisar a arquitetura de cache ou preparar o upgrade com menor risco operacional, o Suporte Magento pode auxiliar no diagnóstico, planejamento e homologação do ambiente.
Perguntas frequentes sobre Valkey no Adobe Commerce
O Redis ainda é suportado no Adobe Commerce 2.4.9?
Não para a configuração de cache documentada pela Adobe Commerce 2.4.9. A restrição também se aplica a patches posteriores a 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 e 2.4.8-p4. A versão completa da instalação deve ser conferida antes da mudança.
Qual é a diferença prática entre Redis e Valkey nessa migração?
Para a operação da loja, a diferença principal é o suporte oficial e a configuração exigida pela versão da plataforma. Não basta manter parâmetros antigos e trocar somente o servidor: comandos, backend de cache e implementação L2 precisam ser revisados.
É necessário alterar o app/etc/env.php?
A configuração efetiva pode resultar em mudanças no app/etc/env.php, mas elas devem ser produzidas pelo procedimento adequado ao ambiente. Em projetos com pipeline ou infraestrutura gerenciada, alterações manuais podem ser sobrescritas e causar divergência entre nós.
Como testar o checkout depois de migrar para Valkey?
Teste carrinho, login, sessão, endereço, frete, cupom, PIX, cartão, antifraude e criação do pedido. Execute os fluxos como visitante e cliente autenticado enquanto monitora logs, conexões, memória e latência.
Magento Open Source também exige atenção ao Valkey?
A decisão deve considerar a edição, a versão completa, o nível de patch e a documentação correspondente ao pacote instalado. Não aplique automaticamente uma configuração de Adobe Commerce a outra combinação sem confirmar os requisitos do projeto.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
