Redis 8: Novidades e decisões de atualização para prestadores de serviços de alojamento

Entender bem o Redis 8

Redis 8 refere-se a uma geração de plataforma, não necessariamente a uma versão-alvo adequada para todas as operações. O Redis 8.0 foi a versão inicial lançada em maio de 2025. No entanto, para uma atualização do Redis, os fornecedores de alojamento têm de selecionar a versão secundária e a versão de correção a utilizar, o seu estado de suporte, bem como a compatibilidade com o seu próprio modelo de serviço.

A 30 de setembro de 2026, o sistema de gestão de versões do Redis apresenta o Redis 8.10 como a versão mais recente listada Versão padrão do GA da linha 8. Também estão listadas como GA as versões 8.4, 8.6 e 8.8. No entanto, a versão menor mais recente não constitui uma meta geral: o estado do patch, as funcionalidades utilizadas, a compatibilidade do cliente e a janela de manutenção prevista continuam a fazer parte dos critérios de seleção.

O Redis 8.0 é uma versão padrão cujo suporte a correções de segurança e de erros críticos termina, de acordo com a gestão de versões, a 1 de dezembro de 2026. O Redis 8.2, por outro lado, é considerado como Liberação alargada até 1 de setembro de 2030. No caso das ofertas de gestão conservadora, este período de suporte definido pode, por isso, adequar-se melhor ao ciclo de vida do produto; no entanto, não substitui a verificação de um nível de correções adequado.

O Redis Open Source 8 é a linha de servidores que inclui as funcionalidades de código aberto abordadas neste artigo. Distinta desta, existe a Redis Software: uma linha de produtos comerciais destinada a outros modelos de operação em cluster e empresarial. O facto de o Redis Software 8.0.x suportar várias versões da base de dados Redis não significa que as suas funcionalidades adicionais sejam características de uma instalação normal do Redis de código aberto.

O Valkey também não é uma variante do Redis 8, mas sim um fork independente, com desenvolvimento próprio e decisões próprias em matéria de compatibilidade e licença. Quem estiver a avaliar alternativas deve, por isso, analisar separadamente o comportamento do protocolo, o conjunto de funcionalidades, o percurso de migração e as condições de utilização. Uma mudança de versão dentro do Redis não é equivalente a uma mudança para um fork.

Componentes integrados da pilha no Redis 8

A alteração mais marcante do Redis 8 é a distribuição integrada componentes do Redis Stack até à data. O Redis Search, o JSON, o Time Series, bem como estruturas de dados probabilísticas como os filtros Bloom e Cuckoo, o Count-Min Sketch, o Top-K e o t-digest fazem parte do Redis Open Source 8. Na versão inicial, o Redis 8.0.0, o Vector Set também foi incluído, mas foi explicitamente identificado como uma versão prévia.

Para os fornecedores, isto simplifica a manutenção do produto, caso um serviço necessite efetivamente de dados de documentos, pesquisa ou séries temporais. Os componentes são versionados e fornecidos em conjunto com o Redis. Desta forma, elimina-se a necessidade de sincronizar os módulos da pilha instalados de forma independente com a versão do servidor; ao mesmo tempo, um único módulo integrado não pode ser atualizado separadamente da versão do Redis.

Os conjuntos de vetores são descritos na documentação atual do Redis como um tipo de dados próprio, com comandos específicos, desde o Redis 8.0. No entanto, a designação «Preview» da versão inicial indica que um serviço de alojamento não deve concluir, apenas com base no Redis 8.0.0, que este se encontra em condições de produção sem restrições. São determinantes as notas de lançamento, o estado das correções e a verificação do funcionamento da versão-alvo concretamente escolhida.

Uma oferta gerida para catálogos de produtos pode disponibilizar documentos JSON e índices de pesquisa na mesma instalação do Redis 8. Para telemetria, o Time Series pode fornecer um modelo de dados adequado. As estruturas probabilísticas são úteis quando as aplicações podem trabalhar com aproximações controladas, por exemplo, para identificar elementos presumivelmente já conhecidos antes de uma consulta mais dispendiosa ao backend.

No entanto, no caso de um cache de objetos clássico, isso não implica a necessidade de novos modelos de dados. As aplicações WordPress, de lojas online ou PHP utilizam frequentemente cadeias de caracteres, hashes e tempos de validade. A integração pode facilitar a padronização da versão do Redis disponibilizada, mas não justifica a utilização de índices de pesquisa, documentos JSON ou dados vetoriais sem requisitos concretos da aplicação e sem um planeamento de capacidade.

Por isso, o limite de serviço é determinante: um sistema simplificado Servidor de cache requer, acima de tudo, uma gestão de memória previsível e acessos claramente delimitados. Um serviço de dados ou de pesquisa necessita, além disso, de um modelo de dados, da criação de índices, de um comportamento de consulta e de um conceito operacional. O Redis 8 disponibiliza os componentes necessários, mas não toma essa decisão arquitetónica por si.

A gestão conjunta de versões reduz, assim, sobretudo a complexidade na gestão de lançamentos. Não substitui a verificação de se os clientes suportam os comandos utilizados ou se uma implementação existente da pilha Redis utiliza configurações e índices específicos. Antes de uma migração, essas dependências devem ser incluídas no levantamento técnico da situação atual.

Avaliar os benefícios consoante o caso de utilização do Redis

O facto de o Redis 8 trazer um valor acrescentado prático depende mais do caso de utilização do que do número da versão. Para o cache de objetos, o armazenamento de sessões, as filas, a limitação de taxa e o cache geral da aplicação, as funcionalidades básicas do Redis continuam a ser determinantes. Os novos tipos de dados são opcionais neste contexto; a aplicação não precisa de os compreender nem de os utilizar para funcionar com o Redis 8.

• Cache clássico e sessões: os benefícios advêm sobretudo de um servidor bem mantido e de um funcionamento controlado; funções de pesquisa ou vetoriais seriam, na maioria dos casos, uma complexidade adicional e não aproveitada.
• Filas e limitação de taxa: as estruturas de dados do Redis e as operações atómicas continuam a ser fundamentais. As estruturas probabilísticas podem complementar casos específicos, mas não fornecem uma contagem exata geral.
• Pesquisa de produtos e dados de documentos: o JSON e o Redis Search podem apoiar uma abordagem de serviço integrado, sempre que o modelo de dados, os índices e as consultas forem efetivamente necessários.
• Telemetria e análises aproximativas: as séries temporais, bem como os esboços e os filtros, são adequados para valores de medição baseados no tempo ou para métodos de aproximação, desde que as aplicações tenham em conta os limites dos seus resultados.

No caso de um Object Cache normal, o planeamento operacional deve, por isso, Limites de armazenamento e dar prioridade aos tempos de expiração. Sem um limite fixo, um espaço de chaves em crescimento pode afetar outros serviços no anfitrião. A estratégia de evicção adequada depende do facto de nessa mesma instância se encontrarem apenas entradas de cache dispensáveis ou também dados relevantes do ponto de vista técnico; na medida do possível, estes dois tipos não devem ser misturados.

Para todos os grupos de casos, a restrição de rede é mais fundamental do que um novo comando. O Redis recomenda que as instâncias não sejam diretamente acessíveis na Internet e que a porta do Redis seja restrita a clientes de confiança. O TLS pode proteger as ligações dos clientes, a replicação e o bus do cluster; as ACLs limitam adicionalmente os comandos e os espaços de chaves acessíveis.

Por isso, uma atualização do Redis justifica-se, no caso de caches puros, sobretudo como uma modernização planeada da versão, da manutenção e do modelo operacional. No caso de aplicações de pesquisa, telemetria ou vetoriais, o leque de funcionalidades integrado pode ser adicionalmente relevante. Em ambos os casos, a questão permanece a mesma: que dados, carga e limites de segurança deve esta instância individual suportar efetivamente?

Novas funcionalidades e requisitos de recursos

O Redis Open Source 8 reúne funcionalidades que, anteriormente, eram normalmente disponibilizadas através do Redis Stack e dos seus componentes: documentos JSON, Redis Search, séries temporais e estruturas de dados probabilísticas. A isto acrescentam-se os conjuntos de vetores (Vector Sets), que foram incluídos na versão inicial do Redis 8.0.0 como pré-visualização. No que diz respeito às ofertas de alojamento, a distribuição integrada reduz o número de componentes que têm de ser mantidos separadamente.

No entanto, os benefícios só se concretizam a partir de um modelo de serviço específico. O JSON e o Redis Search, por exemplo, são adequados para catálogos de produtos ou pesquisas de documentos, enquanto o Time Series é adequado para valores de medição baseados no tempo. Por outro lado, um cache de objetos clássico muitas vezes não necessita nem de consultas a documentos nem de índices: para ele, a quota de memória, os tempos de expiração e um comportamento de evicção adequado continuam a ser decisões operacionais fundamentais.

No caso dos filtros Bloom e Cuckoo, do Count-Min Sketch, do Top-K e do t-digest, o limite técnico é particularmente importante: estes suportam estimativas de probabilidade, frequência, classificação ou quantis, mas não armazenam necessariamente todas as informações individuais com exatidão. Assim, podem aliviar a carga das pesquisas no backend ou de análises extensas; no entanto, não são adequados para valores individuais relevantes para a faturação ou que devam ser à prova de auditoria sem uma verificação adicional.

Por outro lado, a limitação de taxa clássica requer um método deliberadamente escolhido, como contadores, «token bucket» ou «sliding window», com estruturas Redis adequadas e processos atómicos. As estruturas probabilísticas podem, no máximo, complementar um caso especial especialmente concebido e baseado em aproximações. Não constituem um substituto geral para uma lógica de limitação exata.

Os conjuntos de vetores respondem a uma necessidade diferente. O Redis armazena representações vetoriais e procura elementos semelhantes; opcionalmente, podem ser incluídos atributos JSON para filtragem. O Redis não gera as próprias representações (embeddings). Por isso, as aplicações têm de as obter a partir de um modelo ou de um serviço externo, antes que a pesquisa semântica, as recomendações ou a recuperação de dados possam basear-se nelas.

Dimensionar conjuntos de vetores de forma realista

A Conjunto de vetores destina-se a questões como „produtos semelhantes“, „passagens de documentos correspondentes“ ou pesquisa semântica. A pesquisa geral de texto completo e a semelhança vetorial são, neste contexto, abordagens diferentes: o Redis Search pode abranger campos de texto e consultas, enquanto os Vector Sets determinam semelhanças entre vetores. Um cache da Web normal não obtém, por si só, qualquer valor acrescentado funcional através dos vetores.

O planeamento funcional deve manter-se específico para cada versão. O Redis 8.0.0 introduziu os Vector Sets em pré-visualização. A documentação atual descreve a estrutura de dados e os seus comandos, mas não atribui retroativamente um estatuto de total prontidão para produção à versão inicial. Por isso, antes da implementação, é necessário verificar as notas de lançamento e o comportamento da versão específica do Redis selecionada com os clientes necessários.

Para o primeiro planeamento de capacidade, a documentação indica, para 300 dimensões, um valor calculado de 1 200 bytes por vetor FP32 ou 300 bytes por vetor Q8. Com 100 000 vetores FP32, isso resulta em cerca de 120 MB de dados brutos; com Q8, cerca de 30 MB. Este cálculo refere-se exclusivamente à componente vetorial e não constitui uma garantia quanto aos requisitos de memória de uma instância em produção.

Além disso, a estrutura de pesquisa baseada em HNSW necessita de memória para as ligações do grafo. Acrescem-se as etiquetas e os atributos opcionais; da mesma forma, a fragmentação, as réplicas e os dados persistentes podem alterar as necessidades reais de recursos. Quem planeia uma implementação de alta disponibilidade não deve, portanto, equiparar simplesmente o tamanho bruto à memória disponível de um único nó.

A escolha entre FP32 e Q8 é, portanto, uma decisão relacionada com a qualidade e os recursos, e não uma otimização universal. É aconselhável criar um ambiente de teste com vetores, atributos de filtro e padrões de consulta representativos. Nesse ambiente, é possível avaliar a utilização da memória, os tempos de resposta e a qualidade dos resultados para o caso específico do cliente, antes de se definirem capacidades ou limites de clientes.

Preparar de forma controlada uma atualização do Redis

A Atualização do Redis A migração do Redis Open Source 7.x ou do Redis Stack para o Redis 8 deve ser realizada como uma mudança planeada, e não como uma atualização de pacote não acompanhada num sistema em produção. Primeiro, deve ser selecionada uma versão de destino específica, incluindo o período de suporte. Em seguida, uma instância de teste reproduz, da forma mais realista possível, o modelo de dados, a persistência, os clientes e as funções de acesso relevantes.

Antes da intervenção, a equipa deve esclarecer quais os ficheiros de persistência e as cópias de segurança que pertencem efetivamente à instância e como decorre a recuperação. O Redis refere, para o processo de atualização, a realização de cópias de segurança, testes e verificações subsequentes da versão, do acesso aos dados e das ligações dos clientes. Por conseguinte, um rollback documentado requer não só os pacotes antigos, mas também um caminho de retorno rastreável para os dados e a configuração.

Para uma análise inicial, convém consultar as informações relativas ao servidor e à persistência, bem como o caminho de dados configurado. Executa as seguintes consultas com uma conta com as devidas autorizações e guarda os resultados fora de tickets ou registos acessíveis ao público, caso contenham detalhes da infraestrutura.

redis-cli INFO server
redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli INFO server | grep redis_version

O comando SAVE É mencionado na documentação de atualização para um snapshot, mas não é um comando padrão sem consequências: sendo um processo síncrono, pode afetar o funcionamento do sistema, dependendo do volume de dados e da carga. Planeie as cópias de segurança e as janelas de manutenção com base no modelo de persistência utilizado. Para processos de preparação e reversão reproduzíveis, é útil um fluxo de trabalho com controlo de versões e ambientes claramente separados; o artigo a seguir aborda este tema Alojamento Web com suporte Git.

Verificar os ACLs e a separação de clientes

Um serviço Redis gerido começa com um limite de rede bem definido: a porta do Redis não deve estar acessível ao público, mas sim aberta exclusivamente a servidores de aplicações de confiança ou a redes de gestão. O TLS protege as ligações dos clientes, a replicação e o barramento do cluster durante a transmissão. Estas medidas complementam-se mutuamente; o TLS não substitui nem um firewall restritivo nem um controlo de acesso rigoroso no servidor.

Para vários clientes ou aplicações, é Separação de clientes mais do que um número de base de dados distinto. As instâncias próprias são as mais fáceis de delimitar. Se os clientes partilharem uma instância, as ACLs devem limitar os comandos e os espaços de chaves permitidos; além disso, os limites de armazenamento impedem que uma única carga de trabalho esgote a capacidade destinada a outros clientes. Os prefixos de chaves são um elemento da regra, mas não constituem uma barreira de segurança independente.

Na atualização do Redis para a versão 8, a verificação da ACL requer especial atenção. Os comandos dos componentes agora integrados correspondem a categorias existentes, tais como @read e @write atribuída. Uma autorização que, até ao momento, tenha sido formulada de forma ampla pode, por isso, permitir adicionalmente, por exemplo, consultas de pesquisa ou acessos de escrita em JSON. Uma ACL sintaticamente válida não significa, portanto, automaticamente que continue a ter autorizações mínimas do ponto de vista funcional.

Na prática, recomenda-se realizar uma comparação de ACL: as regras exportadas da instância anterior são comparadas com as regras previstas no Redis 8. Para cada função do cliente, a equipa deve verificar quais os comandos que são efetivamente necessários, quais os prefixos de chaves que permanecem acessíveis e se uma categoria recém-herdada inclui direitos indesejáveis. O que é decisivo é a comparação das autorizações efetivas, e não apenas o texto das linhas da configuração.

Em seguida, são criados testes específicos para cada função: um cliente de cache Web, por exemplo, pode ler e escrever as chaves de cache que lhe estão destinadas, mas não pode utilizar prefixos alheios nem comandos de administração. Para aplicações de pesquisa ou JSON, aplicam-se testes específicos. Essas verificações baseadas em funções tornam as alterações rastreáveis, sem impor um modelo de ACL universal para diferentes arquiteturas de clientes.

Funcionamento, monitorização e resolução de problemas

Para o funcionamento, recomenda-se uma monitorização separada da ocupação da memória, das evicções, das latências, das ligações dos clientes, da persistência e da replicação. Estes valores refletem diferentes pontos de estrangulamento e, por isso, devem ser avaliados em conjunto com o respetivo modelo de serviço. Um aumento das evicções não indica automaticamente uma falha do Redis, mas constitui um motivo para verificar os limites de memória, os tempos de expiração e o modelo de dados.

Os índices de pesquisa e os conjuntos de vetores não devem ser incluídos num conjunto de valores de medição juntamente com uma cache de objetos comum. Para além do conjunto de chaves, este inclui memórias de índices e de grafos, atributos, bem como a respetiva carga de consultas. No caso dos vetores, às necessidades de dados brutos acrescentam-se rótulos, ligações, fragmentação, replicação e persistência. Dimensionar uma instância apenas com base nos valores dos vetores subestima, portanto, as necessidades reais de recursos.

O Redis 8 introduz uma nova implementação de threads de E/S; a configuração io-threads No entanto, não se trata de um «botão» universal para melhorar o desempenho. Mesmo as melhorias na replicação não constituem uma garantia geral de débito. Os núcleos da CPU, a rede, a persistência, o conjunto de comandos e o comportamento do cliente são fatores que determinam se uma alteração é benéfica. Por isso, as variantes de configuração devem ser testadas num ambiente de staging próximo da produção, com o seu próprio perfil de carga.

Após uma atualização, os problemas não detetados nos clientes são frequentemente mais reveladores do que as meras métricas do servidor. A equipa deve verificar as ligações, a autenticação, os comandos utilizados e as respostas de erro com as bibliotecas de cliente reais. Igualmente importante é um procedimento de recuperação bem treinado: uma cópia de segurança existente só reduz o risco quando se verifica que os dados e a aplicação funcionam corretamente após a restauração.

Para a emissão de alertas, é útil definir valores-limite distintos consoante a classe de serviço. Uma cache pode tolerar deliberadamente as evicções, enquanto estas podem implicar perda de dados no caso de sessões ou filas. As cargas de trabalho de pesquisa e vetoriais requerem, além disso, uma monitorização da evolução da memória e das latências das consultas. O artigo apresenta informações de fundo sobre observabilidade, escalabilidade e planeamento de recursos Tendências de alojamento em 2026.

Para a deteção de erros, as alterações ao modelo de dados, à versão do cliente, ao limite de memória e à configuração de persistência devem ser associadas cronologicamente às métricas. Desta forma, é possível distinguir se um pico de latência coincide, por exemplo, com uma nova carga de pesquisas, um aumento no número de ligações ou uma fase de persistência. Esta associação é mais fiável do que a suposição de que qualquer anomalia seja consequência da atualização do Redis.

Recuperação no âmbito de uma auditoria fiscal Uma cópia de segurança, por si só, não garante a capacidade de reinício. O guia de atualização recomenda que se pratique de forma controlada a realização de cópias de segurança e a atualização e que, posteriormente, se verifique o acesso aos dados e as ligações dos clientes.

Escolher a licença e o produto

No Redis 8, a escolha da licença é uma decisão relacionada com o produto, não apenas um ponto nas instruções de instalação. O Redis Open Source pode ser utilizado sob as licenças RSALv2, SSPLv1 ou AGPLv3. A opção mais adequada para uma instância interna, um ambiente de cliente ou um produto Managed Redis disponibilizado publicamente depende da forma concreta de implementação e das obrigações a ela associadas.

A RSALv2 restringe, entre outras coisas, a comercialização ou a disponibilização da funcionalidade do software como serviço gerido para terceiros. A SSPLv1 e a AGPLv3 incluem requisitos de copyleft que podem tornar-se relevantes na prestação de serviços ou no acesso à rede. Esta breve descrição não substitui o aconselhamento jurídico: antes da definição de preços, da celebração de contratos ou do lançamento do produto, a arquitetura concreta deve ser analisada do ponto de vista jurídico.

A diferenciação do produto é igualmente importante. Redis de código aberto O número 8 refere-se à linha de servidores com as suas estruturas de dados e funções de consulta integradas. O Redis Software, por outro lado, é uma linha de produtos comercial com documentação de lançamento própria e suporte para várias versões da base de dados Redis. Não se deve deduzir disso que todas as funcionalidades de cluster, gestão ou alta disponibilidade aí descritas façam parte de uma instalação normal de código aberto.

O Valkey e outras ramificações também não são variantes do Redis 8. Quem as considerar como alternativas deve verificar por si próprio os comandos suportados, o modelo de funcionamento, a licença e o percurso de migração. Uma interface de protocolo semelhante ou uma origem histórica comum não são suficientes para inferir garantias de funcionalidade e compatibilidade para aplicações ou ofertas geridas.

Uma decisão sustentável envolve cinco questões: Qual é a versão concreta do Redis adequada ao período de suporte previsto? A carga de trabalho requer efetivamente funcionalidades de pesquisa, séries temporais ou vetores? O modelo operacional está coberto em termos de isolamento, cópias de segurança e monitorização? As ACLs e os clientes foram verificados? E a Exame de licença foi concluído para o tipo de serviço oferecido? Só a combinação destes aspetos é que faz de uma atualização do Redis uma oferta de alojamento fiável.