[SERVER-3385] Publish/Subscribe (Message queue) functionality Created: 07/Jul/11 Updated: 06/Dec/22 Resolved: 03/Dec/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | None |
| Fix Version/s: | features we're not sure of, 3.6.0 |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Victor Boivie | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Done | Votes: | 28 |
| Labels: | message.queue, pub.sub, publish.subscribe | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Message queue functionality is something that is/was traditionally handled by a dedicated message broker, i.e. RabbitMQ when using AMQP as protocol. A growing trend is to use solutions that are easier to setup and maintain, such as pub/sub solutions (quite many of them). There are also NoSQL databases that have added such extensions, and the most common example is Redis. MongoDB could fit very well in this world. (Capped) collections with polling subscribers can already today be used to simulate a message queue, but this is just a workaround. Having native support for publish/subscribe in MongoDB (with blocking readers, for example) can be used to add message queues without having to setup and maintain separate solutions and keep the same concepts as the application developers have grown used to, like the rich expressiveness of documents as messages. The advantages of replica sets can be used to add reliability and durability of messages in a queue (well, this would rule out capped collections). An API would have to be created, and the concepts would have to be defined. |
| Comments |
| Comment by Tommaso Tocci [ 03/Dec/21 ] |
|
ChangeStreams have been added since 3.6 as part of PM-89. |
| Comment by Koala Yeung [ 12/Apr/12 ] |
|
This will be a really awesome feature! I don't really want to run both Redis and MongoDB in my stack but I need Redis's Pubsub to scale my service. I hope MongoDB will have pubsub soon. |
| Comment by Artur Ejsmont [ 06/Apr/12 ] |
|
+1 YES yes and one more time yes. This would be an awesome tandem and plus for MongoDB if it could replace simple 1-1 / 1-n persistent queues. |
| Comment by William Payne [ 01/Feb/12 ] |
|
+1; I am currently using tailing & capped collections. Pub/sub would help me to improve the testability of my logic. |
| Comment by Vladimir [ 15/Jan/12 ] |
|
+1 |
| Comment by David Salgado [ 16/Sep/11 ] |
|
+1 this would be really helpful for me. I'm planning to use multiple (around 300) MongoDB instances partially as a distributed smart cache. pub/sub support would make it much easier to keep all the nodes in sync. |
| Comment by Harry Mexxian [ 17/Aug/11 ] |
|
+1 as well Submitted the same request before seeing this. |
| Comment by Fredrik Björk [ 17/Jul/11 ] |
|
+1 for Pub/Sub support in MongoDB! |