问题标签 [nservicebus-distributor]

我们目前将 NService 总线与分发器一起使用，但我想让它成为 HA，而无需迁移到集群 MSMQ。我们已经有一个集群 SQL 服务器。有没有办法让 NService 总线分配器使用 DB 而不是 MSMQ

我正在调查 NServiceBus，但我不确定如何（甚至是否）可以使用它来处理这种情况：

我有多个客户发送工作请求，分销商将这些请求分发给工人。这项工作需要很长时间才能完成，我希望工作人员将进度报告给发送原始请求的客户。

我查看了全双工示例以及如何将分配器添加到该示例。我已经完成了这些工作，但是当我修改它们以回复一系列进度消息时（消息之间存在延迟，如下所示），客户端会同时收到所有进度消息。

我怀疑我对 NServiceBus 的工作原理还不太了解。有人可以解释我哪里出错了，或者指出一些例子和/或文档吗？

我想使用网络负载均衡器来分发消息，但我知道当您尝试使用事务队列时它会出现问题。现在我打算使用 NSB 分配器。分销商主机不会像我想的那样成为瓶颈吗？我曾假设分发者没有达到扩展订阅者的目的，因为它将所有订阅者实例置于单机瓶颈之后。想法？

我完成了 NServiceBus 的 Pub/Sub 示例。

我现在正试图围绕 NServiceBus 的“分销商”概念。

起初我很困惑，因为我认为示例的某些部分映射到了“分发器”。我现在开始认为情况并非如此。

因此，该示例显示了 2 个移动部件。发布者和订阅者。但下一页显示了至少 4 个活动部件。

1. 订阅数据库
2. 发布者节点（P_1、P_2）
3. 经销商
4. 订户节点（S_A_#、S_B_#）

在我达到这一点之前，这一切都很有意义。现在我想知道这些新玩家如何映射到这个清晰的例子。（或者我应该看一个新的例子吗？）

我阅读了有关这些的页面，从概念的角度来看，这一切都是有道理的。但我看不出它在现实生活/代码/示例中是如何工作的。

如果我的问题太含糊，让我问一个更具体的问题：我需要对 Pub/Sub 示例做什么才能使其使用上面的 4 个部分？

我已经看到它多次提到作为一种最佳实践，应该为每种消息类型配置一个分发器进程，但从未解释过为什么会这样。由于增加分销商的数量会增加部署的复杂性，我想知道其背后的原因。我的猜测是，如果给定消息类型的所有可用订阅者都忙，分发者可能会等待一个释放，而可能有空闲订阅者的其他类型的消息堆积在分发者的工作队列中。这是准确的吗？还有其他原因吗？

我正在使用 NServiceBus 2.5 并尝试让 NServiceBus PubSub 示例的简化版本与分销商一起使用。简化：

• 1 个出版商
• 经销商
• 1 个订阅者 所有这些都在一台机器上。

在我继续处理更复杂的事情之前，我想先完成这项工作，例如单个分销商背后的多个订户、多台机器等。

首先，我得到了简化的 pub sub 示例，在没有分发器的情况下工作（即 1 个 pub 和 1 个 sub - 我得到了很好的工作）。

据我了解，它应该工作的方式是：分发器定义自己的控制和数据队列。发布者有它的控制队列，但没有其他配置引用这个队列。发布者指的是分发数据队列。订阅者指的是分发者的数据和控制队列。

我无法让简化的 pub-sub 分发器使用此配置。我已经对发布者进行了一些调试，我发现发布者的 Bus.Publish 没有找到任何要发布的订阅者。

有什么想法我做错了什么以及我需要做什么才能使其正常工作？

以下是每个配置：

出版商：

经销商

订户

我已经让 PubSub 示例与中间的分销商合作 - 所有这些都在我的本地计算机上。现在我正试图让分销商在另一台机器上遇到问题。订阅者似乎是通过分发者向发布者注册的（我在发布者中添加了日志语句，它告诉我订阅者的数量并给了我正确的值），但订阅者只是没有得到任何发布的事件。我究竟做错了什么？我需要为不同的队列提供一些权限吗？这是我的配置文件：

出版商：

订户：

经销商：

在上述配置中，分发者运行在名为“rosmi”的机器上，发布者和订阅者运行在“rrajagop”上。

假设我有一条ClientRequestMessage消息，其中包含对特定Client. Web 应用程序将生成这些请求，并且需要将它们发送到正确的位置Client进行处理。我可以为此想到一些选择。

1. 我可以有一个所有消息都发送到的队列，并且特定的客户端处理程序检查一个属性（如ClientId）来决定他们是否关心它。不过，这在很多层面上对我来说都是错误的。
2. 我可以向所有客户发布一条消息，他们可以决定在处理过程中是否关心它。这似乎是太多的流量，浪费了每个客户处理他们最初不应该关心的消息的时间。
3. 我可以有客户端特定的队列，这些消息也被路由。这对我来说感觉最好，但我不确定如何去做。我想保持简单并避免使用客户端特定的消息类型，但我不确定如何告诉 NServiceBus“客户端 A 将其发送到客户端 A 的队列，客户端 B 将其发送到客户端 B 的队列”。

所以我的问题是，最好的（最有效的？最容易管理的？）方法是什么？我很确定我需要使用分销商，但不是肯定的，所以我想我会问。

奖励问题：
假设每个客户端都有多个处理程序。如何确保只有其中一个处理给定消息？我需要每个客户的分销商吗？

我们在我们的开发环境中使用 nServiceBus，我们有一个前端向服务（订阅者）发布消息。生活很好。

FrontendWebServer -> MiddlewareServer

在我们的生产环境中，我们将运行两个前端和两个中间件服务器以进行故障转移。

FrontendWebServer -> LoadBalancer(F5) -> MiddlewareServer

FrontendWebServer -> LoadBalancer(F5) -> MiddlewareServer

这对 URL 很有效，但是因为我们需要为 MSMQ 使用机器名称，所以我们被卡住了。

我们不想在每个前端配置中指定物理中间件机器名称（因为它使管理配置变得更加困难，并且如果一个中间件服务器出现故障，它也会停止向其特定前端发送消息）。

我们尝试使用 nServiceBus 分发器（安装在每个前端），但似乎订阅者只能收听一个分发器。

有什么想法可以在不使用单独配置的情况下解决这个问题吗？

为简单起见，我将分发器的 ControlInputQueue 和它的 StorageQueue 都称为相同的。我了解分销商的客户端如何通过向 ControlInputQueue 写入条目来通知其可用性，以及分销商如何将条目移动到其 StorageQueue 以跟踪哪些客户端可用于工作。如果我将它们视为相同，则更容易解释。所以...

我创建了一个概念证明来演示 NServiceBus 分发器的行为。正如预期的那样，当客户端启动时，它会在分发服务器的 StorageQueue 中添加一个条目。当一条消息进入分发器（通过它的 InputQueue）时，分发器从它的 StorageQueue 中删除一个条目，并将消息转发给指定的客户端。客户端执行它的工作，然后将一个条目添加回分发者的 StorageQueue。因此，分发者的 StorageQueue 中最多有一个条目（每个客户端）。

我的问题发生在客户端手动或意外关闭时（如服务器爆炸）。客户端的条目仍然存在于 Distributor 的 StorageQueue 中，因此据分发者所知，该客户端仍然可用。这很好，除了当客户端再次启动时，它会在 StorageQueue 中添加另一个条目。因此，现在单个客户端的 StorageQueue 中有两个条目。

有没有办法确保分发者对于任何给定的客户端都只有一个 StorageQueue 条目？