标签: nservicebus-distributor

3版之前的建议是在分发服务器旁边运行超时管理器作为群集上的独立进程.(详见此处:http://support.nservicebus.com/customer/portal/articles/965131-deploying-nservicebus-in-a-windows-failover-cluster).

在将超时管理器作为附属程序集包含之后,在与分发服务器进行扩展时使用它的正确方法是什么？

服务A的每个工作程序是否应该在启用超时管理器的情况下运行,或者只应将服务A的分发程序进程配置为运行服务A的超时管理器？

如果每个工作者都运行它,他们是否共享相同的Raven实例来存储超时？(如果是这样,你如何确保两个或多个工人同时没有获得相同的过期超时？)

我们正在努力寻找一种优雅的解决方案,用于报告从我们基础架构中的系统生成的异常,这些异常比查看电子邮件或检查日志文件更容易操作.跨服务总线的发布/订阅模型可以非常巧妙地解决这个问题.服务将发布错误/事件,并且子程序员可以使用简单模式匹配过滤这些消息.

我们一直在调查NServiceBus项目并想知道它是否能达到我们的要求,看看PubSub示例(http://docs.particular.net/samples/pubsub/),我们注意到它没有解决以下两种情况:

1. 所有发布者都发布相同的消息类型
2. 订阅者不应要求了解发布者端点

我们已设法达到这些要求,但我们不确定配置是否正确.以下是我们的解决方案:

1. 所有发布者共享相同的订阅存储配置(DBSubscriptionStorage),这是一个共享数据库,如文档http://docs.particular.net/nservicebus/messaging/publish-subscribe/的订阅存储部分所述.

2. 所有发布者/订阅者都配置为使用nservicebus网站上的文档中描述的分发者.

我们想知道这是否是NServiceBus发布/订阅模型的正确实现,或者是否有其他解决方案可以实现我们的目标？

我正在考虑使用网络负载均衡器在我的用户实例之间加载平衡消息,而不是使用NServiceBus分发服务器(这基本上只是我能说的软件负载均衡器).每个订户实例将具有要传递到的消息的相同名称的队列,并且将存在在订户之间循环的虚拟IP.发布者只会知道虚拟IP和队列名称.

以下是我理解为这样做的利弊:

1. PROS
   • 无需安装NServiceBus分销商
   • 当我们进行横向扩展时,需要管理/更新的东西少一些(我们已经使用F5对这些机器进行负载平衡,而我们的数据中心购买时就知道它就像他们的手背一样)
   • 少一点失败(是的,NLB可能会失败,但让我们面对它,F5将比在Windows上运行的NServiceBus分销商稳定得多)
   • 无需拥有群集服务器即可拥有我们的群集MSMQ.2台服务器比仅向F5添加另一台VIP贵得多.
2. 缺点
   • NServiceBus分发服务器允许您更轻松地查看消息积压,因为您可以监视的分发服务器上有一个队列.这使您很容易知道何时应添加更多工作节点.
   • NServiceBus分销商在控制工作线程数等方面比较聪明.为什么比NLB更能控制？(不确定这一个)

我准确地捕捉到了这个吗？我知道建议使用NServiceBus分销商,在我反对该建议之前,我想了解更多原因.

NServiceBus文档列出了SQL传输的好处:

队列支持竞争的消费者(同一端点的多个实例从同一队列中提供),因此不需要分发器来扩展处理

http://docs.particular.net/nservicebus/sqlserver/design

如果多个消费者订阅了同一个队列,NServiceBus会阻止多个消费者处理消息？

在处理消息之前,NServiceBus是否会锁定整个表？或者是标记为"正在处理"的消息？