Node-redis: как установить время истечения

Пожалуйста, проверьте dcoumentation команд. У каждой части есть свой параметр, поэтому вы должны написать что-то вроде:

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

благодаря

@BridgeAR ссылка на документацию не работает

не работает .. redis версия 3.0

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

@sxyjijiji у меня отлично работает. Если вы столкнулись с ошибкой, опубликуйте трассировку стека и опишите, что не работает.

@brucejcw исправил ссылку

Я думаю, что это не входит в документацию node_redis, даже функцию set.
Может быть, кого-то это запутает.

@bruceCzK Нет явной документации по командам. В целом это было бы не очень хорошей идеей, поскольку в Redis команды могут изменяться, а со временем могут добавляться новые параметры.

Но существует более одной ссылки на основную документацию, на которую вы всегда должны смотреть, чтобы увидеть, как работают команды. Если вы видите возможность улучшить текущую документацию, не стесняйтесь открывать для нее пулреквест. Было бы неплохо добавить ссылку на все вхождения "команд" в README.md.

Привет, ребята, есть ли способ установить срок действия по умолчанию на уровне клиента?

Пример: что-то вроде

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

Просто повторю, что это очень запутанный синтаксис, особенно для новичков. В документации node_redis нет ничего об истечении срока действия ключа / TTL. Я предполагаю, что большинство людей используют Redis как часть уровня кеширования, и время истечения срока действия ключей будет действительно важной частью этого рабочего процесса. IMO, это должно быть либо встроено в базовый API (возможно, функция set может принимать необязательный параметр), либо в документации следует хотя бы говорить о командном API, поскольку это связано с истечением срока действия ключа.

похоже, ответ - нет, что мы не можем установить глобальный срок действия на уровне клиента. Отстойно устанавливать срок действия для каждой клавиши.

@ryanvanderpol функция set уже принимает необязательный параметр, как описано. Просто посмотрите документацию и мой комментарий выше.

@ kienpham2000 На уровне клиента нет глобального истечения срока действия, и это было бы сложно реализовать. Каждую команду нужно будет проверять и управлять ею. Вместо этого новая функция для добавления хуков может решить эту проблему.
Это не библиотека для кеширования, и, скорее всего, вы ее ищете.

@BridgeAR : Понятно, но вы как бы упускаете суть. Возможно, я просто ленив, но я отказываюсь изучать весь собственный Redis API, чтобы я мог вставлять что-то и вытаскивать. Может, тогда мне не стоит использовать библиотеку node_redis . Может быть, мне стоит использовать что-то еще, что находится поверх него и отвлекает это от меня. Однако, как я уже говорил ранее, я думаю, что большинство людей используют Redis в качестве кеша, и в документации node_redis даже упоминания слова «истечение срока действия» или «истечение срока действия» (или даже команды «EX» или TTL), поэтому, не копаясь в официальной документации Redis, трудно понять, как на самом деле установить TTL для ключа - действие, которое, как я ожидаю, потребуется большинству людей.

@ryanvanderpol Это клиентская библиотека Redis, а не библиотека кеширования. Если вы используете библиотеку Redis, ожидается, что вы прочитаете документацию Redis, особенно потому, что node_redis не документирует, как работают команды, именно по этой причине. В конце концов, node_redis большую часть времени просто перенаправляет параметры в Redis.

Если вам нужна библиотека кеширования, вы можете использовать один из множества имеющихся пакетов npm, таких как cacheman-redis или node-redis-cache , в их документации вы найдете явное упоминание «expire»: smile:

Я понимаю вашу точку зрения, но я думаю, что работа node_redis не должна дублировать документацию Redis или абстрагироваться от вещей больше, чем необходимо ...

@CherryDT, ваша точка зрения является справедливой, и именно поэтому я предварял свой предыдущий комментарий фразой «может быть, мне следует использовать что-то еще, что находится поверх node_redis», но, учитывая, сколько +1 мой комментарий получил до сих пор, я не сомневаюсь что я не одинок в этом разочаровании.

Если бы все, что я хотел сделать, это напрямую общаться с Redis в необработанном формате, тогда эта оболочка не представляет для меня особой ценности. Я думаю, вполне справедливо предположить, что подавляющее большинство людей, использующих Redis, делают это для целей кэширования и будут заботиться об истечении срока действия.

Весь этот разговор можно было бы просто свести на нет с помощью «хорошего замечания, мы должны добавить в документацию немного о том, как установить срок действия ключей, а также некоторые другие часто используемые команды». Полагаю, я мог бы также отправить PR для этого, но я не знаком с Redis, кроме использования его в качестве кеша.

Тем не менее, я посмотрю на другие библиотеки, которые вы упомянули, и могу перейти к одной из них, если они больше подходят для моего варианта использования.

Я хочу сказать, что функциональных возможностей гораздо больше, чем TTL. Существуют разные типы данных (списки, наборы, отсортированные наборы), система издателя и подписчика и многое другое, и в основном дублирование документации Redis (и поддержание ее в актуальном состоянии) или добавление большего количества сахара к параметрам (и поддержание _them_ обновленным) являются вещи, которые, по моему мнению, выходят за рамки этого клиента. Я бы не ожидал от клиента MySQL функций ORM (или ссылки MySQL), не так ли?

Я верю в модульную конструкцию и, следовательно, считаю, что отдельные модули не должны быть больше, чем они должны быть. И в этом случае этот клиент отлично справляется с абстрагированием сетевой части и предоставляет команды в качестве методов для первого уровня удобства, но я думаю, что над этим должны работать более специализированные библиотеки для конкретных целей. (например, те, которые я ранее связывал для кеширования, или другие для pubsub и т. д.). Между прочим, они часто используют node_redis внутренне. Так что, даже если он может быть не очень полезен для вас напрямую, он может быть косвенным, потому что более абстрактные библиотеки, которые вы можете использовать, могут использовать node_redis в качестве зависимости.

Итак, я согласен, что для вашего варианта использования вам будет лучше с библиотекой более «высокого уровня» поверх чего-то вроде node_redis.

Да, я полностью с вами не согласен. Я ожидаю, что документация для клиента MySQL покажет мне, как делать некоторые из обычных вещей, которые все делают в MySQL, например, как мне сделать выбор с помощью агрегатной функции или как мне сделать подзапрос. Я не ожидаю, что он объяснит, как создать ORM или будет воспроизведением всей документации MySQL, но покажу мне, как я делаю обычные вещи, используя библиотеку.

В любом случае, ясно, что вы не поймете мою точку зрения, и это пустая трата времени. Пока со мной согласны 17 человек, и только вы и еще один человек не согласны. Так что, возможно, вам стоит сделать шаг назад и подумать о том, как вы можете время от времени смотреть на вещи с точки зрения других людей.

Почему вы делаете это личным? Я полностью понимаю вашу точку зрения, я просто думаю, что node_redis тогда не подходит для этой работы. (Как вы сами согласились, прежде чем я даже начал высказывать свою точку зрения.) Подумайте об этом, сохранение небольших размеров и автономности упрощает многие вещи. node_redis беспокоится о сети, такие вещи, как node-cache-redis (или ваша собственная реализация), беспокоятся о правильном использовании Redis API. Таким образом, зависимостей не так много. Библиотеки «сверху» всегда будут существовать так или иначе, и поэтому node_redis не нужно обновлять (или даже поддерживать разные версии API) каждый раз, когда Redis добавляет или изменяет какую-либо функцию (только когда он добавляет целую _command_) .

Я предложил вам альтернативные решения, и я надеюсь, что они будут соответствовать вашим потребностям, а если нет, найдите момент, чтобы поискать "redis" в npm, и вы также найдете множество других библиотек.

Согласитесь, мы с этим не согласны. (И неважно, согласны ли 17 или 1700 человек с вами или со мной. Я считаю, что нужно ценить каждое мнение.)

Если мы посмотрим на исходный вопрос и ответ, я не знал, что мне нужно использовать .set() с 'EX' и такими параметрами времени в этой библиотеке.

Глядя на текущий README.md, он объясняет, как использовать client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback), возможно, мы можем добавить еще несколько общих случаев для SET и GET аналогичным образом? Я также предполагаю, что люди часто используют GET и SET с redis.

Я не знал, что у многих людей были проблемы с этим, поскольку лайки не отображаются в моем почтовом ящике.

Я был бы за PR, который документирует команду set в качестве примера, но при этом упоминает «истекает».

Я также хотел бы иметь PR, который документирует, что это не кеш-библиотека и что она не предназначена для этого. Я открыт для любого мнения о том, как улучшить документацию для новых людей.

@ kienpham2000 Ну это тоже отдельная команда - setex :)

Просто чтобы поговорить об объяснении _redis_ в файле readme модуля _node_redis_. Я не совсем согласен с этой идеей. Как показано в этом примере - использование set и expire в multi / exec , использование setex или использование set с "ex" - есть масса способов сделать много вещей. Ничего из этого не имеет отношения к node. Мы объясняем hgetall потому что это отличается от того, как другие команды возвращают значения.

Нельзя сказать, что у людей нет вопросов, но мне кажется, что написание блога, среднего сообщения или чего-то еще - лучший способ информировать людей, а не сосредоточивать его здесь. Если мы получим вопрос, его можно будет просто связать с любыми возникающими проблемами. Превращение readme модуля _node_redis_ в исходный код для получения знаний, возможно, выходит за рамки.

@stockholmux Мне просто любопытно, как мы используем setex в этой библиотеке? Это просто client.setex() ?

Если эта библиотека представляет собой сопоставление 1-1 с командами redis, я думаю, нам не нужен документ. Но если в этой библиотеке есть специальный способ передачи параметров api или diff, я думаю, что наличие некоторого типа документации API было бы очень полезно для разработчиков.

@ kienpham2000 это

И @stockholmux прав, что hgetall документирован только потому, что вы можете использовать его больше, чем любую другую команду. Но это по-прежнему сопоставление 1 к 1.

В любом случае: я за добавление раздела об этом, чтобы это больше не повторялось.

@BridgeAR круто, спасибо, что готовы принять этот PR документа, вот мой первый черновик: https://github.com/NodeRedis/node_redis/pull/1229/files

Обновлено: https://github.com/NodeRedis/node_redis/pull/1380

Теперь я нашел это, и это похоже на другой метод: https://dzone.com/articles/tutorial-working-nodejs-and

Мне тоже не удалось заставить этот метод работать (без ошибок, просто без эффекта, поэтому я отказываюсь от этого проекта и переключаюсь на https://www.npmjs.com/package/node-cache, который в любом случае может использовать Redis.

В Windows невозможно установить срок действия в методе "set" с помощью 'EX', 20 потому что принимает только 2 параметра вместо o 3.

Может у вас старая версия Redis? В документации говорится, что он был добавлен в Redis 2.6.12: https://redis.io/commands/set

Вместо этого вы можете использовать SETEX, который существует с 2.0.0 ...

Может у вас старая версия Redis? В документации говорится, что он был добавлен в Redis 2.6.12: https://redis.io/commands/set

Я использую redis в проекте node-express, с JS невозможно добавить три параметра (или я не могу .. :-()

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); -> это мой код с ошибкой в ​​области истечения срока действия.

Какая версия Redis?

Redis 2.4.5 для windows redis-windows и последняя версия модуля узла.

Итак, все ясно, пожалуйста, прочтите сообщение выше и проверьте документацию Redis! Параметр «EX» в SET был добавлен только в 2.6.12, поэтому в Redis версии 2.4.5 его нет, но вместо этого вы можете использовать SETEX, который существует с 2.0.0.

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

redis.setex(key, value, expiration) -> это не работает

... но я нашел один правильный способ в этой ссылке: redis windows

Если вы хотите изменить свою версию Redis, да, ваш путь, конечно же, правильный.
Если нет, мой тоже работает, я просто неправильно указал параметры (но если бы вы проверили документацию SETEX, вы бы заметили): это ключ, секунды, значение, а не ключ, значения, секунды.

Во всяком случае, приятно слышать, что теперь это работает для вас.

Ниже не работает.

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

Что-нибудь обновлено по этому поводу?
Сейчас я использую client.expire(id,10) .

PS: я использую версию redis: Redis server v=5.0.0 и версию узла: v8.10.0

@kdthanvi Это должно сработать. Дважды проверьте, что происходит на самом деле, используя MONITOR из redis-cli при запуске.

@kdthanvi прав. Не работает с Redis 5:

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

Тебе нужно:

`
client.set (ключ, значение, обратный вызов);

client.expire (ключ, TTL, обратный вызов);
`

чтобы это действительно работало.

@martinlevesque Я считаю, что вы ошибаетесь. EX был добавлен в 2.6.12, и node_redis правильно передает 'EX' независимо от версии. Проверьте с помощью MONITOR и вы увидите.

SET + EXPIRE может опасно отличаться от SET .. EX из-за атомарных различий.

Поскольку этот поток имеет номер 1, когда я ищу «Срок действия набора узлов Redis истекает», я хотел бы сделать вывод о том, что команда follow set expire работает с nodeJS redis на сегодняшний день.

setex(key, 60, value)

Где 60 - время истечения срока в секундах.

Поскольку этот поток имеет номер 1, когда я ищу «Срок действия набора узлов Redis истекает», я хотел бы сделать вывод о том, что команда follow set expire работает с nodeJS redis на сегодняшний день.

setex(key, 60, value)

Где 60 - время истечения срока в секундах.

Обнаружил это после 2 часов отладки и устранения ошибок. Огромное спасибо ;)