使用NServiceBus分发进程的优势

我从文章中了解到如何在FullDuplex示例上使用NServiceBus分发进程，这让我想知道：

为了使用分发服务器，我需要以下队列：

• MyClientInputQueue-单个客户端的输入队列
• distributordatabus—分发服务器要向其发送消息的队列
• distributorcontrolbus—分发服务器用于存储其状态的内容
• server1messagebus—第一个服务器实例的输入队列
• server2messagebus—第二个服务器实例的输入队列

这意味着，为了使用分发服务器进行扩展，每当我想使用另一台服务器进行扩展时，我都需要一个独立的配置文件来指定一个新的服务器消息总线队列。如果我想缩小规模，我还有残留的配置文件和队列

这似乎是不必要的，因为在没有分发服务器的情况下进行测试时，我注意到如果我启动了服务器的另一个实例（只需在调试时在Visual Studio中选择Debug Start New instance），那么新的程序实例（它是相同的二进制文件，具有相同的配置文件和相同的输入队列）似乎与第一个实例的负载平衡相当好。当客户端发出请求时，请求似乎在服务器之间来回移动

如果这种负载平衡是有效的，这意味着我可以简单地通过添加指向同一高可用性输入队列的重复实例来扩展，而不需要任何额外的资源分配。那就容易多了

那么，分销商的优势是什么呢

---

我唯一的猜测来自，其中指出分发服务器“设计为永远不会压倒任何配置为从其接收工作的工作节点”我不能在每个工作进程上使用MsmqTransportConfig的NumberOfWorkerThreads属性来控制一个工作进程可以完成多少工作吗？

因为分发服务器主要用于扩展单个消息类型的处理，按照类似地隔离该消息类型的处理的建议，我们可以将许多队列命名为与消息类型相同的队列：因此，与“distributordatabus”、“server1messagebus”和“server2messagebus”不同的是，它们的名称都相同，但每个队列位于不同的机器上。然后，我们将分发服务器的控制总线命名为与消息类型类似的名称，但仅使用“\u control”后缀（或类似的名称）

那么，分销商的优势是什么呢

---

它用于扩展到许多无法共享输入队列的机器。

因为分发服务器主要用于扩展单个消息类型的处理，并遵循类似隔离该消息类型处理的建议，我们可以将许多队列命名为与消息类型相同的队列：因此，它们的名称都相同，而不是“distributordatabus”、“server1messagebus”和“server2messagebus”，但它们都位于不同的机器上。然后，我们将分发服务器的控制总线命名为与消息类型类似的名称，但仅使用“\u control”后缀（或类似的名称）

那么，分销商的优势是什么呢

---

它用于扩展到许多无法共享输入队列的机器。

也许你应该将问题发布到NSB讨论组，这里没有很多人使用NSB。也许你应该将问题发布到NSB讨论组，这里没有很多人使用NSB。