I learned how to use an NServiceBus Distributor process on the FullDuplex sample from the article Getting the NServiceBus Distributor Working and it made me wonder:
In order to use the distributor, I need the following queues:
- MyClientInputQueue - the input queue for the single client
- distributordatabus - the distributor's queue to send messages to
- distributorcontrolbus - what the distributor uses to store its state
- server1messagebus - the input queue for the first server instance
- server2messagebus - the input queue for the second server instance
This means that in order to scale with the distributor, every time I want to scale out with another server, I need to have an independent config file which specifies a new server message bus queue. If I want to scale back down, I have vestigial config files and queues left over.
This seems unnecessary since, during my testing without the distributor, I noticed that if I spun up another instance of a server (just by selecting Debug-Start New Instance in Visual Studio while debugging) then the new program instance (which is the same binary and has the same config file and same input queue) seems to load balance fairly well with the first instance. The requests seem to go back and forth between servers when issued by the client.
If this load balancing is effective, it means I could scale out simply by adding duplicate instances pointing to the same highly available input queue, without requiring any additional resource allocation. That would be much easier!
So what, then, are the advantages of the Distributor?
My only guess comes from the Distributor documentation which states that the distributor is "designed never to overwhelm any of the worker nodes configured to receive work from it." Can't I just control how much work a worker process can chew through using the NumberOfWorkerThreads property of the MsmqTransportConfig on each worker?