[Moscow.pm] Асинхронная обработка: ActiveMQ и другие брокеры сообщений

[Михаил Монашёв]

Здравствуйте, Павел.

Блокировки делаются через 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/
Без бэкапа по жизни.