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

Я хотел бы услышать больше о реальном опыте применения с MongoDB в качестве службы очереди, если вы использовали MongoDB для этой цели, могли бы вы поделиться своими мыслями, а также средой, в которой он использовался?

6 ответов


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

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

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

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

обновление

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

  1. переместить это сообщение в другое, коллекция ошибок очереди сообщений или..

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

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


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

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

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


здесь большая статья объяснение того, как кто-то использовал репликацию mongoDB в качестве очереди.

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


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


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

Это часть статьи это оценивает производительность различных систем очередей сообщений.

одиночн-поток, установка одиночн-узла достигает 7 900 msgs/s отправленных и 1 900 msgs/s полученных.


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