Мне нужен какой-то толчек в понимании. Спинным мозгом чувствую, что на верном пути.
Хочу хранить очередь пользовательских событий в redis.
Ключом видимо будет комбинация user_id и времени (или инк. счетчика), а значением будет описание события. Я могу сразу задавать время устаревания записи, чтобы не копить бесконечно. Суть события сейчас абсолютно неважна. Интересует только доступ к этой очереди.
В redis, насколько я понимаю, нет reset + next. Как мне итерировать очередь с головы к хвосту? Допустим я буду сохранять отдельно значение ключа самого свежего события, а дальше что?
Профи-и-и-и!!! Вася-а-а-а-ц!!!
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
ёбнуть всё в новых вкладках
Форум → Разработка → Установка и администрирование ПО → Серверы баз данных → Поток событий (с устареванием) в key-value
Поток событий (с устареванием) в key-value
Страницы: ← Следующая страница →
-
Сообщения:
5147
Репутация:
N
Группа:
в ухо
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 9:48 д.п., спустя 7 минут
там есть списки … заводи на юзера список, в список то и добавляй события, доки читай, чо профи отвлекать от онанизма?!
/me пошел мыть рукиСапожник без сапог -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 9:55 д.п., спустя 6 минут 55 секунд
Спасибо маса Дуд за наставление!
Вот нашел чего люди делали — очередь сообщений на redis. http://art-code.com.ua/articles_N154.htm
Да, используют структуру list. Сука-сука, элементы очереди ведь не устаревают как сами записи. Это уже чуть менее красиво, чем я планировал.Спустя 108 сек.Т.е. они не устаревают «автоматически».ιιlllιlllι унц-унц -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 9:58 д.п., спустя 2 минуты 8 секунд
Да, используют структуру list. Сука-сука, элементы очереди ведь не устаревают как сами записи. Это уже чуть менее красиво, чем я планировал.
да, может устареть весь СПИСОК, а не отдельная структура, это неудобно :(
сталкивался :(Сапожник без сапог -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 10:02 д.п., спустя 4 минуты 50 секунд
В общем здесь есть место для изобретательства. Актуально.ιιlllιlllι унц-унц
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 10:06 д.п., спустя 3 минуты 19 секунд
тебе надо "список с устареванием"? так тогда - в список добавляй айдишники записей + записывай сами записи в виде айдишников этих эвентам, ставь им время устаревания, и извлечение в 2 захода - получаем список вентов и чреез мультигет получаем список неустаревших записей, фильтруем и все - профит. хули выдумывать? :)Спустя 28 сек.
Карма: 86
ы
у меня в webmoney такой bussiness level :DСапожник без сапог -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 10:22 д.п., спустя 16 минут 50 секунд
Чем больше уровней в редисе, тем ниже профит. Если запрос становится "многоходовым", может оказаться, что преимущества перед SQL улетучились.ιιlllιlllι унц-унц
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 10:31 д.п., спустя 8 минут 7 секунд
Если запрос становится "многоходовым", может оказаться, что преимущества перед SQL улетучились.
ение памяти преде чтением с жесткого диска .. пусть даже и медленее запросы выполнится чем в скл, но профит на лицо - файловая подсистема свободна. так что не пизди, а реализуй так :D
+ мускуль на любой запрос памяти жрет дохуища все равно)Сапожник без сапог -
Сообщения:
3131
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 12:23 п.п., спустя 1 час 52 минуты 15 секунд
Что за события?
Ещё там есть подписки.Спустя 229 сек.Ещё есть упорядоченные множества.
Можно время использовать, как оценку (значение, по которому будет сортироваться множество), периодически удаляя устаревшие.
Зависит от того, что там всё-таки за события такие. -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 12:33 п.п., спустя 10 минут 34 секунды
любопытно, но разве эта модель не для постоянного соединения? если я вызову publish, мое сообщение получат только те, кто в этот момент подписан на канал.Спустя 71 сек.совершенно неважно что за события. просто кусок говна, которое пользователь сервиса должен получить, пока оно не просрочено.Спустя 95 сек.ссылка на чат Нурдхуйза дохлаяιιlllιlllι унц-унц
-
Сообщения:
3131
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 1:01 п.п., спустя 27 минут 25 секунд
Это сообщения "от пользователя"? т.е. другие пользователи многократно могут их читать?
или это "сообщение пользователю", т.е. конкретный пользователь может достать это сообщение только один раз? -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 1:06 п.п., спустя 5 минут 18 секунд
это какбы новости. они от многих многим. вася будет участвовать в автопробеге. у пети день рождения. сарочка забеременела.Спустя 28 сек.они не сгорают при прочтенииιιlllιlllι унц-унц
-
Сообщения:
3131
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 1:07 п.п., спустя 1 минуту 1 секунду
Если второе, можно так.
message:ids - общая переменная, максимальный ID сообщения
message:$id - конкретное сообщение с ID=$id
message:user:$uid - список сообщений для юзера $uid
посылаем 17-му юзеры сообщение "хуё-моё":
INCR message:ids // новый ID (25 пусть)
SET message:25 "хуё-моё"
EXPIRE message:25 3600 // время устаревания сообщения
RPUSH message:user:17 25 // кинули ID сообщения в очередь сообщений пользователя
Пользователь достаёт сообщения с другого конца.
LPOP message:user:17 // 25
GET message:25
Если GET вернул нихуя, значит сообщение устарело - повторить LPOP. -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
Сен. 23, 2010, 1:15 п.п., спустя 7 минут 47 секунд
понятно. только видимо (l)push и (l)pop — читаем с самого свежего. а при надобности еще ltrimιιlllιlllι унц-унц
-
Сообщения:
50
Репутация:
N
Группа:
Кто попало
Сен. 27, 2010, 2:21 п.п., спустя 4 дня 1 час 6 минут
еще чуть-чуть и вы заново изобретете http://www.zeromq.org/
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!