Alpha-Beta-Release Blog

Приветствуем наших читателей! Сегодня мы продолжаем исследовать тему такого класса ПО как очереди сообщений применительно к РНР веб-системам. В прошлой статье мы рассмотрели некоторое ПО, в частности представителей как самой верхней области (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, да и сам проект серьезный и функциональный.