Краткий обзор MQ (Messages queue) для применения в проектах на РНР. Часть 2
Приветствуем наших читателей! Сегодня мы продолжаем исследовать тему такого класса ПО как очереди сообщений применительно к РНР веб-системам. В прошлой статье мы рассмотрели некоторое ПО, в частности представителей как самой верхней области (Apache Active MQ, возможности которого находятся на уровне уже корпоративного ПО), так и достаточно простые варианты, например, MQS. Но не рассмотренными остались еще несколько достаточно интересных проектов, так что наше исследование продолжается.
Starling Message Queue - достаточно простая система, разработанная Blaine Cook из Twiitter-а на Ruby, поддерживает работу по Memcache протоколу, а значит позволяет подключаться и работать любой системе, понимающей этот протокол.
И последний проект, который я бы хотел рассмотреть, пришел к нас с области десктопных приложений. D-Bus это система межпроцессных и меж-программных взаимодействий, которая используется в оконной среде GNOME (детальнее в Wikipedia). Это, правда, не совсем чистая система MQ, D-Bus реализует концепцию сигналы/слоты (РНР реализация которой я считаю просто отличной в ezComponents и о которой напишу позже отдельно). Однако, просматривая листы рассылки этого проекта (а он является частью freedesktop.org) я наткнулся на сообщения, что есть реализация на РНР - D-BUS PHP Binding (это всего лишь коннектор к существующей системе). Но есть именно и порты на другие языки и платформы - на win32 системы, на .NET платформу, а также для Java, Python и другие языки, включая, конечно же, Perl. PHP версия называется PHP DBus и разрабатывается японскими разработчиками, текущая реализация имеет версию 0.1 (в виде модуля-расширения к РНР). Кстати, на основе этой библиотеки разработчики сделали прослойку над Skype API и могут взаимодействовать с установленным Skype прямо с РНР приложения.
Поскольку традиционно уже, системы сообщений наиболее развиты в мире Java, то РНР-проекты начинались с того, что создавались как врапперы над существующими Java-системами, обеспечивая их применение в РНР-приложениях. В частности, это связка двух проектов - Mantaray (на Java, распределенная P2P система для обмена сообщениями в распределенной сети поверх HTTP/HTTPS протоколов, правда, не обновляется с 2006 года) и PHPMQ, который является враппером над JMS-протоколом и использует для работы PHP/Java Integration extension, еще один интереснейший проект для организации совместной работы двух сред. К сожалению, рассматривать для серьезной работы обе системы не стоит, но в качестве исследовательских систем - вполне.
Dropr - это, пожалуй, первый и единственный серьезный проект полностью на PHP, который реализует очереди сообщения и применяется в реальных проектах. Позиционируется dropr как распределенный фреймворк для организации очереди сообщений. Система устойчива к сбоям сети или оборудования - на каждой ноде имеется свое независимое хранилище сообщений, в локальной файловой системе или базе данных. Dropr имеет распределенную архитектуру без единой точки отказа, и каждая нода может быть как сервером так и клиентом. Сам сервер выполнен в виде отдельного демона, с которым взаимодействует клиентский скрипт и РНР библиотека Dropr. Демон хранит сообщения локально или передает их по сети другому узлу, используя многопоточную загрузку при помощи cURL-модуля. Кстати, насколько я разобрался, демон выполнен так же в виде PHP-скрипта, который запускается отдельно и постоянно висит в памяти сервера.
Эта система была создана и используется в крупном проекте, Jimdo (по сути, сервис для простого создания и хостинга бесплатных страничек), в котором обеспечивает работу трехузлового географически распределенного кластера. К чести Dropr, в нем есть и некоторые служебные инструменты вроде просмотра состояния очереди и управления ею, однако, как замечают создатели, нет документации, кроме комментированного кода и руководств по установке и использованию.
К сожалению, это, наверное, и все проекты, которые я смог найти и посмотреть. Как видим, большинство из них написаны на Java, и если вы хотите как то использовать эту функциональность в РНР-приложениях, вам необходимо или библиотека-враппер и взаимодействие с демонами по сети или сокетах, или же использовать средства интеграции PHP/Java, что, однако, достаточно нетривиально (хотя таких вариантов есть уже, как минимум, три, и я о них напишу скоро отдельную статью). Если же это для вас неприменимо, рассмотрите работу с чистым РНР решениям Dropr, однако смиритесь с тем, что вам будет предоставлен только базовый функционал. В зависимости от потребностей и сценариев использования, можно рассмотреть все же выделенный сервер, например, на основе memcacheQ, который обеспечит быструю работу, надежность и унифицированный интерфейс, либо все же еще раз посмотреть в сторону более серьезных и сложных решений на базе Java, Erlang, C/C++ или Ruby, что может оказаться предпочтительнее, если у вас веб-проект на RoR.
И на последов, один из оригинальных проектов. Browser DBus Bridge - коннектор к шине D-Bus из JavaScript кода, который работает в Gecko/WebKit браузерах на системах, где поддерживается взаимодействие через D-Bus. Смысл проекта, вероятно в том, чтобы расширить взаимодействие веб-приложений с внешним ПО, например, автоматический запуск того же скайпа или другого ПО, установленного в системе. Однако здесь мы сталкиваемся с проблемами безопасности, поэтому полностью весь потенциал будет раскрыт только в собственных разработках, когда вы для своего приложения создаете клиент на основе Gecko движка и компилируете вместе с ним все необходимые библиотеки (ведь в обычном браузере на этом движке, даже запущенному на платформе с D-Bus, никакой поддержки работы с ней нет).
P.S. Отвечу на вопрос, заданный мне еще в предыдущей статье - какую же систему я выбрал. Пока никакую, рассматриваю и думаю вообще про архитектуру. Есть два варианта - запуск на платформе Java всех РНР приложений и работа напрямую с каким-либо Java-проектом, но с чем-то легче, чем Apache Active MQ, либо же использовать вообще другую, но близкую архитектуру, основанную на сигналах и слотах (аналогично к D-Bus), для нее тем более есть прекрасная реализация в ezComponents. Хотя это, конечно, не совсем уж MQ, но большую часть требований покроет. Именно же для взаимодействия по сети с другими нодами, здесь рассматриваем уже применение или memcacheQ, либо расширение ezComponents для взаимодействия с Dropr, либо применение выделенного сервера на основе Spread, тем более у него есть модуль к PHP, да и сам проект серьезный и функциональный.
У меня стоит такая задача…
Есть допустим цмс, и куча сайтов написанных на ней. Мы обновили например какой то модуль и должны разослать изменения на все сайты которые используют нашу цмс. Либо сделав под заказ модификацию модуля должны по запросу с сайта отдать им обновления.
Это все должно происходить автоматически либо с мин. настройкой через админ панель.
Что мне для решения задачи можно было бы заюзать? Не уверен, что очереди сообщений то, что надо, ведь прийдется файлы гонять.
не думаю, что освещенные здесь продукты будут полезны в решении данной проблемы. Я бы на вашем месте на стороне сайтов добавлял скрипт, который бы по крону стучался на ваш сервак и узнавал последнюю стабильную версию в своей ветке, если таковая находилась, то бекапился и забирал обновления.
Игорь, вам правильно отвечают — наверное эти системы не решат вашу задачу.
В админпанели вам надо сделать настройки автоопроса вашего сайта, а там выкладывать обновления ввиде архивов. и при запросе определять с какого домена пришел, или же использовать ключ клиента, определять какие обновления ему нужны. Пусть передается MD5 хеш последнего обновления, а CMS у себя хранит хещ. если они не совпадают, значит есть новые обновления, и CMS клиента должна скачать архив и распаковать его (это для примера).
Можно конечно и сделать в виде обычного рнр файла, внутри которого держать архив и пусть он скачивает и запускает его.