NServiceBus pub/sub - 我的消息到哪里去了？
嗯，我做这个 NServiceBus 项目已经有一段时间了，一旦我让它在 PubSub 上工作，我就把剩下的时间花在实际的工作流逻辑上。然而，我可以看到一个我想要解决的严重问题（或者更确切地说学习如何正确处理）。
据我所知，发布者将消息发布到任何订阅者的存储队列。伟大的。但是当订阅者没有运行时会发生什么（我读过有关此的其他帖子，他们似乎没有问同样的问题）。
场景 - 我让发布者在没有订阅者运行时发布消息（附加/请求的消息将转发给他们）.. 然后我发现.. 消息“消失”了，只是不存在！它去哪儿了？出版商是否说“嘿，没有人订阅这个，所以我不会费心出版它？”，难道它不应该这样做并且需要至少一个订阅者吗？
任何人都可以阐明这一点吗？ （nservicenewbie）
Well I've been doing this NServiceBus project for a while and once I got it working for PubSub I then spent the rest of the time on the actual workflow logic. However, I can see a serious issue which I want to get around (or rather learn how to handle correctly).
A publisher publishes a message to the storage queues of any subscribers as far as I understand. Great. But what happens when the subscriber isn't running (I've read other posts about this and they don't seem to be asking the same question).
Scenario - I get the publisher to Publish a message when no subscribers are running (attached/requested messages to be relayed to them).. I then find that.. the message is "gone" just simply isn't there! where did it go? Did the publisher say "hey, no one's subscribing to this, so I wont bother publishing it?", shouldn't it NOT do that and require at least one subscriber?
Can anyone shed any light on this? (nservicenewbie)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该发布一个已经发生的事件 - 一个事实陈述，其他处理程序可能感兴趣也可能不感兴趣。零订阅者是完全有效的！如果情况并非如此，那么也许您应该 Send()ing 命令而不是 Publish()ing 事件。
如果您使用持久订阅存储，则启动订阅者一次，它将始终被订阅。如果订阅者离线，则其消息将堆积在其输入队列中，准备在订阅者重新上线时进行处理。
如果您只是使用 NServiceBus 进行测试，则 NServiceBus.Host.exe 正在 Lite 配置文件中运行，该配置文件使用内存（非持久）订阅存储，这将导致您所看到的结果。
You should publish an event that has happened - a statement of fact, that other handler may or may not be interested in. It's perfectly valid to have zero subscribers! If this is not the case then maybe you should be Send()ing a command instead of Publish()ing an event.
If you are using a persistent subscription storage, start the subscriber up once and it will always be subscribed. If the subscriber is offline, messages for it will pile up in its Input Queue, ready to be processed when the subscriber comes back online.
If you're just testing with NServiceBus, the NServiceBus.Host.exe is running in the Lite profile, which uses in-memory (non-persistant) subscription storage, which would result in what you are seeing.
啊哈！虽然没有消息类型的订阅者并不总是错误，但有一种方法可以处理它。
在您的发布者中，只需修改：
要使用（您将需要 NServiceBus.Core.dll 和 NS NServiceBus.Unicast）：
然后您可以将处理程序附加到：
这可以将消息放入错误队列中..或者可能永远重试..或者发布其他东西等等..等等..你想要什么。从而确保您的特定系统（从业务角度）需要结果时不会造成任何损失
Ah ha! Well though it's not always an error to have no subscriber for a message type, there is a way to handle it.
In your publisher simply modify the:
To use (you will need NServiceBus.Core.dll and the NS NServiceBus.Unicast):
Then you can attach an handler to:
This can then put the message in an error queue.. or perhaps retry forever.. or publish something else etc.. etc.. what ever you want. Thus ensuring there is nothing lost where your particular system (from a business perspective) requires an outcome