多个 NServiceBus 发布者可以共享同一个 DBSubscriptionStorage 吗？
查看发布-订阅API 和配置页面，似乎NServiceBus 用于跟踪订阅的数据库模式仅跟踪订阅者端点和消息类型。
我曾希望也许我可以更改表的名称，以便为多个发布者使用相同的数据库，但是 此帖子似乎表明您不能。
关键是 - 我完全理解并同意每个事件类型有一个发布者端点的概念 - 但这不可避免地导致多个发布者都在同一应用程序范围内运行。也许在不同的组件或流程中运行，但这是一个有争议的问题；无论如何，这意味着所有或大多数发布者将共享相同的事务数据库。因此，必须为每个单独的发布者实际创建一个单独的 SQL 数据库的可能性似乎有点荒谬；我们最终会得到数百个单表订阅数据库。
DBSubscriptionStorage 是否跟踪足够的信息来识别发布者，以便多个发布者都可以指向同一个数据库？或者如果没有，是否可以使用一些配置更改或修改来实现相同的最终结果？
或者我实际上是否需要为每个发布者以及每个发布的消息类型建立一个单独的数据库？
Looking at the Publish-Subscribe API and Configuration page, it would seem that the database schema used by NServiceBus to track subscriptions only tracks the Subscriber Endpoint and Message Type.
I had hoped that maybe I could change the name of the table in order to use the same database for multiple publishers, but this thread seems to indicate that you can't.
The point is - I fully understand and agree with the notion of having a single publisher endpoint per event type - but that inevitably leads to having multiple publishers all operating out of the same application scope. Perhaps operating in different assemblies or processes but that is a moot point; regardless, it means that all or most publishers will share the same transactional database. So the possibility of having to actually create a separate SQL database for every individual publisher seems slightly ridiculous; we'd end up with hundreds of single-table subscription databases sitting around.
Does the DBSubscriptionStorage track enough information to identify the publisher as well, such that multiple publishers can all be pointed to the same database? Or if not, is there some configuration change or hack that I could use to accomplish the same end result?
Or am I actually going to need a separate database for every publisher - and by extension, every published message type?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您绝对可以在同一个数据库中使用同一个表来存储多个发布者的订阅。由于每个发布者对其特定的消息类型负责，因此不会有逻辑重叠。
You absolutely can use the same table in the same database to store the subscriptions of multiple publishers. Since each publisher is responsible for its specific message types, there will be no logical overlap.