[Moscow.pm] Асинхронная обработка: ActiveMQ и другие брокеры сообщений
Михаил Монашёв
postmaster на softsearch.ru
Чт Мар 5 14:24:55 PST 2009
Здравствуйте, Павел.
Блокировки делаются через add :
http://cpansearch.perl.org/src/EARL/IPC-Lock-0.14/lib/IPC/Lock/Memcached.pm
Но лучше избегать блокировок или сделать их рассеянными, т.е. так,
чтобы вероятность попадания на эту блокировку была близка к нулю,
например, организовав 100 очередей. Или создавать очереди с привязкой
к определённому временному интервалу и писать append-ом в одну, а
читать из другой сразу пачкой. Или через inc увеличивать счётчик и
получать id-ку следующего ключа и в него писать событие, а читать,
увеличивая второй счётчик. Если ничего не смогли прочитать, то ждём
немного и снова пытаемся прочесть. Иногда проверяем, не убежал ли
первый счётчик намного дальше второго, а второй уткнулся в куда-то
пропавшее сообщение (мало ли чего может случится...). Криво, но
работоспособно.
Чтобы ответить конкретнее нужны условия задачи. Например сколько
сообщений с единицу времени нужно через эту очередь пропускать, какое
возможно отставание между отправлением и получением, важен ли порядок
сообщений, сколько процессов может писать/читать сообщения в/из
очереди, возможна ли пакетная обработка сообщений. Чем больше данных,
тем лучше получится решить задачу. Общие условия всегда дают плохие
решения.
P.S.
А можно вообще самому написать демона на EV...
ОП> Благодарю за развернутый ответ, скорее всего MemcacheDB будет
ОП> использоваться для хранения данных.
ОП> По поводу очередей на нём больше всего интересует вопрос блокировок --
ОП> при получение / занесении элементов,
ОП> я так понимаю, мы должны блочить конкретную очередь на чтение /
ОП> запись, чтобы кто-то другой не забрал
ОП> себе задание или же для этого будет достаточно обычных транзакций?
ОП> 2009/3/6 Михаил Монашёв <postmaster на softsearch.ru>:
>> Здравствуйте, Павел.
>>
>> Возможно не совсем то, что Вы ищете, но всё же напишу...
>>
>> Если хотите построить по настоящему не убиваемую систему, сделайте её
>> на основе MemcacheDB. И быстро и просто и масштабируется бесконечно.
>> Нужно будет только чуток допилить Cache::Memcached, чтобы он понимал
>> rget и мог устраивать перевыборы мастера. Плюс организовать
>> элементарное добавление и вытаскивание сообщений. Есть ещё MemcacheQ
>> (в каких-то старых версиях вроде хранил своё состояние на диске) и
>> beanstalk (перлового клиента вроде ещё нет, но могу ошибаться), но они
>> не переживают рестарт. Авторизации нигде нет.
>>
>> ОП> Интересует вот такой вопрос -- хочу попробовать в одном проекте
>> ОП> реализовать полностью
>> ОП> асинхронную обработку на основе посылки сообщений между различными
>> ОП> частями системы.
>>
>> ОП> Требования к брокеру сообщений довольно простые -- сохранять
>> ОП> содержимое очереди при рестарте,
>> ОП> иметь систему авторизации (при посылке / приёме сообщений) +
>> ОП> нормальный интерфейс работы (REST и др.).
>>
>> ОП> Самым первым в руки попался брокер сообщений ActiveMQ, но оно,
>> ОП> во-первых, на Java, а, во-вторых,
>> ОП> в интернетах довольно много жалоб на его стабильность.
>>
>> ОП> Вопрос -- кто использовал подобные системы и какую лучше выбрать?
>>
>> ОП> --
>> ОП> С уважением, Одинцов Павел
>> ОП> --
>> ОП> Moscow.pm mailing list
>> ОП> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>>
>>
>> --
>>
>> С уважением,
>> Михаил Монашёв, SoftSearch.ru
>> mailto:postmaster на softsearch.ru
>> ICQ# 166233339
>> http://michael.mindmix.ru/
>> Без бэкапа по жизни.
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
--
С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster на softsearch.ru
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.
Подробная информация о списке рассылки Moscow-pm