NServiceBusIn bus transports like MSMQ there is no central place from which multiple instances of an endpoint can receive messages concurrently. Each instance has its own queue so scaling out requires distributing of the messages between the queues.
The process of distributing the messages can be performed on the sender side. In this case the sender of the message knows about all the instances of the receiver. Refer to the Scaling out with sender-side distribution article for more details.
Distribution can be also done via a dedicated distributor process. Refer to Scaling out with distributor for details.
Following table compares both approaches:
| Sender-Side Distribution | Distributor |
|---|---|
| Sender aware of scaling-out of receiver | Sender ignorant of scaling-out of receiver |
| Almost liner scaling with number of workers | Limited scaling |
| No flow control | Flow control via ready messages |
| No automatic worker failure detection | Worker failure detection via ready messages |
| Round-robin load balancing | Fair load balancing |
MSMQ remote receive
Version 4 of MSMQ, made available with Vista and Server 2008, can perform remote transactional receive. This means that processes on other machines can transactionally pull work from a queue on a different machine. If the machine processing the message crashes, the message roll back to the queue and other machines could then process it.
The biggest problem with 'remote transactional receive' is that it gets proportionally slower as more worker nodes are added. This is due to the overhead of managing more transactions, as well as the longer period of time that these transactions are open. In short, the scale out benefits of MSMQ Version 4 by itself are quite limited.
