【问题标题】:Can multiple NServiceBus publishers share the same DBSubscriptionStorage?多个 NServiceBus 发布者可以共享同一个 DBSubscriptionStorage 吗?
【发布时间】:2011-04-11 19:01:52
【问题描述】:

查看 Publish-Subscribe API and Configuration 页面,似乎 NServiceBus 用于跟踪订阅的数据库模式仅跟踪订阅者端点和消息类型。

我曾希望也许我可以更改表的名称以便为多个发布者使用同一个数据库,但this thread seems to indicate that you can't

重点是——我完全理解并同意每个事件类型有一个发布者端点的概念——但这不可避免地会导致多个发布者都在同一个应用程序范围之外运行。也许在不同的组件或流程中运行,但这是一个有争议的问题;无论如何,这意味着所有或大多数发布者将共享相同的事务数据库。因此,必须为每个发布者实际创建一个单独的 SQL 数据库 的可能性似乎有点荒谬。我们最终会得到数百个单表订阅数据库。

DBSubscriptionStorage 是否跟踪足够的信息来识别发布者,以便多个发布者都可以指向同一个数据库?或者如果没有,是否有一些配置更改或黑客可以用来实现相同的最终结果?

或者我是否真的需要为每个发布者建立一个单独的数据库 - 进而,每个发布的消息类型?

【问题讨论】:

    标签: .net nservicebus publish-subscribe


    【解决方案1】:

    您绝对可以使用同一个数据库中的同一张表来存储多个发布者的订阅。由于每个发布者都对其特定的消息类型负责,因此不会有逻辑重叠。

    【讨论】:

    • 这是一个非常好的观点,事后看来是显而易见的。不过我想知道,如果该表中有数百个(或者也许有一天,数千个)订阅,性能会开始受到影响,还是实现只查询它关心的特定消息类型?
    • 该表已编入索引,这使得查询订阅者的子集成为一项非常便宜的操作——即使对于可能包含数十万订阅条目的表也是如此。
    • Udi,对于每个发布者引用的所有消息,我都有一个消息程序集。在这种情况下这仍然有效吗?
    • Jeff,这不是推荐的设置 - 会使版本控制更加困难。
    • @Udi 了解版本控制问题,但它与订阅存储中的内容有什么关系吗?在我看来,每个订阅的消息类型都有一行,因此涉及多少程序集似乎并不重要。
    猜你喜欢
    • 2012-02-19
    • 1970-01-01
    • 1970-01-01
    • 2019-05-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多