使用NServiceBus分销商流程的优势

时间:2010-03-30 15:47:38

标签: nservicebus

我学习了如何在文章Getting the NServiceBus Distributor Working的FullDuplex示例中使用NServiceBus分发服务器进程,这让我感到奇怪:

为了使用经销商,我需要以下队列:

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

这意味着为了与分发服务器进行扩展,每次我想扩展到另一台服务器时,我需要一个独立的配置文件,它指定一个新的服务器消息总线队列。如果我想缩小规模,我会留下遗留的配置文件和队列。

这似乎是不必要的,因为在我没有经销商的测试期间,我注意到如果我旋转另一个服务器实例(只需在调试时选择Visual Studio中的调试启动新实例)那么新的程序实例(这是相同的二进制文件和具有相同的配置文件和相同的输入队列)似乎与第一个实例相当好地负载平衡。当客户端发出请求时,这些请求似乎在服务器之间来回传递。

如果此负载平衡有效,则意味着我可以通过添加指向同一高可用性输入队列的重复实例来扩展,而无需任何额外的资源分配。那会容易得多!

那么,经销商的优势是什么?

我唯一的猜测来自Distributor documentation,它指出分销商“设计永远不会压倒任何配置为接收工作的工作节点”。我不能通过在每个工作者上使用MsmqTransportConfig的NumberOfWorkerThreads属性来控制工作进程可以咀嚼的工作量吗?

1 个答案:

答案 0 :(得分:3)

由于分发器主要用于扩展单个消息类型的处理,并且遵循类似地隔离了该消息类型的处理的建议,因此我们可以将许多队列命名为与消息类型相同:so而不是'distributordatabus','server1messagebus'和'server2messagebus',所有这些都将被命名为相同,但每个都将在不同的机器上。然后我们将分配器的控制总线命名为类似于消息类型,但只是带有'_control'后缀(或类似的东西)。

  

那么,经销商的优势是什么?

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