【问题标题】:Advantage of using NServiceBus Distributor process使用 NServiceBus Distributor 流程的优势
【发布时间】:2010-03-30 15:47:37
【问题描述】:

我从Getting the NServiceBus Distributor Working 文章中了解了如何在 FullDuplex 示例上使用 NServiceBus Distributor 进程,这让我很想知道:

为了使用分发器,我需要以下队列:

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

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

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

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

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

我唯一的猜测来自Distributor documentation,它指出分发器“设计为永远不会压倒任何配置为从中接收工作的工作节点”。我不能使用每个工作线程上的 MsmqTransportConfig 的 NumberOfWorkerThreads 属性来控制工作进程可以处理多少工作?

【问题讨论】:

  • 也许你应该把你的问题发布到 NSB 讨论组,这里没有多少人使用 NSB。

标签: nservicebus


【解决方案1】:

由于分发器主要用于扩展单个消息类型的处理,并且遵循类似隔离该消息类型处理的建议,我们可以将许多队列命名为与消息类型相同:所以而不是“distributordatabus”、“server1messagebus”和“server2messagebus”,它们都将命名相同,但每个都将位于不同的机器上。然后我们将分发器的控制总线命名为类似于消息类型,但只是使用“_control”后缀(或类似名称)。

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

它用于横向扩展至多台机器 - 不能共享输入队列。

【讨论】:

    猜你喜欢
    • 2011-03-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多