1) Да, в том же порядке.
2) Да. Можно ему указать таймаут 0, поскольку это блокирующая команда, она будет "висеть", пока не появится сообщение (или пока не прервется коннекшн). Я, честно говоря, в случае с одним воркером обхожусь списком и LPUSH/BRPOP On 2013-01-12 19:19, Nick Knutov wrote: > О, а я не сразу увидел, что он такое тоже умеет. > > Только документация какая-то неочевидная, или я не туда смотрю. > > http://search.cpan.org/dist/Redis/lib/Redis.pm#Publish/Subscribe_commands [2]В случае с подпиской - будет ли клиент получать данные в том же порядке, > в котором они были засунуты в редис? > > Обязн ли я использовать при этом wait_for_messages? Если да то > минимальный лаг (вроде) получается 1 секунда, но не получится ли слишком > большой нагрузки, если раз в секунду опрашивать сервер? Это же > получается как раз цикл, который я не хочу, вместо коллбека. > > 12.01.2013 20:50, iSage пишет: > >> Ну, ээ, а чем редис-то не угодил? On 2013-01-12 18:46, Nick Knutov wrote: >> >>> Подскажите, какие сейчас есть nosql серверы, вроде Redis, чтобы не на яве и с биндингом для перла и можно было повесить хук на появление данных? И, наверное, все данные должны сохранятся при потере питания, а скорость не очень критична - данных не много. Кейс предполагается примерно такой: 1) Какой-то внешний скрипт коннектится к nosql базе и кладёт задачу. 2) На некотором другом сервере запущен перловый скрипт демоном с повешенным хуком на появление новых данных (предполагается какой-то механизм коллбека, а не проверка в цикле) и как только для него есть новые задачи - последовательно (это важно) их выполняет. Сейчас очередь в мускле, а скрипт по крону раз в минут за ней ходит, но хочется более быстрой реакции на новые данные, чем раз в минуту. -- Best Regards, Nick Knutov http://knutov.com [1] ICQ: 272873706 Voice: +7-904-84-23-130 > > -- > Best Regards, > Nick Knutov > http://knutov.com [1] > ICQ: 272873706 > Voice: +7-904-84-23-130 Links: ------ [1] http://knutov.com [2] http://search.cpan.org/dist/Redis/lib/Redis.pm#Publish/Subscribe_commands
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
