Cache (Valkey)
1. Visão Geral
O add-on Cache (Valkey) implanta uma instância do Valkey — fork open-source do Redis — dentro de um ambiente, para uso como cache, gerenciamento de sessão, pub/sub e estruturas de dados em tempo real.
Use quando o fluxo, app ou outro add-on precisa de um armazenamento chave/valor rápido em memória, com ou sem persistência em disco.
Tags do catálogo: Cache, In-Memory, Key-Value.
2. Pré-requisitos
- Um squad e um ambiente já selecionados na tela de Add-ons.
3. Passo a passo do Deploy
O assistente de deploy do Cache (Valkey) tem 4 passos:
Passo 1 — General
| Campo | Obrigatório | Descrição |
|---|---|---|
| Add-on Name | Sim | Nome do add-on dentro do ambiente. Apenas letras minúsculas, números e hífens (3 a 63 caracteres). Exemplo: my-cache. |
Passo 2 — Admin User
O usuário padrão do Valkey usa autenticação por senha via REQUIREPASS. O nome de usuário é fixo (default) — usuários ACL adicionais podem ser criados depois.
| Campo | Obrigatório | Descrição |
|---|---|---|
| Admin Username | — | Fixo em default, não editável. |
| Password | Sim | Senha de autenticação do usuário default. |
| Eviction Policy | Não | Define como as chaves são removidas quando o limite de memória é atingido. Padrão: allkeys-lru (política recomendada para uso como cache). |
Passo 3 — Persistence
Define como os dados sobrevivem a reinicializações, e configura os backups automáticos (mesmo padrão do add-on PostgreSQL).
| Campo | Obrigatório | Descrição |
|---|---|---|
| Persistence Mode | Não | Modo de persistência dos dados. Opções: NONE (cache puro em memória, sem persistência), RDB — snapshots periódicos (padrão), AOF — log append-only (mais durável, porém mais lento), RDB+AOF — os dois combinados. |
| RDB Save Schedule | Se modo RDB ou RDB+AOF | Pares segundos alterações que definem quando um snapshot é disparado. Padrão: 3600 1 300 100 60 10000 — dispara um snapshot a cada hora com pelo menos 1 alteração, a cada 5 min com 100, ou a cada 1 min com 10000. |
| Enable automatic backups | Não | Liga/desliga os backups automáticos. Ligado por padrão. |
| Keep last N backups | Se backups ligados | Quantidade de backups mais recentes mantidos antes de purgar os mais antigos. Padrão: 10. |
| Cron schedule (UTC) | Se backups ligados | Expressão cron (em UTC) que define a frequência dos backups. Padrão: 0 2 * * * (todo dia às 02:00 UTC). |
Passo 4 — Resources
Define os recursos alocados para a instância.
| Campo | Padrão | Máximo |
|---|---|---|
| Memory | 256Mi | 2Gi |
| CPU | 500m | 2000m |
| Disk Size | 1Gi | 20Gi |
Ao clicar em Deploy Add-on, a implantação é iniciada. O add-on passa a aparecer na aba My Add-ons do ambiente.
4. Após o Deploy
TODO: descrever como obter o host/porta de conexão da instância após o deploy, e como criar usuários ACL adicionais além do usuário default.
5. Perguntas frequentes
Qual a diferença entre os modos de persistência (NONE, RDB, AOF, RDB+AOF)?
NONE não grava nada em disco — se a instância reiniciar, os dados são perdidos (uso como cache puro). RDB tira fotos periódicas do estado (pode perder as últimas alterações entre snapshots). AOF grava um log de cada alteração (mais durável, porém com mais overhead). RDB+AOF combina os dois.
Dá para mudar a Eviction Policy depois do deploy?
TODO: confirmar se Eviction Policy pode ser alterada após a implantação.