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 messages between the queues.
The process of distributing the messages can be performed on the sender. In this case, the sender of the message knows about all the instances of the receiver. Refer to Scaling Out with Sender-side Distribution for more details.
Distribution can also be done via a dedicated distributor process. Refer to Scaling Out with the Distributor for details.
The following table compares each approach:
| Sender-Side Distribution | Distributor |
|---|---|
| Sender aware of scaled-out receiver | Sender ignorant of scaled-out receiver |
| Almost linear 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 |
| Available since core v6 & msmq v1 | Unsupported since core v7 / msmq v1 |
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 rolls back to the queue and other machines could then process it.
One 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.
