MongoDB как услуга очереди?

Ответ 1

Я использую mongodb в качестве службы очереди для отправки электронной почты. Вскоре он будет работать следующим образом:

• Когда приходит новое сообщение, я храню его в mongodb.
• Фоновая задача затем загружает сообщение из mongodb через атомную операцию findAndModify и устанавливает флаг Processing в true, поэтому он не обрабатывает одно и то же сообщение дважды (потому что мое фоновое задание запускает несколько потоков параллельно).
• Как только письмо отправлено, я удаляю документ из mongodb.
• Вы также можете подсчитать количество сбоев для каждого сообщения и удалить его после трех неудачных попыток.

В общем, я использую mongodb в качестве службы очереди только по одной причине: потому что мне нужно отправлять электронные письма по указанному расписанию (каждое сообщение содержит информацию о том, во сколько он должен быть отправлен).

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

Update

При сбое фонового задания при обработке сообщений вы можете выполнить следующие действия:

• Переместите это сообщение в другой, с ошибкой в ​​очереди сообщений или..

• Увеличьте счетчик попыток обработки в сообщении и снова назначьте статус "Новый", чтобы снова попробовать его обработать. Просто убедитесь, что фоновое задание является идемпотентным (может обрабатывать одно и то же сообщение несколько раз и не повреждать данные) и транзакцией (при неудачном выполнении задания вы должны отменить внесенные изменения. Если таковые имеются). Когда сбой задания после 5 попыток (значение конфигурации), выполните # 1.

• Как только ошибка с обработкой сообщений была исправлена, вы можете снова ее обработать, назначив статус "Новый" и переместившись в очередь сообщений, или просто удалите это сообщение. Это зависит от бизнес-процессов.

Ответ 2

Я знаю, что этот вопрос вернулся с 2012 года, но во время моего собственного исследования я нашел эту статью и просто хочу сообщить любому другому пользователю, что devs from serverdensity заменили rabbitmq в пользу простой системы массового обслуживания с mongodb.

Подробная статья приведена здесь:

https://blog.serverdensity.com/replacing-rabbitmq-with-mongodb/

Ответ 3

Вот отличная статья, объясняющая, как кто-то использовал mocoDB репликацию oplog как очередь.

Вы можете сделать то же самое с другой коллекцией. Основной совет, похоже, состоит в использовании capped collection - драйверы mongo имеют эффективные средства ожидания на закрытой коллекции, так что клиент не является" t постоянный опрос.

Ответ 4

Я много искал и нашел версию JavaScript https://github.com/chilts/mongodb-queue. Но я хочу версию go, поэтому была выполнена простая реализация в Go, включая менеджера для опроса сообщений: https://github.com/justmao945/mongomq

Ответ 5

Вот простая очередь сообщений реализация.

Это часть статьи которая оценивает производительность множества систем очереди сообщений.

Однопоточная, одиночная node настройка достигает 7 900 msgs/s и получает 1 900 msgs/s.

Ответ 6

Вот моя Python-реализация PubSub/queue Он работает либо хвостовым курсором на закрытой коллекции, либо опросом обычной коллекции. Использовал его несколько проектов, где я хотел упростить свой стек с неплохими результатами. Конечно, как уже упоминалось, до тех пор, пока вы не достигли пределов атомной findAndModify, но об этом можно позаботиться о различных техниках