Comments 5
Насколько я помню, sortedset'ы — самое медленное, что есть в редисе.
Не было мысли (в случае конечности весов, например только 1,2...10) создать десяток обычных очередей и опрашивать их по очереди, начиная с queue1?
ИМХО, вышло бы быстрее.
Не было мысли (в случае конечности весов, например только 1,2...10) создать десяток обычных очередей и опрашивать их по очереди, начиная с queue1?
ИМХО, вышло бы быстрее.
Предложение на каждую минуту (срабатывания события) заводить свою очередь?
Как предполагается получать ключи этих очередей? Скажем, если у нас был простой 5 минут, то нам надо получить 5 ключей листов и последовательно их обработать.
Я правильно понимаю?
Как предполагается получать ключи этих очередей? Скажем, если у нас был простой 5 минут, то нам надо получить 5 ключей листов и последовательно их обработать.
Я правильно понимаю?
Приблизительно так.
Простой можно проверять, например, по очереди, в которую сложены обработанные минуты.
Насколько я помню, оверхед на создание новой очереди минимален, а вот быстродействие будет таки O(1) (ну точнее, от количества запросов к очередям) у очереди против O(log(N)+M) в вашем варианте.
Простой можно проверять, например, по очереди, в которую сложены обработанные минуты.
Насколько я помню, оверхед на создание новой очереди минимален, а вот быстродействие будет таки O(1) (ну точнее, от количества запросов к очередям) у очереди против O(log(N)+M) в вашем варианте.
Подскажите, а как-нибудь решали проблему конкурентного чтения из SortedSet?
Или сканеры работают только в один поток?
Или сканеры работают только в один поток?
Sign up to leave a comment.
Отложенные уведомления пользователей на Node.js & Redis