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

[Одинцов Павел]

Такс, я тут пока забил на очереди и заморочился с MemcacheDB,
попутно сделал сравнение с MySQL для большей уверенности в
выборе: http://phpsuxx.blogspot.com/2009/03/mysql-vs-memcachedb.html
(если у кого есть какие комментарии по поводу теста или пожелания
погонять это ещё в каком-то режиме, то велкам).

А-то недавно были посты об архитектуре какого-то хайлоада, где
они хранили данные по ключу в мускуле, поэтому и провел тесты,
но как они показали, я ждал от мускуля невозможного :)

В итоге разница получилась довольно большая (все цифры в "записей / секунду"):

тип        чтение    запись
MySQL  3200      10 000
MchDB  18000     14000

MySQL был следующей конфы: дефалтный Центосовый my.cnf, тип engine --
MyISAM + char вместо varchar в таблице + индекс по ключевому полю.
MemcacheDB: /memcachedb -p7777 -d -r -N -H $PATH/db -u root >
$PATH/debug.log 2>&1

Вполне мог накосячить в тестах, это мой первый опыт подобного
тестирования, так что жду критики :)

2009/3/6 Михаил Монашёв <postmaster на softsearch.ru>:
> Здравствуйте, Павел.
>
> Блокировки делаются через 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 mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением, Одинцов Павел