Главная > Java - язык и технологии, MMOG, MMORPG игры, Open Source, PHP, веб-обзоры, Высокопроизводительная архитектура, Разное > Краткий обзор MQ (Messages queue) для применения в проектах на РНР. Часть 1

Краткий обзор MQ (Messages queue) для применения в проектах на РНР. Часть 1

18 ноября 2008

Приветствуем наших читателей. К сожалению, очень много дел и проблем навалилось, поэтому частота обновление блога не такая, как хотелось бы, но это поправимо. Параллельно к основной работе, я в "фоне" обдумываю и прикидываю реализации архитектуры для игровых проектов (напомню, что основная область моих интересов и работ - создание онлайновых браузерных игр). Последнее время я все чаще и чаще возвращаюсь к мысли, что интересно было бы реализовать основной игровой сервер на основе очередей сообщений (MQ или Messages queue). То есть,  движок такой игры будет представлять собой набор компонентов, которые будут общаться между собой посредством асинхронных сообщений, а каждый компонент может быть как генератором сообщений, так и подписчиком, то есть исполнять другие сообщения.

Такой подход, насколько я понимаю, широко применяется в мире Java, там для этого есть стандарт Java Message Service (JMS) и применяются брокеры сообщений и на этом базируется архитектура  Enterprise service bus (ESB), например,  Apache ServiceMix. Но для нас это пока высокая сфера крупных проектов, а в специфике веба и веб-ориентированных приложений я бы хотел рассмотреть, можно ли что-то сделать подобное, но с меньшими затратами и обеспечить приложению отказоустойчивость, распределение нагрузки и асинхронную обработку. И конечно, очень желательно, чтобы это было реализовано на РНР как основном языке реализации всех компонентов сервера.

И так, еще раз - MQ, это архитектура и ПО промежуточного уровня, которое занимается сбором, хранение и маршрутизацией (распределением) сообщений между компонентами. Я не претендую на полноту описания, и, вполне возможно, не учитываю множества нюансов, поэтому не рассматривайте мои определения как аксиомы, лучше всего почитать дополнительную литературу, если вы хотите поглубже разобраться в архитектуре MQ (например, вот эти статьи: [1], [2], [3]) и определение в Wikipedia - Message queue

Пока давайте посмотрим очень кратко, обзорно, какие системы реализации систем сообщения есть, а, главное, какие из них можно рассматривать в качестве основы для специфика моего проекта. И хотя я думал рассмотреть только РНР реализации, оказалось, что нужно "копать глубже", поэтому мы затронем и системы на других языках, но обладающие возможность взаимодействовать с РНР-приложениями.

Apache ActiveMQ - открытая реализация брокера сообщений (Message Broker) и Enterprise Integration Patterns (если сейчас и очень кратко - расширение для реализации дополнительной обработки согласно правилам). Этот проект, по моему мнению, из всех открытых, самый мощный и развивающийся, недавно вышла версия 5.1. Он реализовывает множество стандартов и обеспечивает все возможности, необходимые для решений уровня Enterprise, входит в стек Java-технологий от Apache. Что меня заинтересовало, так это возможность кросс-языкового обмена сообщениями, а значит - клиенты могут быть реализованы на любом языке. Для платформ Java, C, C++, C# это библиотека OpenWire, реализующая Wire протокол для нативного доступа к MQ, для остальных языков, включая, что нам и интересно, РНР, есть Stomp - реализация библиотек для разных скриптовых языков, которая превращает сообщения в формат JMS. Кстати, если необходимо обеспечить безопасную коммуникацию и передачу сообщений, можно использовать SSL.

MQS  (Minimalist Queue Services) - проект, если можно так сказать, с друго конца. Это небольшая система, написанная на Perl, организовывает систему очередей сообщений, используя XML-RPC протокол, сами сообщения могут хранится как в любой базе данных, так и в файлах. К сожалению, по всей видимости, проект заброшен, так как последняя новость на сайте датирована апрелем 2005 года, а текущая версия - 0.0.14.

Spread - еще одна реализация очереди сообщений, на этот раз на С++, и версии есть для различных платформ, включая Win32, Linux, BSD и MacOS. Текущая версия - 4.0.  Система распределенная и ориентирована на высокопроизводительные системы, где клиентов и, соответственно, сообщений, очень много. Заявлена поддержка, в последней 4.0 версии, технологии Virtual Synchrony.   Что интересно - в поставку сразу включены бинарные версии для нескольких платформ, а также встроенные интерфейсы для некоторых языков - C/C++, Java, Perl, Python, Ruby. Странно, что четвёртого Р - РНР, среди них нет, но существует расширение в PECL, которое реализовывает весь интерфейс Spread API. Текущая версия 2.1 и достаточно новая, значит проект развивается.  Существуют и реализации для других языков, в том числе и альтернативы встроенным интерфейсам, поэтому посмотрите на список здесь, там даже для MS Excel есть расширение. Среди интересных проектов - модуль mod_log_spread для Apache, позволяющий собирать логи доступа с нескольких веб-серверов.

RabbitMQ - высокопроизводительная платформа, написанная на Erlang, основанная на Open Telecom Platform, а значит - очень надежная и масштабированная система, часто применяемая в телекоммуникационных приложениях и других подобных системах. Есть интерфейс только для Java и C++. Система поддерживает стандарт AMQP  (Open Standard for Messaging Middleware). Система интересная, знать бы только Erlang, хотя что-то мне подсказывает, что проектируя весь серверный модуль на этой платформе, мы получили бы много "плюшек", в частности, на этой же платформе написан самый популярный Jabber-сервер ejabberd, который также можно применять в он-лайн игровых проектах.

Beanstalkd - также интересный проект, созданный в рамках разработки одного из приложений для социальной сети Facebook, которым пользуется около 10 млн человек (приложением, не сетью). Это специализированный сервер для хранения и обработки очередей заданий, использующий хранение данных в памяти для обеспечения скорости, однако в ущерб отказоустойчивости. Этот проект очень похож на уже ранее описанный нами MemcacheQ, да и сами разработчики выражают благодарность создателям memcached за принципы архитектуры и протокол. Система предназначена для создания асинхронной очереди обработчиков пользовательских задач, которые не требуют немедленного ответа, например, отсылки писем, фоновые обработки и т.п. Существуют клиентские API для различных языков, в том числе для Erlang, OCaml, Perl, PHP, Python, Ruby. Для РНР библиотека расположена здесь и пока имеет версию 0.11, сама разработка началась всего пару месяцев назад (судя по регистрации проекта).  Детальнее можно почитать отличный обзор: Beanstalk Messaging Queue Сервер написан на С, что обеспечивает высокую скорость работы, однако специфика проекта в плане хранения всех данных в оперативной памяти не подойдет для тех сфер, где остро необходима максимальная отказоустойчивость, пусть даже ценой дополнительного ПО и затрат на хранение данных в базе.

Пока это все. А как же РНР, спросите вы? Описанные решения основаны на сторонних платформах, однако имеют библиотеки для обеспечения коммуникации с РНР-приложениями. Но существуют и нативные, РНР решения такого рода приложений, конечно, не полные аналоги, здесь уже скажется специфика среды РНР, однако достаточные для многих областей применения. О таких решения я расскажу вам в продолжении этого материала.

  1. 18 ноября 2008 в 20:53 | #1

    Отличная статья, как раз кстати!

    > О таких решения я расскажу вам в продолжении
    > этого материала.

    Это был обзор, а ты именно что выбрал? Или пока ещё выбираешь? Если сможешь расскажешь что именно выбрал. А о решениях на PHP тоже интересно почитать!

    P.S. Сделай плизз, чтобы в title было название статьи а не только блога, ибо в закладках не удобно ориентироваться и тебе для SEO полезно будет.
    P.S.S. И желательно немного увеличить шрифт, а то читать трудно. (мне самому правда не помешает то же самое 🙂

  2. 18 ноября 2008 в 22:39 | #2

    Я пока не выбирал, я параллельно с статьями исследую сам вопрос, потому и пишу. Так что ещё в процессе выбора и рассмотрения самого принципа архитектуры.

    гмм.. тайтл… ааа надо шаблон подправить… постараюсь сделать, спасибо!

  3. Давид Мзареулян
    19 ноября 2008 в 04:48 | #3

    Так чем они друг от друга отличаются-то, кроме разных комбинаций слов «масштабируемость», «производительность» и прочего бла-бла?

  4. 19 ноября 2008 в 07:06 | #4

    Ранее был не знаком с этими технологиями, но после слов:
    >для создания асинхронной очереди обработчиков >пользовательских задач, которые не требуют немедленного >ответа, например, отсылки писем, фоновые обработки и т.п.
    «очнулся» и появился живой интерес к этой теме 🙂
    Было бы интересно прочитать у вас обзоры менее навороченных MQ-проектов. А ещё было бы хорошо упомянуть примеры применения.

  5. 19 ноября 2008 в 12:08 | #5

    Давид Мзареулян — ну например, платформой, интерфейсами, возможностями обработки сообщений, маршрутизации, а также поддержкой persistent queue, для примера

  6. 20 ноября 2008 в 01:08 | #6

    adw0rd — странно, но не хочет выводить в тайтле название поста, хотя все настроено — перерыл все и даже плагин специальный стоит

  7. 20 ноября 2008 в 01:37 | #7

    Посмотрите в шаблоне темы, файл single.php и header.php. Что-то типа или

  8. 20 ноября 2008 в 01:41 | #8

    the_title() или single_post_title()

  9. 20 ноября 2008 в 01:51 | #9

    adw0rd — О! Заработало! Оказалось, плагин All-in-SEO-pack должен был перезаписывать тег тайтла, но не делал этого. Удалил там опцию, и вручную вставив вывод имени поста, если это страница одиночной записи — и все заработало. спасибо еще раз.

  10. 20 ноября 2008 в 10:00 | #10

    Да незачто, тебе за статью спасибо! И за блог в целом 🙂

  11. 21 ноября 2008 в 14:53 | #11

    Было бы интересно прочитать у вас обзоры менее навороченных MQ-проектов. А ещё было бы хорошо упомянуть примеры применения.

  12. 21 ноября 2008 в 14:59 | #12

    Илья, примеры я там дал, да и это универсальное решение, каждый себе думает, как и где применить. Это средства уровня архитектуры, а если архитектор не знает, зачем ему это, то и не за чем 🙂 В общем случае — для организации асинхронного, распределенного, масштабируемого обмена данными/сообщениями между отдельными компонентами одной системы. Кстати, среди рассмотреных есть и очень простые системы, буквально в одном-двух файлах. тот же MemcacheQ. Другие проекты я рассмотрю чуть позже, в продолжении материала

  13. 6 января 2009 в 13:33 | #13

    I wish I could read it 🙁

  14. Gleb
    7 января 2009 в 16:18 | #14

    Я вот как раз вчера столкнулся с необходимостью делать клиент к ActiveMQ на шарпе или дельфи. И похоже, что имеющийся, например, Apache.NMS не в состоянии подключиться к MQ через SSL. Вы случайно не в курсе касательно данной проблемы?

  15. 7 января 2009 в 23:28 | #15

    Gleb, сам сервер умеет и может, написано в разделе протоколов/транспортов: http://activemq.apache.org/uri-protocols.html STOPM также может работать по SSL (http://activemq.apache.org/stomp.html, там отдельно есть раздел про SSL), клиент для C# есть (http://stomp.codehaus.org/DotNet) и для Delphi (http://stomp.codehaus.org/Delphi)

    работу с SSL поддерживает и RabbitMQ

Комментирование отключено.
Developers.org.ua