Node-redis: cómo configurar el tiempo de expiración

Por favor, compruebe el comandos dcoumentation . Cada parte tiene su propio parámetro, por lo que escribiría algo como:

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

Gracias

@BridgeAR el enlace de documentación no funciona

no funciona .. redis versión 3.0

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

@sxyjijiji funciona perfectamente bien para mí. Si se encuentra con un error, publique el seguimiento de la pila y describa lo que no funciona.

@brucejcw arreglé el enlace

Creo que no está incluido en la documentación de node_redis, ni siquiera en la función set.
Quizás confunda a algunas personas.

@bruceCzK No hay documentación de comandos explícitos. Y esto no sería una buena idea en general, ya que los comandos podrían cambiar en Redis y podrían agregarse nuevos parámetros con el tiempo.

Pero hay más de una referencia a la documentación principal que siempre debe mirar para ver cómo funcionan los comandos. Si ve alguna posibilidad de mejorar la documentación actual, no dude en abrir una solicitud de extracción. Puede ser una buena idea agregar el enlace en todas las apariciones de "comandos" en el archivo README.md.

Hola chicos, ¿hay alguna manera de establecer la expiración predeterminada a nivel de cliente?

Ej: algo como

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

Solo repitiendo que esta es una sintaxis muy confusa, especialmente para los recién llegados. No hay nada en la documentación de node_redis sobre vencimientos de claves / TTL. Me imagino que la mayoría de la gente usa Redis como parte de una capa de almacenamiento en caché y el tiempo de vencimiento de las claves sería una parte realmente importante de ese flujo de trabajo. En mi opinión, esto debería integrarse en la API básica (quizás la función set puede incluir un parámetro opcional) o la documentación debería al menos hablar sobre la API de comandos en lo que respecta a la expiración de la clave.

parece que la respuesta es no, que no podemos establecer un vencimiento global a nivel de cliente. Es una especie de asco tener que configurar la expiración de cada tecla.

@ryanvanderpol la función set ya toma un parámetro opcional como se describe. Solo mira la documentación y mi comentario anterior.

@ kienpham2000 No hay caducidad global a nivel de cliente y esto sería difícil de implementar. Cada comando tendría que ser verificado y manipulado. En cambio, una nueva característica para agregar ganchos podría resolver eso.
Esta no es una biblioteca de almacenamiento en caché y es probable que esté buscando eso en su lugar.

@BridgeAR : Entendido, pero estás perdiendo el punto. Quizás sea solo que soy un vago, pero me niego a aprender toda la API nativa de Redis solo para poder meter y sacar cosas. Tal vez no debería usar la biblioteca node_redis entonces. Tal vez debería usar algo más que se coloque encima y lo abstraiga de mí. Sin embargo, como dije antes, creo que la mayoría de la gente usa Redis como caché y no hay nada en la documentación node_redis que mencione la palabra "expirar" o "expiración" (o incluso el comando "EX" o TTL), por lo que sin profundizar en la documentación oficial de Redis es difícil entender cómo establecer realmente un TTL para una clave, una acción que espero que la mayoría de la gente deba hacer.

@ryanvanderpol Es una biblioteca cliente de Redis, no una biblioteca de caché. Si usa una biblioteca de Redis, se espera que lea la documentación de Redis, especialmente porque node_redis no documenta cómo funcionan los comandos, por esta misma razón. Después de todo, node_redis simplemente reenvía los parámetros a Redis la mayor parte del tiempo.

Si desea una biblioteca de caché, puede usar uno de los muchos paquetes npm que existen, como cacheman-redis o node-redis-cache , en su documentación encontrará una mención explícita de "expire": smile:

Entiendo su punto, pero creo que no debería ser el trabajo de node_redis duplicar la documentación de Redis o abstraer cosas más de lo necesario ...

@CherryDT, tu punto es justo, que es también la razón por la que prefacié mi comentario anterior con "tal vez debería usar algo más que esté encima de node_redis", pero dada la cantidad de +1 que mi comentario ha recibido hasta ahora, no tengo ninguna duda que no estoy solo en esta frustración.

Si todo lo que quería hacer era comunicarme directamente con Redis en un formato sin formato, entonces este contenedor realmente no me proporciona mucho valor. Creo que es completamente justo suponer que la gran mayoría de las personas que usan Redis lo hacen con fines de almacenamiento en caché y se preocuparán por los vencimientos.

Toda esta conversación podría haberse negado con un "buen punto, deberíamos agregar un poco a la documentación sobre cómo establecer caducidades de claves, junto con algunos otros comandos de uso común". Supongo que también podría enviar un PR para eso, pero no estoy familiarizado con Redis fuera de usarlo como caché.

Dicho esto, miraré las otras bibliotecas que mencionaste y podría pasar a una de ellas si se adaptan mejor a mi caso de uso.

Mi punto es que hay mucha más funcionalidad que TTL. Hay diferentes tipos de datos (listas, conjuntos, conjuntos ordenados), un sistema de editor y suscriptor y más, y básicamente duplicar la documentación de Redis (y mantenerla actualizada), o agregar más azúcar a los parámetros (y mantener _los_ actualizados) son cosas que creo que están fuera del alcance de este cliente. Tampoco esperaría de un cliente MySQL las características de un ORM (o una referencia de MySQL), ¿verdad?

Creo en el diseño modular y, por lo tanto, también creo que los módulos individuales no deberían ser más grandes de lo necesario. Y en este caso, este cliente hace un gran trabajo al abstraer la parte de la red y proporcionar los comandos como métodos para una primera capa de conveniencia, pero creo que las cosas además de eso deberían ser el trabajo de bibliotecas más especializadas para los objetivos específicos. (como los que vinculé antes para caché, u otros para pubsub, etc.). Aquellos a menudo usan node_redis internamente, por cierto, por lo que incluso si no puede ser de mucha utilidad para usted directamente, puede serlo indirectamente, porque las bibliotecas más abstractas que puede usar tal vez usen node_redis como dependencia.

Entonces, estoy de acuerdo en que para su caso de uso, estaría mejor con una biblioteca de más "alto nivel" además de algo como node_redis.

Sí, estoy completamente en desacuerdo contigo aquí. Esperaría que la documentación de un cliente MySQL me muestre cómo hacer algunas de las cosas comunes que todos hacen en MySQL, como cómo hago una selección con una función agregada o cómo hago una subconsulta. No espero que explique cómo construir un ORM o que sea una reproducción de toda la documentación de MySQL, pero muéstrame cómo hago cosas comunes usando la biblioteca.

De todos modos, claramente no vas a ver mi punto de vista y esto es una pérdida de tiempo. Hasta ahora, 17 personas están de acuerdo conmigo y solo tú y otra persona están en desacuerdo. Entonces, tal vez debería dar un paso atrás y pensar en cómo puede ver las cosas desde la perspectiva de otras personas de vez en cuando.

¿Por qué haces esto personal? Entiendo totalmente tu punto, solo creo que node_redis no es la herramienta adecuada para el trabajo en ese momento. (Como usted mismo acordó antes de que comenzara a hacer mi punto.) Piénselo, mantener las cosas pequeñas y autónomas simplifica muchas cosas. node_redis se preocupa por las redes, cosas como node-cache-redis (o su propia implementación) se preocupan por usar la API de Redis correctamente. De esta forma, no hay tantas dependencias. Las bibliotecas "en la parte superior" siempre existirán de una forma u otra, y de esta manera node_redis no necesita actualizarse (o incluso admitir diferentes versiones de API) cada vez que Redis agrega o cambia alguna característica (solo cuando agrega un _command_ completo) .

Le ofrecí soluciones alternativas, y espero que estas satisfagan sus necesidades, y si no, tómese un momento para buscar "redis" en npm y también encontrará toneladas de otras bibliotecas.

Aceptemos que no estamos de acuerdo con esto. (Y no importa si 17 o 1700 personas están de acuerdo contigo o conmigo. Creo que cada opinión debe valorarse).

Si miramos la pregunta original y la respuesta, no sabía que tenía que usar .set() con 'EX' y opciones de tiempo como esa en esta biblioteca.

Mirando el README.md actual, explica cómo usar client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback), tal vez podamos agregar algunos casos más comunes para SET y GET de manera similar? También asumo que la gente usa mucho GET y SET con redis.

No sabía que tanta gente tuviera problemas con eso, ya que los me gusta no aparecen en mi bandeja de entrada.

Me gustaría un PR que documente el comando set como ejemplo y también mencione "expirar".

También me gustaría tener un PR que documente que esta no es una biblioteca de caché y que no está destinada a serlo. Estoy abierto a cualquier opinión sobre cómo mejorar la documentación para las personas nuevas.

@ kienpham2000 Bueno, también es un comando separado - setex :)

Solo para intervenir aquí sobre la explicación de _redis_ en el archivo léame del módulo _node_redis_. No estoy completamente convencido de la idea. Como se ilustra en este ejemplo, usando set y expire en un multi / exec , usando setex o usando set con 'ex': hay muchas formas de hacer muchas cosas. Ninguno de los cuales tiene nada que ver con node. Explicamos hgetall porque se aparta de cómo otros comandos devuelven valores.

No quiero decir que la gente no tenga preguntas, pero me parece que escribir un blog o una publicación mediana o algo es una mejor manera de informar a la gente en lugar de concentrarlo aquí. Si recibimos la pregunta, simplemente se puede vincular en cualquier problema que surja. Convertir el archivo léame del módulo _node_redis_ en la fuente de todo el conocimiento quizás esté fuera de alcance.

@stockholmux Tengo curiosidad por saber cómo usamos setex en esta biblioteca. ¿Es solo client.setex() ?

Si esta lib es un mapeo 1-1 con comandos redis, entonces creo que no necesitamos doc. Pero si esta biblioteca tiene una forma especial de API o diff para pasar las opciones, creo que tener algún tipo de documento API sería muy útil para los desarrolladores.

@ kienpham2000 es un mapeo 1 a 1. Siempre estuvo destinado a ser uno. Un cliente simple para usar la API. Este es un nivel bajo, no un nivel alto.

Y @stockholmux tiene razón en que hgetall solo está documentado porque puede usarlo de más formas que cualquier otro comando. Pero sigue siendo un mapeo 1 a 1.

De todos modos: estoy a favor de agregar una sección sobre esto para que no vuelva a surgir.

@BridgeAR genial gracias por estar dispuesto a aceptar este documento PR, aquí está mi primer borrador: https://github.com/NodeRedis/node_redis/pull/1229/files

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

Ahora encontré esto y parece otro método: https://dzone.com/articles/tutorial-working-nodejs-and

Tampoco pude hacer que ese método funcionara (sin error, solo sin efecto, así que estoy abandonando este proyecto y cambiando a https://www.npmjs.com/package/node-cache, que puede usar Redis de todos modos.

En Windows no es posible establecer la caducidad dentro del método "set" con 'EX', 20 porque solo acepta 2 parámetros en lugar de 3.

¿Quizás tienes una versión antigua de Redis? Los documentos dicen que se agregó en Redis 2.6.12: https://redis.io/commands/set

Puede usar SETEX en su lugar, que existe desde 2.0.0 ...

¿Quizás tienes una versión antigua de Redis? Los documentos dicen que se agregó en Redis 2.6.12: https://redis.io/commands/set

Estoy usando redis en un proyecto de node-express, con JS no es posible agregar tres parámetros (o no puedo .. :-()

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); -> este es mi código con error en el área de vencimiento.

¿Qué versión de Redis?

Redis 2.4.5 para windows redis-windows y la última versión del módulo de nodo.

Entonces está claro, por favor léame el mensaje de arriba nuevamente y verifique la documentación de Redis. El parámetro "EX" en SET solo se agregó en 2.6.12, por lo que su versión 2.4.5 de Redis no lo tiene, pero en su lugar puede usar SETEX que existe desde 2.0.0.

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

redis.setex(key, value, expiration) -> eso no funciona

... pero he encontrado una forma correcta en este enlace: redis windows

Si desea cambiar su versión de Redis, sí, su camino es correcto, por supuesto.
Si no, el mío también funciona, solo tengo los parámetros incorrectos (pero si hubiera revisado los documentos SETEX, lo habría notado): es clave, segundos, valor y no clave, valores, segundos.

De todos modos, es bueno saber que ahora funciona para usted.

Lo siguiente no funciona.

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

¿Alguna actualización sobre esto?
Estoy usando client.expire(id,10) por ahora.

PD: estoy usando la versión de redis: Redis server v=5.0.0 y versión del nodo: v8.10.0

@kdthanvi Eso debería funcionar. Verifique lo que realmente está sucediendo usando MONITOR de redis-cli al ejecutarlo.

@kdthanvi tiene razón. No funciona con redis 5:

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

Necesitas:

'
client.set (clave, valor, devolución de llamada);

client.expire (clave, TTL, devolución de llamada);
'

para que realmente funcione.

@martinlevesque creo que estás equivocado. EX se agregó en 2.6.12 y node_redis pasa correctamente 'EX' sin importar la versión. Consulte con MONITOR y verá.

SET + EXPIRE puede ser peligrosamente diferente de SET .. EX debido a diferencias atómicas.

Debido a que este hilo es el número 1 cuando busco "Redis node set expire", me gustaría concluir que el siguiente comando set expire funciona con nodeJS redis a partir de hoy.

setex(key, 60, value)

Donde 60 es el tiempo de expiración en segundos.

Debido a que este hilo es el número 1 cuando busco "Redis node set expire", me gustaría concluir que el siguiente comando set expire funciona con nodeJS redis a partir de hoy.

setex(key, 60, value)

Donde 60 es el tiempo de expiración en segundos.

Encontré esto después de 2 horas de depuración y resolución de errores. Muchas gracias ;)