А потом я побывал на максимально упоротом собесе в криптостартапе и решил по криптостартапам больше не ходить ?

? Вроде разобрался. Такие ньюансы в доках лучше указывать явно ???. Это нихерашечки не очевидно. Там есть параметр HZ, который помечен как оптимальный. Отвечает за опрос что-то там-толком не понял. Ну и в определенных кейсах редиска банально не успевает добраться до ключа, у которого истекло время жизни. Выставил напобольше - поехало как часы.

@Saluev @bladdon @aragaer вы знали о такой засаде?

А че я то сразу

Я редис только как кеш использовал

Ты не сразу, а вторым)

я не очень знаю, что такое редис

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

кажется, опираться на это плохая идея

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

Очень жаль, что не дошли. Но еще не поздно, будем рады пообщаться )

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

Прямо заявленная точность до 1 мс.

На данный момент нет, можем в личке обсудить детали

Да не. Я так, на всякий случай

Вообще, для подобных штуковин сначала хотел заюзать что-то более надежное. Но увы. Я нихера не нашел, где бы поддерживался TTL записи

М?

Вы там про редис?

? Вроде разобрался. Такие ньюансы в доках лучше указывать явно ???. Это нихерашечки не очевидно. Там есть параметр HZ, который помечен как оптимальный. Отвечает за опрос что-то там-толком не понял. Ну и в определенных кейсах редиска банально не успевает добраться до ключа, у которого истекло время жизни. Выставил напобольше - поехало как часы.

у тебя какой-то странный кейс использования

ты хочешь мгновенно получать нотификацию, что expire для какого-то ключа закончился?

Ага

В aerospike, кстати, TTL записи есть

Ага

странное желание какое-то

у редиса есть два механизма: 1. ключ удаляется при попытке его получения (если ttl истек) 2. фоновый gc, который их выщищает

И правда, зачем нотификации на ТТЛ?

исходя из этого странно строить логику на этом

у редиса есть два механизма: 1. ключ удаляется при попытке его получения (если ttl истек) 2. фоновый gc, который их выщищает

У меня через подписку на триггер или как он точно называется.

У меня через подписку на триггер или как он точно называется.

да пофигу, я тебе рассказал как оно внутри работает

в общем единственный нормальный кейс использования ttl, это гарантия того, что ты не получишь устаревшие данные

все остальные кейсы использовать не надо

> If no command targets the key constantly, and there are many keys with a TTL associated, there can be a significant delay between the time the key time to live drops to zero, and the time the expired event is generated. Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero. https://redis.io/topics/notifications

в общем единственный нормальный кейс использования ttl, это гарантия того, что ты не получишь устаревшие данные

+

в общем единственный нормальный кейс использования ttl, это гарантия того, что ты не получишь устаревшие данные

Не понял. Ты выставил на ключ ттл. Если ключ еще жив, что А, если нет то Б. Ты об этом?

> If no command targets the key constantly, and there are many keys with a TTL associated, there can be a significant delay between the time the key time to live drops to zero, and the time the expired event is generated. Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero. https://redis.io/topics/notifications

Там написано "Много". В моем представлении много - это в рамках редиски почти дохуя. Но таких TTL ключей там не будет много в принципе никогда. Поэтому и выбрал.

Не понял. Ты выставил на ключ ттл. Если ключ еще жив, что А, если нет то Б. Ты об этом?

я о том, что в нормальном сценарии редис может узнать о том, что ttl истек только в момент попытки получения этого ключа. Т.е. он достает данные по ключу, видит что там есть ttl, если он не истек возвращает значение, если истек - то возвращает, что этого ключа нет и физически его удаляет

я о том, что в нормальном сценарии редис может узнать о том, что ttl истек только в момент попытки получения этого ключа. Т.е. он достает данные по ключу, видит что там есть ttl, если он не истек возвращает значение, если истек - то возвращает, что этого ключа нет и физически его удаляет

Окей. Они же в доках прямо пишут заявленную точность.

Окей. Они же в доках прямо пишут заявленную точность.

покажи где написано про заявленную точность expired-нотификаций

это про получение ключа

как ты представляешь себе мгновенную реакцию на истечение ttl в хэш-таблице?

Я не знаю, что у них под коробкой. В редиске. Может там какие-нибудь таймеры

Я не знаю, что у них под коробкой. В редиске. Может там какие-нибудь таймеры

В общем, ты пытаешься применять инструмент для того для чего он не предназначен, и необоснованно негодуешь почему он не работает так как ты ожидаешь

это не проблема редиса, а проблема того, что ты не понимаешь как он работает

В общем, ты пытаешься применять инструмент для того для чего он не предназначен, и необоснованно негодуешь почему он не работает так как ты ожидаешь

Зачем тогда они сделали сабскрайбы?

Зачем тогда они сделали сабскрайбы?

для подписки на события. И события действительно отправляются. Но применительно к ttl они явно говорят каким образом эти ключи инвалидируются и соответсвенно только в этот момент срабатывает event

@MarkEgorov https://redis.io/commands/expire#how-redis-expires-keys

для подписки на события. И события действительно отправляются. Но применительно к ttl они явно говорят каким образом эти ключи инвалидируются и соответсвенно только в этот момент срабатывает event

Ага. И еще неоч прямо за точность отвечает параметр hz.

Ага. И еще неоч прямо за точность отвечает параметр hz.

а где я это говорил? Да, при увеличении hz редис начинает чаще вычищать expired ключи, но это все равно не дает никаких гарантий. Ты же понимаешь что результат зависит от кол-ва ключей с ttl?

если ты задрал hz до 100 и при твоих 1000 ключах все ок, то это не значит, что когда ключей станет 1кк все будет работать так как ты ожидаешь

это не изначально нерабочая схема, и редис для этого не предназначен

а где я это говорил? Да, при увеличении hz редис начинает чаще вычищать expired ключи, но это все равно не дает никаких гарантий. Ты же понимаешь что результат зависит от кол-ва ключей с ttl?

А я выше писал, что у меня изначально ttl ключей много не будет. Это не сессии пользователей. И уж с соточкой-другой редиска должна справится.

Я не знаю, что у них под коробкой. В редиске. Может там какие-нибудь таймеры

Я же кинул ссылку. "Между истечением таймаута и нотификацией может быть огромная задержка"

Как в sublime3 сделать подсветку модулей с библиотек?

А я выше писал, что у меня изначально ttl ключей много не будет. Это не сессии пользователей. И уж с соточкой-другой редиска должна справится.

Вообще тут можно говорить только о вероятности. Может сработать быстро, а может и нет. Это зависит от того какие рандомные ключи редис выберет для проверки

Test 20 random keys from the set of keys with an associated expire.

А я выше писал, что у меня изначально ttl ключей много не будет. Это не сессии пользователей. И уж с соточкой-другой редиска должна справится.

Тогда зачем тебе вообще эти уведомления?

Вообще тут можно говорить только о вероятности. Может сработать быстро, а может и нет. Это зависит от того какие рандомные ключи редис выберет для проверки

Задержка в пять секунд приемлема. Неприемлема в минуту. Пока посмотрю. Вроде полет ровный, почти секунда в секунду.

Test 20 random keys from the set of keys with an associated expire.

если в этих 20 рандомных ключах будет меньше 5 expired, то придется ждать следующий цикл, который запустится через 1/hz секунд

Тогда зачем тебе вообще эти уведомления?

Мне надо некое внешнее кей валуе, которое гарантированно вернет нотификацию, что ключу хана. Ну или через get.

Ну через гет тебе редис стопудово вернет

А зачем нотификация?

В общем не надо так делать. Гарантий никаких, это вообще не масштабируется на большее количество ключей, увеличивает нагрузку на cpu

Какой кейс вообще

А зачем нотификация?

Элегантно получается.

Итого, тебе надо получать нотификации, если не было никаких действий с ключом N-секунд. Так?

Вообще много у тебя там операций записи?

Итого, тебе надо получать нотификации, если не было никаких действий с ключом N-секунд. Так?

Нет. Мне нужен срок жизни ключа. Дальше демон получает уведомление, генерирует пак событий - и рассылает их.

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

Может есть решение

Чоблин

Чо

Все ещё не понятно, что значит "как переменную"

Приведи пример

Ну

У вас проекты на хероку нормально пашут?

Всем привет

Вопрос немного не по теме

Но, не могу скачать файл с ЯД

через curl

Через апи получил итоговую ссылку

Обращаюсь к ней curl -o ./FILE.FILE HTTP:…//../

Скачивается файл 32 б с содержимым HTTP 422 No parameter: filename

Наверно randint надо числа передавать, а ты строки суешь

А сам вывод curl таков: [1] 83057 [2] 83058 [3] 83059 [4] 83060 [5] 83061 [6] 83062 [7] 83063 [8] 83064 [9] 83065 [10] 83066 [2] Done filename=v3.efi [3] Done disposition=attachment [4] Done hash= [5] Done limit=0 [6] Done content_type=application%2Fx-dosexec [7] Done fsize=927424 [8] Done hid=f588265224c6eaa74b95ddc0159a6d5f [9] Done media_type=unknown [10]+ Done tknv=v2 MacBook-Pro-Alexandr:~ alexandr$ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 32 0 32 0 0 165 0 --:--:-- --:--:-- --:--:-- 165

Они у тебя и так переменные

Просто в них не числа, а строки