Redis no Magento 2: cache, page cache e sessão em bancos separados

Por que separar não é frescura

Quando você manda o Magento limpar o cache inteiro, o backend do Redis não sai apagando chave por chave. O código do Cm_Cache_Backend_Redis, que a classe Magento\Framework\Cache\Backend\Redis estende, faz isso:

if ($mode == Zend_Cache::CLEANING_MODE_ALL) {
    return $this->_redis->flushDb();
}

Um FLUSHDB. O banco inteiro, com tudo que tiver dentro. Se as sessões moram no mesmo número de banco, elas vão junto: carrinho de quem estava comprando, admin logado, tudo.

O segundo motivo é operacional. Com bancos separados, você olha o consumo de cada coisa em um comando:

redis-cli INFO keyspace

E enxerga na hora se o page cache está engolindo a memória toda ou se são as sessões que não estão expirando. No mesmo banco, é um monte indistinguível de chaves.

Os três comandos

Rode com a loja em manutenção, porque o env.php muda no meio:

php bin/magento setup:config:set --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-port=6379 \
  --cache-backend-redis-db=0

php bin/magento setup:config:set --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 \
  --page-cache-redis-port=6379 \
  --page-cache-redis-db=1

php bin/magento setup:config:set --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-port=6379 \
  --session-save-redis-log-level=4 \
  --session-save-redis-db=2

Repare na pegadinha: cache e page cache usam --...-redis-server, e a sessão usa --session-save-redis-host. Nome diferente para a mesma coisa. Se você trocar um pelo outro, o comando morre com option does not exist — chato na hora, bom no fim, porque você descobre o erro em vez de achar que configurou.

Em Redis com senha, cada bloco tem o seu: --cache-backend-redis-password, --page-cache-redis-password e --session-save-redis-password.

O env.php que sai disso

Depois dos três comandos, o app/etc/env.php fica com dois blocos. O do cache:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => ['server' => '127.0.0.1', 'database' => '0', 'port' => '6379'],
        ],
        'page_cache' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => ['server' => '127.0.0.1', 'port' => '6379', 'database' => '1', 'compress_data' => '0'],
        ],
    ],
],

E o da sessão, que vem com uma lista bem maior de opções — timeout, compression_library, max_concurrency, disable_locking, max_lifetime, entre outras:

'session' => [
    'save' => 'redis',
    'redis' => ['host' => '127.0.0.1', 'port' => '6379', 'database' => '2', 'log_level' => '4'],
],

Duas coisas que eu confiro nesse bloco. O compress_data do page cache vem 0 no exemplo da Adobe: comprimir página inteira gasta CPU do PHP para economizar memória do Redis, e em servidor com memória sobrando não compensa. E o disable_locking da sessão: deixar em 0 mantém o lock, que é o certo para não corromper carrinho com requisição paralela do checkout.

Conferido o arquivo, confirme que cada banco recebeu o que devia:

redis-cli -n 0 DBSIZE
redis-cli -n 1 DBSIZE
redis-cli -n 2 DBSIZE

Os tropeços que sobram

Quatro coisas que aparecem sempre depois que essa configuração vai para produção:

• Redis Cluster só tem o banco 0. Se a sua infra usa cluster — vários serviços gerenciados sobem assim por padrão — a separação por número de banco simplesmente não existe. Nesse caso, o jeito é instância separada para sessão, não banco separado.
• Separar banco não separa memória. O maxmemory-policy é do servidor inteiro, não de cada banco. Com política de despejo agressiva, o Redis pode evictar chave de sessão para caber mais cache. Se as sessões importam — e importam —, instância própria para elas é o certo.
• Varnish na frente muda o volume. Com o Varnish guardando as páginas, o banco 1 fica bem mais vazio. Configure mesmo assim: o Magento continua usando o cache type page_cache.
• Valkey no lugar do Redis. A tabela de requisitos da Adobe já lista Valkey nas versões atuais: 8.1 no 2.4.8 e 9 no 2.4.9. Como o Valkey nasceu como fork do Redis e fala o mesmo protocolo, os comandos acima continuam iguais, com os mesmos flags de nome redis.

Terminou? Limpe e teste de verdade: php bin/magento cache:flush, e depois confira que a sua sessão de admin continua de pé. Se você foi deslogado, alguma coisa ainda está no banco errado.