[Moscow.pm] Асинхронная обработка: ActiveMQ и другие брокеры сообщений
Одинцов Павел
pavel.odintsov на googlemail.com
Вс Мар 15 03:15:44 PDT 2009
Такс, я тут пока забил на очереди и заморочился с 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
>
--
С уважением, Одинцов Павел
Подробная информация о списке рассылки Moscow-pm