Enchantner
Сен. 28, 2011 17:47:48
Не хочется раздувать холивар, но вот такой вопрос.
Есть асинхронный обработчик (например, gevent), который висит на сокете и формирует очередь сообщений для воркеров. Вопрос - что лучше использовать для хранения очереди? Для чего проще организовать асинхронное взаимодействие поверх event loop?
И да, данные - важные и persistent, то есть нужны дампы на диск, а потери пакетов недопустимы. Сейчас склоняюсь к Redis, но я для него не знаю асинхронного биндинга. Он есть для MongoDB (asyncmongo поверх tornado loop), но она вроде как не сильно стабильная, да и хочется чего-нибудь попроще. Про последний вариант вообще знаю очень мало. Может, кто что посоветует?
o7412369815963
Сен. 28, 2011 19:09:02
Юзаю tornado + asyncmongo, мне нравиться, другие варианты не пробовал. Сейчас в базе около 100к документов, багов не замечено.
кстати выборка документов (с join'ами) в asyncmongo гораздо быстрее чем в синхронном варианте, т.к в синхронном “джойны” достаются последовательно, а в асинхронном параллельно.
Андрей Светлов
Сен. 28, 2011 19:12:46
Если использовать hiredis-py — создание асихронного редис клиента не представляет никаких проблем.
Sleepwalker
Сен. 29, 2011 10:28:27
Под Twisted для Redis есть асинхронный клиент - txredis
ziro
Сен. 29, 2011 10:43:15
Если хранение очереди критически важно, то ПМСМ наилучший вариант это связка rabbitmq+pika. pika кстати умеет с amqp работать как синхронно, так и асинхронно (поверх tornado и asyncore). Ну и для обработчиков сообщений в этом случае естественно напрашивается celery.
Enchantner
Сен. 29, 2011 10:55:10
ziro
я думал про него, но если rabbitmq падает сам (если падает воркер - это еще ничего) - то вся очередь безвозвратно теряется. Этого допустить никак нельзя. В Redis эта проблема более-менее решена, кроме того, по нему проще вести статистику (это тоже важно).
Enchantner
Сен. 29, 2011 12:08:46
Андрей Светлов
а как организовать асинхронную вставку данных, а не только чтение?
ziro
Сен. 29, 2011 12:19:57
Ну как бы там есть разные сценарии по работе с сообщениями - как “быстро, но стремно” так и “медленно, но надежно”, так что безвозвратно теряется там только то, что разрешено потерять в случае чего. Смотрите здесь -
http://www.rabbitmq.com/faq.html#scenarios Возможно Вам просто флажок “persistent” надо поставить для сообщений.
Да, кстати, Reliable persistent message delivery примерно соответствует тому способу хранения, который использует redis.