NServiceBus：NSB 分发器是瓶颈吗？
我想使用网络负载均衡器来分发消息，但我知道当您尝试使用事务队列时它会出现问题。现在我打算使用NSB经销商。分发主机不会像我想象的那样成为瓶颈吗？我曾认为分发器无法达到扩展订阅者的目的，因为它将所有订阅者实例置于一台机器的瓶颈之后。想法？
I wanted use a network load balancer to distribute messages, but I understand that it has problems when you are trying use Transactional queue. Now I am planning to use the NSB distributor. Does the distributor host not become a bottleneck like I think it would? I had assumed that the distributor defeats the purpose of scaling out a subscriber because it puts all subscriber instances behind a one-machine bottleneck. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据您的分发服务器的吞吐量，您可以使用更多线程来扩展它或添加另一个线程。由于分销商不知道其工作来自何处，因此您可以创建分销商/工作人员网格并根据需要水平扩展。
或者，您可以公开一个负载平衡的 Web 服务入口点，并将工作推送到两个相同的分发服务器。我们发现，只要您将工作推送给分发商，分发商几乎就能尽快分发工作。它的作用并不大，因此繁重的工作是由工人完成的。我会进行一些测试，看看它是否满足您的需求。
您将需要考虑对您的分销商进行集群，因为您不想丢失工作人员需要完成的工作主体。
Depending on the throughput of your Distributor you can scale it up with more threads or add another one all together. Since the Distributor is not aware of where its work comes from you can create a grid of Distributors/Workers and scale horizontally as much as you like.
Alternatively you could expose a web service entry point that is load balanced and pushes work to two identical Distributors. We have found that the Distributor can pretty much dish out the work as fast as you push the work to it. It is not doing much, so the heavy lifting is done by the Workers. I would run some tests to see if it meets your needs.
You will want to consider clustering your Distributor as you don't want to lose the body of work the Workers need to do.