MongoDB作为队列服务？

我很想了解更多关于MongoDB作为队列服务的实际应用体验，如果您为此使用MongoDB，能否分享您的想法以及使用它的环境？

我将MongoDB用作电子邮件发送的队列服务。 很快它将以以下方式工作：

当新消息出现时，我将其存储在mongodb中

然后，后台作业通过原子操作从mongodb加载消息，并将标志

Processing

设置为true，因此它不会处理同一消息两次（因为我的后台作业并行运行多个线程）

发送电子邮件后，我将从mongodb中删除该文档

您还可以记录每条消息的失败次数，并在尝试3次失败后将其删除

一般来说，我使用mongodb作为队列服务只有一个原因：因为我需要按照指定的时间表发送电子邮件（每条消息都包含应该发送的时间的信息）

如果您没有任何时间表，并且需要立即处理消息，我建议您查看现有的，因为它们可能会处理您在没有深入了解消息队列的情况下可能看不到的所有情况

更新 当后台作业在消息处理过程中崩溃时，您可以执行以下操作：

将此消息移动到另一个、消息队列错误集合或

增加消息中的处理尝试次数计数器，并再次分配状态“新建”，以再次尝试处理该消息。只需确保后台作业是幂等的（可以多次处理同一消息，并且不会损坏数据）和事务性的（当作业失败时，必须撤消所做的更改。如果有的话）。当作业在5次尝试（配置值）后失败时，执行#1

一旦修复了消息处理的bug，您可以通过指定“新建”状态并移动到消息队列来再次处理它，或者删除此消息。这实际上取决于业务流程

下面是一个示例，解释了有人如何使用mongoDB的复制oplog作为队列

---

您可以对不同的集合执行相同的操作。主要的建议似乎是使用a-mongo驱动程序，它有有效的方法等待一个有上限的集合，这样客户就不会不断地进行轮询。

我知道这个问题是从2012年开始的，但是在我自己的研究中，我发现了这篇文章，我只想告诉其他任何用户，serverdensity的开发人员取代了rabbitmq，代之以使用mongodb的简单排队系统

这里有一篇详细的文章：

---

我搜索了很多，找到了JavaScript版本。但是我想要一个围棋版本，所以

---

Go中的一个简单实现，包括轮询消息的管理器：

这里是一个简单的消息队列

它是评估各种消息队列系统性能的一部分

单线程、单节点设置可实现7900毫秒/秒的发送和1900毫秒/秒的接收

这是我的 它的工作原理是在封顶集合上使用尾随光标或轮询正常集合。

---

在一些项目中使用了它，在这些项目中，我希望简化我的堆栈并获得相当好的结果。当然，正如有人已经提到的，直到您达到了原子查找和修改的极限，但这可以通过各种技术来解决

几年来，我一直在改进redis和/或mongodb之上的作业队列实现，并对负载平衡和HA提供了良好的支持。我决定使用node.js进行实现，这似乎非常适合。我提出了两个实体：

• node.js库（）能够在redis和mongodb之上管理队列和集群。它还提供了mongodb上队列的实现，通过对mongodb的读写进行bucket处理，突破FindModify限制

• node.js（）中还提供了一个服务器，它基本上在node.js库的顶部提供STOMP和REST iterface。这台服务器可以被看作是SQS之类的替代品

---

显然，该库仅限于node.js，但服务器可以从几乎任何可以说HTTP的地方使用。在MongoDB之上而不是在专用MQ之上构建此服务的另一个动机是，它使您无需再从应用程序中与另一个服务交互。唯一的主要问题是吞吐量，它将低于专为MQ而设计的性能。我还在Mongo上寻找一个好的Q impl。如果您的后台作业在将处理标志设置为true之后，但在它能够处理消息之前崩溃或重新启动，您会怎么做？@cirrus这也是我想知道的。我计划区分三种状态（新状态/进行中状态/完成状态），并保留最后修改日期/时间。然后，新员工（或专用garbace gollector）可以开始查找“正在进行”的消息，这些消息的最后修改时间远远超过过去，然后将其重置为“新”。@andrew。这些都是用q系统解决的问题。我只是想知道你的impl采用了什么方法。这不是消息处理中的一个“bug”，我考虑的更多的是使处理能够适应瞬态过程。我不知道在Mongo做一个全功能Q的最好方法是什么。看我的Q：@Marian我想你说得对。不过，您可能仍然需要幂等运算，因为您仍然可以多次处理同一消息。您将至少得到一次语义。不幸的是，您链接到的页面已不再可用available@Tilo回复太迟了，网络档案中的链接：我们已经达到了MongoDB中原子查找和修改操作的极限，并转移到Kafka：版主再次伤害了社区，你为什么要关闭这样的问题？真是德怀特·施鲁特