Прокси-сервер очереди сообщений в Python + Twisted

Я хочу реализовать облегченный прокси-сервер очереди сообщений. Его задача - получать сообщения от веб-приложения (PHP) и асинхронно отправлять их на сервер очереди сообщений. Причина этого прокси в том, что MQ не всегда доступен и иногда отстает или даже не работает, но я хочу убедиться, что сообщения доставляются, а веб-приложение немедленно возвращается.

Итак, PHP отправит сообщение прокси-серверу MQ, работающему на том же хосте. Этот прокси-сервер будет сохранять сообщения в SQLite для сохранения в случае сбоев. В то же время он будет отправлять сообщения из SQLite в MQ пакетами, когда соединение доступно, и удалять их из SQLite.

Насколько я понимаю, в этом сервисе есть следующие компоненты:

  1. message listener (listens to the messages from PHP and writes them to a Incoming Queue)
  2. DB flusher (reads messages from the Incoming Queue and saves them to a database; due to SQLite single-threadedness)
  3. MQ connection handler (keeps the connection to the MQ server online by reconnecting)
  4. message sender (collects messages from SQlite db and sends them to the MQ server, then removes them from db)

Я думал об использовании Twisted для №1 (TCPServer), но у меня возникла проблема с его интеграцией с другими точками, которые не управляются событиями. Интуиция подсказывает мне, что каждая из этих точек должна выполняться в отдельном потоке, потому что все они связаны с вводом-выводом и независимы друг от друга, но я мог бы легко поместить их в один поток. Тем не менее, я не смог найти никаких хороших и понятных (для меня) примеров того, как реализовать этот рабочий поток помимо основного цикла Twisted.

В качестве примера я начал использовать chatserver.py, который использует service.Application и объекты internet.TCPServer. Если я запускаю свой собственный поток до создания службы TCPServer, он запускается несколько раз, но останавливается и больше никогда не запускается. Я не уверен, почему это происходит, но, вероятно, потому, что я неправильно использую потоки с Twisted.

Есть предложения о том, как реализовать отдельный рабочий поток и сохранить Twisted? Вы думаете об альтернативных архитектурах?


person gasper_k    schedule 01.06.2010    source источник


Ответы (3)


Вы в основном думаете о написании специального расширения для вашего сервера обмена сообщениями, задача которого - обеспечить все гарантии надежности, которые вы о нем просили.

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

person Jean-Paul Calderone    schedule 01.06.2010
comment
Согласны, OP следует взглянуть на использование функций кластеризации RabbitMQ. - person Tom; 03.06.2010
comment
Спасибо, я понял, что это действительно лучший подход. Мне нужно время, чтобы все обдумать. - person gasper_k; 22.06.2010

Возможно, использование отдельного потока в Twisted для обхода блокирующего вызова - не лучший вариант для ваших денег, но иногда наименее злое решение оказывается лучшим. Вот ссылка, которая показывает вам, как интегрировать многопоточность в Twisted:

http://twistedmatrix.com/documents/10.1.0/core/howto/threading.html

Иногда, в крайнем случае, простота реализации оказывается быстрее, чем часы / дни исследований, которые могут оказаться напрасными.

person Joel M Ward    schedule 31.10.2010

Изящным решением этой проблемы было бы использование хранилища ключевых значений Redis. Это высокоскоростное постоянное хранилище данных с большим количеством клиентов - у него есть клиент php и python (если вы хотите использовать синхронизированный / пакетный процесс для обработки сообщений - он избавляет вас от создания базы данных, а также имеет дело с вашими историями о постоянстве Он отлично работает в средах Cywin / Windows + posix.

Клиент PHP Redis находится здесь.

Клиент Python находится здесь.

У обоих очень чистый и простой API. Redis также предлагает механизм публикации / подписки, если он вам понадобится, хотя похоже, что он будет иметь ограниченную ценность, если вы публикуете в несогласованной очереди.

person Ben Hughes    schedule 02.06.2010
comment
Это возможное решение, и мы уже рассматриваем Redis для чего-то еще, так что это не будет чем-то новым. Но, как я сказал выше, я все это переосмысливаю, потому что это кажется неправильным. Спасибо за ответ. - person gasper_k; 22.06.2010