使用NServiceBus Distributor进程的优点
我从文章 让 NServiceBus 分发器工作，这让我想知道：
为了使用分发器，我需要以下队列：
- MyClientInputQueue - 单客户端分发器数据总线的输入队列
- -分发器向分发器发送消息的队列
- controlbus - 分发器用来存储其状态的内容
- server1messagebus - 第一个服务器实例的输入队列
- server2messagebus - 第二个服务器实例的输入队列
这意味着为了与分发器一起扩展，每次我想要扩展到另一台服务器，我需要一个独立的配置文件，它指定一个新的服务器消息总线队列。如果我想缩小规模，我会留下残留的配置文件和队列。
这似乎是不必要的，因为在没有分发器的情况下进行测试时，我注意到如果我启动服务器的另一个实例（只需在调试时在 Visual Studio 中选择“调试-启动新实例”），则新程序实例（这是相同的二进制文件）并且具有相同的配置文件和相同的输入队列）似乎与第一个实例的负载平衡相当好。当客户端发出请求时，这些请求似乎在服务器之间来回传递。
如果这种负载平衡有效，则意味着我可以简单地通过添加指向同一高可用输入队列的重复实例来进行扩展，而不需要任何额外的资源分配。那会容易得多！
那么，经销商的优势有哪些呢？
我唯一的猜测来自分销商文档，其中指出分销商“旨在永远不会压倒任何配置为从中接收工作的工作节点的数量。”我不能使用每个工作线程上的 MsmqTransportConfig 的 NumberOfWorkerThreads 属性来控制工作进程可以处理多少工作吗？
I learned how to use an NServiceBus Distributor process on the FullDuplex sample from the article Getting the NServiceBus Distributor Working and it made me wonder:
In order to use the distributor, I need the following queues:
- MyClientInputQueue - the input queue for the single client
- distributordatabus - the distributor's queue to send messages to
- distributorcontrolbus - what the distributor uses to store its state
- server1messagebus - the input queue for the first server instance
- server2messagebus - the input queue for the second server instance
This means that in order to scale with the distributor, every time I want to scale out with another server, I need to have an independent config file which specifies a new server message bus queue. If I want to scale back down, I have vestigial config files and queues left over.
This seems unnecessary since, during my testing without the distributor, I noticed that if I spun up another instance of a server (just by selecting Debug-Start New Instance in Visual Studio while debugging) then the new program instance (which is the same binary and has the same config file and same input queue) seems to load balance fairly well with the first instance. The requests seem to go back and forth between servers when issued by the client.
If this load balancing is effective, it means I could scale out simply by adding duplicate instances pointing to the same highly available input queue, without requiring any additional resource allocation. That would be much easier!
So what, then, are the advantages of the Distributor?
My only guess comes from the Distributor documentation which states that the distributor is "designed never to overwhelm any of the worker nodes configured to receive work from it." Can't I just control how much work a worker process can chew through using the NumberOfWorkerThreads property of the MsmqTransportConfig on each worker?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于分发器主要用于扩展单个消息类型的处理，并且遵循类似地隔离该消息类型的处理的建议，因此我们可以将许多队列命名为与消息类型相同的名称：因此而不是 ' 'distributordatabus'、'server1messagebus' 和 'server2messagebus'，所有这些都将被命名为相同，但每个都将位于不同的计算机上。然后，我们将分配器的控制总线命名为类似于消息类型，但只是带有“_control”后缀（或类似的名称）。
它用于扩展到许多机器——这些机器不能共享输入队列。
Since a distributor is used primarily to scale out the processing of a single message type, and following the recommendations of having similarly isolated the processing of that message type, we can name many of the queues the same as the message type: so instead of 'distributordatabus', 'server1messagebus', and 'server2messagebus', all of them would be named the same, but each would be on a different machine. Then we'd name the distributor's control bus similar to the message type, but just with a '_control' suffix (or something like that).
It's for scaling out to many machines - which can't share an input queue.