Асинхронная очередь сообщений — какая комбинация?

Я пытался определить, какую комбинацию пакетов использовать для службы push-сообщений за веб-сайтом... Моя текущая идея состоит в том, чтобы использовать Tornado + Socket.IO (Tornadio) и ZMQ. Но я также рассматривал возможность участия Mongrel2. Также есть аналогичный проект под названием Brubeck, который берет начало от Tornado, используя ZMQ и Eventlet. Мой главный вопрос заключается в следующем... Я пытаюсь понять, в чем заключалась бы польза от Mongrel2, если бы я использовал Tornado. Нужен ли в таком случае Tornado? В тот момент я подумал, что просто напишу обработчик Python Mongrel2, и все. Я хотел бы сосредоточиться на использовании веб-сокетов/jssockets, поэтому использование Socket.IO было интересным, поскольку он обрабатывает всю обратную совместимость под капотом для вас.

Если рассматриваемые инструменты включают в себя: Python focus, Tornado, Mongrel2, ZMQ, Brubeck и Socket.IO, какие рекомендации вы могли бы дать для лучшего сочетания для поддержки веб-сокетов? Наличие Mongrel2 было действительно привлекательным для идеи масштабируемости и просто включения большего количества обработчиков Python.

Обновление от 01.01.2012

Сначала шел с Tornado + TornadIO + ZeroMQ и имел рабочий сервер. Но в конце концов я выучил Go (www.golang.org) и переписал свой сервер, используя чистый Go со встроенным в параллелизме. В итоге оказался быстрее, чем Python, более чем в 10 раз, даже с большим количеством функций, чем моя версия Python: http://www.justinfx.com/2011/07/28/go-language-for-python-programmers/

Кажется, что он продолжает набирать скорость, поскольку команда Go выпускает больше релизов для Go 1.0.


python messaging tornado zeromq mongrel
person jdi    schedule 12.04.2011    source источник
comment
В чем проблема со стандартной очередью сообщений, такой как RabbitMQ, - работающей с возрастом и надежной ракетой.   -  person Andreas Jung    schedule 12.04.2011
comment
Раньше я использовал ZMQ для модуля Python RPC между приложениями. Мне очень понравилось, и я хочу остаться с ним. Он также является ядром Mongrel2 и имеет большую поддержку в Tornado.   -  person jdi    schedule 12.04.2011
comment
Вы спрашиваете, какие инструменты выбрать, но вам нужно немного объяснить (и обобщить) проблему, которую вы пытаетесь решить.   -  person skrat    schedule 12.04.2011
comment
Для веб-сайта нам нужно двунаправленное соединение, чтобы пользователь мог подписаться сразу на несколько каналов сообщений. И иметь возможность отправлять сообщения в каналы. Итак, находятся ли они в чате один на один с другим пользователем ... или получают сообщения в реальном времени, связанные с текущим форумом, на котором они находятся. Мы хотели сосредоточиться на веб-сокетах, а не на длительных опросах. По сути, это просто возможность pub-sub с произвольным количеством дополнительных каналов. Я полагал, что с их подключением к сокету они могут указать нужные каналы, и для них можно запустить подпрограмму в обработчике сервера.   -  person jdi    schedule 12.04.2011
comment
Я использую tornado+socketio(tornadio)+redis(через brukva) для pub/sub.   -  person Mikhail Korobov    schedule 27.04.2011
comment
@Mike - Каковы были ваши доводы в пользу Redis, а не Zeromq? Это выглядит очень интересно.   -  person jdi    schedule 01.07.2011
comment
@Justin: установить Redis стало еще проще, и его можно использовать не только для публикации/подписки, но и для быстрого хранения данных. Привязки Python для zeromq обеспечивают скопированную реализацию IOLoop торнадо, и это также усложняет систему (а что, если торнадо изменит IOLoop?), brukva использует стандартный IOLoop. Я думаю, что для этого решения есть веские причины, но Redis был проще и работает хорошо. Идея zeromq очень хороша, и я думаю, что в конечном итоге буду использовать ее в одном из будущих проектов.   -  person Mikhail Korobov    schedule 02.07.2011
comment
Я полагаю, что единственный оставшийся вопрос заключается в том, какова производительность Redis pub/sub по сравнению с zeromq. Я не могу найти никаких реальных данных о нем. Но то, что я нашел, предполагает, что Redis, вероятно, ограничивает около 100 тысяч сообщений в секунду, тогда как ZeroMQ утверждает, что около 1 миллиона+. Было высказано предположение, что Redis идеален до тех пор, пока реализация не ставит цель работать в абсолютно реальном времени. Таким образом, это может отлично подойти для чата, но, может быть, не очень хорошо для продвижения тонн событий с высокой скоростью?   -  person jdi    schedule 15.07.2011

Ответы (2)


arrow_upward
0
arrow_downward

Звучит как работа для привязки Flash/Javascript. http://www.zeromq.org/bindings:javascript

Таким образом, у вас есть приложение ZMQ в браузере, которое является SUB для любых сокетов PUB, отправляющих соответствующие сообщения.

person Michael Dillon    schedule 01.07.2011
comment
На самом деле я спрашивал о реализации сервера, а не на стороне клиента. Кроме того, я не хочу полагаться на вспышку. Моя цель состояла в том, чтобы придерживаться приложений Python. - person jdi; 01.07.2011
comment
Если вы хотите работать в браузере, вы не можете использовать Python. Кроме того, привязка javascript просто использует объект flash для доступа к реальным сокетам. ZMQ довольно агностичен, поэтому Python легко использовать на сервере и другие вещи на клиенте. Но сначала создайте свой клиентский прототип на Python. - person Michael Dillon; 01.07.2011
comment
Спасибо за комментарий, но я думаю, что это не совсем мой вопрос. Я совершенно не беспокоюсь о клиенте. Я пытался выяснить мнение людей о комбинациях на стороне сервера для разработки очереди сообщений. В итоге я написал свой сервер с помощью Tornado + TornadIO + ZMQ. Пока что работает. Но теперь мне интересно переключиться на Redis для настойчивости. Я до сих пор не могу понять, была бы Mongrel2 лучшей базой или нет. Клиентский аспект - это все javascript через socket.io - person jdi; 05.07.2011

arrow_upward
0
arrow_downward

Я добавляю свое собственное обновление к этому вопросу в качестве ответа, так как я никогда не получал никаких других ответов, и поэтому я могу закрыть этот вопрос...

Сначала шел с Tornado + TornadIO + ZeroMQ и имел рабочий сервер. Но, в конце концов, я изучил Go (www.golang.org) и переписал свой сервер, используя чистый Go со встроенным параллелизмом. В итоге оказался быстрее, чем Python, более чем в 10 раз, даже с большим количеством функций, чем моя версия Python: http://www.justinfx.com/2011/07/28/go-language-for-python-programmers/

Кажется, что он продолжает набирать скорость, поскольку команда Go выпускает больше релизов для Go 1.0.

person jdi    schedule 28.02.2012