Python-сообщество

Не хочется раздувать холивар, но вот такой вопрос.

Есть асинхронный обработчик (например, gevent), который висит на сокете и формирует очередь сообщений для воркеров. Вопрос - что лучше использовать для хранения очереди? Для чего проще организовать асинхронное взаимодействие поверх event loop?

И да, данные - важные и persistent, то есть нужны дампы на диск, а потери пакетов недопустимы. Сейчас склоняюсь к Redis, но я для него не знаю асинхронного биндинга. Он есть для MongoDB (asyncmongo поверх tornado loop), но она вроде как не сильно стабильная, да и хочется чего-нибудь попроще. Про последний вариант вообще знаю очень мало. Может, кто что посоветует?

Юзаю tornado + asyncmongo, мне нравиться, другие варианты не пробовал. Сейчас в базе около 100к документов, багов не замечено.

кстати выборка документов (с join'ами) в asyncmongo гораздо быстрее чем в синхронном варианте, т.к в синхронном “джойны” достаются последовательно, а в асинхронном параллельно.

Если использовать hiredis-py — создание асихронного редис клиента не представляет никаких проблем.

Под Twisted для Redis есть асинхронный клиент - txredis

Если хранение очереди критически важно, то ПМСМ наилучший вариант это связка rabbitmq+pika. pika кстати умеет с amqp работать как синхронно, так и асинхронно (поверх tornado и asyncore). Ну и для обработчиков сообщений в этом случае естественно напрашивается celery.

ziro
я думал про него, но если rabbitmq падает сам (если падает воркер - это еще ничего) - то вся очередь безвозвратно теряется. Этого допустить никак нельзя. В Redis эта проблема более-менее решена, кроме того, по нему проще вести статистику (это тоже важно).

Андрей Светлов
а как организовать асинхронную вставку данных, а не только чтение?

Ну как бы там есть разные сценарии по работе с сообщениями - как “быстро, но стремно” так и “медленно, но надежно”, так что безвозвратно теряется там только то, что разрешено потерять в случае чего. Смотрите здесь - http://www.rabbitmq.com/faq.html#scenarios Возможно Вам просто флажок “persistent” надо поставить для сообщений.

Да, кстати, Reliable persistent message delivery примерно соответствует тому способу хранения, который использует redis.

Отредактировано (Сен. 29, 2011 12:22:26)