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

Question

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

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

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

1. прослушиватель сообщений (прослушивает сообщения из PHP и записывает их в очередь входящих сообщений)
2. Очиститель БД (читает сообщения из входящей очереди и сохраняет их в базе данных; из-за однопоточности SQLite)
3. Обработчик подключения MQ (поддерживает подключение к серверу MQ в режиме онлайн путем повторного подключения)
4. отправитель сообщений (собирает сообщения из базы данных SQlite и отправляет их на сервер MQ, затем удаляет их из базы данных)

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

PHP Redis-клиент здесь .

Клиент Python здесь .

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