'How should RabbitMQ message processing be parallelized when using a .NET Worker Service?
I created a .NET Worker Service which binds to an existing RabbitMQ instance, pulls a message representing a job off the queue, does that job's data processing, and then alerts the client which originally requested the job. It works great. Now I'm ready to deploy the Worker Service to Windows Server, but I want to take advantage of some horsepower on the server - how do I parallelize the processing of messages from RabbitMQ? Two solutions come to mind:
- Start two or more instances of my Service Worker queue processor, with each instance simultaneously processing messages from the queue one at a time.
- Tweak the params to the
BasicQos()method and pull two or more messages off the queue, process each as an async Task, and await all before again fetching more messages from the queue.
The second option seems like it could be problematic, should there be a case where one of the async tasks runs excessively long impacting performance, or one task causes an error that prevents the other tasks from being processed completely. Is one of these approaches a better idea than the other? Or is there an established best practice/convention to accomplish parallel processing of RabbitMQ messages with such a service?
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|