Краткий обзор 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, да и сам проект серьезный и функциональный.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 6
    • +1
      К вопросу архитектуры, думаю, нужно подходить изначально из требований. Например, обработка асинхронных (как и сихронных) сообщений накладывает свои ограничения, например, по скорости, памяти, менеджменту соединений и т.п. Нужно исходить из конкретных задач. Например, у нас на проекте изначально MQ (WebSphere) покрывала все требования (30'000 сообщений в час). Но с увеличением требований по скорости обработки сообщений 300'000 сообщений в час нужно уже пересматривать архитектуру: где-то еще распараллелить, а где-то убрать отслыку сообщения и работать напрямую; где-то использовать вместо MQ естественный общий ресурс — базу данных; отказаться от персистентности сообщений и т.д. Какую пропускную способность Вы предполагаете на игровом сервере? Насколько затратным будет выполнение одного сообщения?
      • 0
        Знаете, еще не прочитал Вашу вторую статью, но читал первую. Для решения задач с высокой нагрузкой, а именоо на это вы и нацеливаете сервис думаю Erlang для Вас наиболее оптимальный выбор.
        • 0
          да я тоже думаю, но тута еще стоит подумать, как я буду использовать функционал… может стоит на некоторые задачи выделить отдельные сервера… или вовсе обойтись… в общем пока это исследование различных архитектур. а Ерланг сильно уже иная технология для меня :)
          • 0
            На highload достаточно интересно рассказывали про PgQ (http://pgfoundry.org/projects/skytools/) ребята из скапа, как средство для масштабирования мне понравилось. Но я больше на мускуле специализируюсь поэтому реально в работе не применял.
        • 0
          единственное чего не умеет ezComponents Это хранить саму очередь а отправлять сообщения между серверами это помойму вполне легко сделать на базе ezComponents, сама очередь из себя будет представлять проосто последовательность хттп запросов к другому серверу если это межсерверное взаимодействие сделать можно по средствам RPC
          • 0
            да, вы правы. ну там не столько очередь же сообщений, сколько стек функций, поэтому там и не надо персистентности. Но я уже подумываю сделать подобную систему

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.