Node-redis: como definir o tempo de expiração

Verifique a dcoumentação dos comandos. Cada parte tem seu próprio parâmetro, então você escreveria algo como:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

obrigado

@BridgeAR o link de documentação não funciona

não funciona .. redis versão 3.0

client.set(key, value, 'EX', 60 * 60 * 24, callback);

@sxyjijiji funciona perfeitamente bem para mim. Se você encontrar um erro, poste seu rastreamento de pilha e descreva o que não está funcionando.

@brucejcw consertei o link

Eu acho que não está incluído na documentação do node_redis, mesmo a função set.
Talvez isso confunda algumas pessoas.

@bruceCzK Não há documentação de comandos explícita. E isso não seria uma boa ideia em geral, pois os comandos podem mudar no Redis e novos parâmetros podem ser adicionados com o tempo.

Mas há mais de uma referência à documentação principal que você deve sempre consultar para ver como os comandos funcionam. Se você vir alguma possibilidade de melhorar a documentação atual, sinta-se à vontade para abrir uma solicitação de pull para isso. Pode ser uma boa idéia adicionar o link em todas as ocorrências de "comandos" no README.md.

Ei pessoal, há uma maneira de definir a expiração padrão no nível do cliente?

Ex: algo como

  const redisClient = redis.createClient({
    host: process.env.REDIS_ENDPOINT,
    port: process.env.REDIS_PORT,
    expire: 60 
})

Apenas repetindo que esta é uma sintaxe super confusa, especialmente para iniciantes. Não há nada na documentação do node_redis sobre expiração de chave / TTLs. Eu imagino que a maioria das pessoas usa o Redis como parte de uma camada de cache e o tempo de expiração das chaves seria uma parte realmente importante desse fluxo de trabalho. IMO, isso deve ser incluído na API básica (talvez a função set possa incluir um parâmetro opcional) ou a documentação deve pelo menos falar sobre a API de comando no que se refere à expiração da chave.

parece que a resposta é não, pois não podemos definir a expiração global no nível do cliente. É meio chato ter que definir expirar em cada tecla.

@ryanvanderpol a função set já leva um parâmetro opcional conforme descrito. Basta olhar a documentação e meu comentário acima.

@ kienpham2000 Não há expiração global no nível do cliente e isso seria difícil de implementar. Cada comando teria que ser verificado e manipulado. Em vez disso, um novo recurso para adicionar ganchos poderia resolver isso.
Esta não é uma biblioteca de cache e provavelmente você está procurando por ela.

@BridgeAR : Entendido, mas você meio que não entendeu. Talvez seja apenas eu sendo preguiçoso, mas me recuso a aprender toda a API nativa do Redis apenas para poder inserir e retirar coisas. Talvez eu não devesse usar a biblioteca node_redis então. Talvez eu devesse usar outra coisa que fica em cima dele e abstrai isso de mim. No entanto, como eu disse antes, acho que a maioria das pessoas usa Redis como um cache e não há nada na documentação node_redis que sequer mencione a palavra "expirar" ou "expiração" (ou mesmo o comando "EX" ou TTLs) sem cavar na documentação oficial do Redis, é difícil entender como definir um TTL para uma chave, uma ação que espero que a maioria das pessoas precise fazer.

@ryanvanderpol É uma biblioteca cliente do Redis, não uma biblioteca de cache. Se você usa uma biblioteca Redis, espera-se que você leia a documentação do Redis, especialmente porque node_redis não documenta como os comandos funcionam, por este motivo. Afinal, node_redis apenas encaminha os parâmetros para o Redis na maioria das vezes.

Se você quiser uma biblioteca de cache, pode usar um dos muitos pacotes npm disponíveis, como cacheman-redis ou node-redis-cache , em sua documentação você encontrará uma menção explícita de "expirar": smile:

Eu entendo seu ponto, mas acho que não deveria ser trabalho do node_redis duplicar a documentação do Redis ou abstrair as coisas mais do que o necessário ...

@CherryDT, seu ponto é justo, e é também por isso que antecipei meu comentário anterior com "talvez eu devesse usar outra coisa que fique em cima de node_redis", mas considerando quantos + 1s meu comentário recebeu até agora, não tenho dúvidas que não estou sozinho nesta frustração.

Se tudo que eu queria fazer era me comunicar diretamente com o Redis em um formato bruto, esse wrapper realmente não fornece muito valor para mim. Acho que é totalmente justo presumir que a grande maioria das pessoas que usam o Redis o faz para fins de cache e se preocupará com as expirações.

Toda essa conversa poderia ter sido negada com um "bom argumento, devemos adicionar um pouco à documentação sobre como definir expirações de chave, junto com alguns outros comandos comumente usados". Suponho que também poderia enviar um PR para isso, mas não estou familiarizado com o Redis além de usá-lo como cache.

Dito isso, vou olhar para as outras bibliotecas que você mencionou e, em vez disso, posso mover para uma delas, se elas se adequarem melhor ao meu caso de uso.

Meu ponto é que há muito mais funcionalidade do que TTLs. Existem diferentes tipos de dados (listas, conjuntos, conjuntos classificados), um sistema de editor e assinante e muito mais, e basicamente duplicar a documentação do Redis (e mantê-la atualizada) ou adicionar mais açúcar aos parâmetros (e mantê-los _tualizados) são coisas que acredito estarem fora do escopo deste cliente. Eu não esperaria de um cliente MySQL os recursos de um ORM (ou de uma referência MySQL), você esperaria?

Eu acredito no design modular e, portanto, também acredito que os módulos individuais não devem ser maiores do que precisam ser. E, neste caso, este cliente faz um ótimo trabalho abstraindo a parte da rede e fornecendo os comandos como métodos para uma primeira camada de conveniência, mas acho que as coisas além disso deveriam ser o trabalho de bibliotecas mais especializadas para os objetivos específicos (como aqueles que vinculei antes para cache, ou outros para pubsub, etc.). Esses costumam usar node_redis internamente, a propósito. Portanto, mesmo que não seja muito útil para você diretamente, pode ser indiretamente, porque as bibliotecas mais abstratas que você pode usar talvez usem node_redis como dependência.

Portanto, concordo que, para o seu caso de uso, você ficaria melhor com uma biblioteca de "alto nível" em cima de algo como node_redis.

Sim, discordo totalmente de você aqui. Eu esperaria que a documentação de um cliente MySQL me mostrasse como fazer algumas das coisas comuns que todos fazem no MySQL, por exemplo, como faço uma seleção com uma função agregada ou como faço uma subconsulta. Não espero que explique como construir um ORM ou seja uma reprodução de toda a documentação do MySQL, mas me mostre como faço coisas comuns usando a biblioteca.

De qualquer forma, obviamente você não vai entender meu ponto de vista e isso é uma perda de tempo. Até agora, 17 pessoas concordam comigo e apenas você e outra pessoa discordam. Então, talvez você deva dar um passo atrás e pensar sobre como você pode ver as coisas da perspectiva de outras pessoas de vez em quando.

Por que você torna isso pessoal? Eu entendo totalmente seu ponto, só acho que node_redis não é a ferramenta certa para o trabalho então. (Como você mesmo concordou antes mesmo de eu começar a apresentar meu ponto de vista.) Pense nisso, manter as coisas pequenas e independentes simplifica muitas coisas. node_redis se preocupa com a rede, coisas como node-cache-redis (ou sua própria implementação) se preocupam em usar a API Redis corretamente. Dessa forma, não existem tantas dependências. Bibliotecas "no topo" sempre existirão de uma forma ou de outra, e desta forma node_redis não precisa ser atualizado (ou mesmo suporta diferentes versões de API) toda vez que o Redis adiciona ou altera algum recurso (somente quando adiciona um _command_ inteiro) .

Eu lhe ofereci soluções alternativas e espero que atendam às suas necessidades, caso contrário, reserve um momento para pesquisar "redis" no npm e você encontrará toneladas de outras bibliotecas também.

Vamos apenas concordar que discordamos nisso. (E não importa se 17 ou 1.700 pessoas concordam com você ou comigo. Cada opinião deve ser valorizada, eu acho.)

Se olharmos para a pergunta original e a resposta, eu não sabia que precisava usar .set() com 'EX' e opções de tempo como essas nesta biblioteca.

Olhando para o README.md atual, ele explica como usar client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback), talvez possamos adicionar alguns casos mais comuns para SET e GET de forma semelhante? Também estou assumindo que as pessoas usam muito GET e SET com redis.

Eu não sabia que tantas pessoas tinham problemas com isso, pois os gostos não aparecem na minha caixa de entrada.

Eu estaria pronto para um PR que documentasse o comando set como um exemplo, ao mesmo tempo mencionando "expirar".

Também gostaria de ter um PR que documente que esta não é uma biblioteca de cache e que não se destina a ser. Estou aberto a qualquer contribuição sobre como tornar a documentação melhor para novas pessoas.

@ kienpham2000 Bem, também é um comando separado - setex :)

Apenas para falar aqui sobre a explicação de _redis_ no readme do módulo _node_redis_. Não estou totalmente convencido da ideia. Conforme ilustrado por este exemplo - usando set e expire em um multi / exec , usando setex ou usando set com 'ex' - há várias maneiras de fazer muitas coisas. Nada disso tem a ver com o nó. Explicamos hgetall porque difere de como outros comandos retornam valores.

Não querendo dizer que as pessoas não tenham dúvidas, mas me parece que escrever um blog ou post de mídia ou algo assim é a melhor maneira de informar as pessoas do que concentrá-lo aqui. Se recebermos a pergunta, ela pode ser relacionada a qualquer problema que surgir. Transformar o readme do módulo _node_redis_ na fonte apenas para conhecimento talvez esteja fora do escopo.

@stockholmux Estou apenas curioso em como usamos setex nesta biblioteca? É apenas client.setex() ?

Se esta lib é mapeamento 1-1 com comandos redis, então acho que não precisamos do doc. Mas se esta lib tem uma forma especial de api ou diff de passar opções, acho que ter algum tipo de documento de API seria muito útil para os desenvolvedores.

@ kienpham2000 é um mapeamento 1 para 1. Sempre foi feito para ser um. Um cliente simples de usar a API. Este é um nível baixo, não um nível alto.

E @stockholmux está certo ao dizer que hgetall só está documentado porque você pode usá-lo de mais maneiras do que qualquer outro comando. Mas ainda é um mapeamento 1 para 1.

De qualquer forma: sou a favor de adicionar uma seção sobre isso para que não volte a aparecer.

@BridgeAR muito obrigado por aceitar este documento PR, aqui está meu primeiro rascunho: https://github.com/NodeRedis/node_redis/pull/1229/files

Atualizado: https://github.com/NodeRedis/node_redis/pull/1380

Agora eu encontrei isso e parece outro método: https://dzone.com/articles/tutorial-working-nodejs-and

Eu também não consegui fazer esse método funcionar (sem erro, apenas sem efeito, então estou abandonando este projeto e mudando para https://www.npmjs.com/package/node-cache que pode usar o Redis de qualquer maneira.

No Windows não é possível definir a expiração dentro do método "definir" com 'EX', 20 porque só aceita 2 parâmetros em vez de 3.

Talvez você tenha uma versão antiga do Redis? Os documentos dizem que foi adicionado no Redis 2.6.12: https://redis.io/commands/set

Você pode usar SETEX em vez disso, que existe desde 2.0.0 ...

Talvez você tenha uma versão antiga do Redis? Os documentos dizem que foi adicionado no Redis 2.6.12: https://redis.io/commands/set

Estou usando redis em um projeto node-express, com JS não é possível adicionar três parâmetros (ou não estou conseguindo .. :-()

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); -> este é meu código com erro na área de expiração.

Qual versão do Redis?

Redis 2.4.5 para windows redis-windows e última versão do módulo de nó.

Então está claro, leia a mensagem acima novamente e verifique a documentação do Redis! O parâmetro "EX" em SET foi adicionado apenas em 2.6.12, portanto, sua versão do Redis 2.4.5 não tem, mas você pode usar SETEX que existe desde 2.0.0.

redis.setex(key, seconds, value)
redis.setex(key, value, seconds)

redis.setex(key, value, expiration) -> que não está funcionando

... mas eu encontrei uma maneira correta neste link: windows redis

Se você quiser mudar sua versão do Redis, sim, seu jeito é certo, claro.
Se não, o meu também funciona, acabei de errar os parâmetros (mas se você tivesse verificado os documentos do SETEX, você teria notado): é chave, segundos, valor e não chave, valores, segundos.

De qualquer forma, é bom saber que agora funciona para você.

O abaixo não funciona.

client.set('key', 'value', 'EX', 10, (error, replay)=>{
...
}

Alguma atualização sobre isso?
Estou usando client.expire(id,10) por enquanto.

PS: Estou usando a versão do redis: Redis server v=5.0.0 e a versão do nó: v8.10.0

@kdthanvi Isso deve funcionar. Verifique novamente o que está realmente acontecendo usando MONITOR de redis-cli ao executá-lo.

@kdthanvi está certo. Não funciona com o redis 5:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

Você precisa:

`
client.set (chave, valor, retorno de chamada);

client.expire (chave, TTL, retorno de chamada);
`

para fazer realmente funcionar.

@martinlevesque Acho que você está enganado. EX foi adicionado em 2.6.12 e node_redis passa corretamente 'EX' não importa a versão. Verifique com MONITOR e você verá.

SET + EXPIRE pode ser perigosamente diferente de SET .. EX devido a diferenças atômicas.

Como este segmento é o número 1 quando procuro "Redis node set expire", gostaria de deixar claro que o comando follow set expire funciona com nodeJS redis a partir de hoje.

setex(key, 60, value)

Onde 60 é o tempo de expiração em segundos.

Como este segmento é o número 1 quando procuro "Redis node set expire", gostaria de deixar claro que o comando follow set expire funciona com nodeJS redis a partir de hoje.

setex(key, 60, value)

Onde 60 é o tempo de expiração em segundos.

Encontrei isso após 2 horas de depuração e solução de erros. Muito obrigado ;)