发布/订阅范例：为什么消息类必须不知道它们的订阅者？
来自 Wikipedia：“发布/订阅（或 pub/sub）是一种消息传递范例，其中消息的发送者（发布者）不会被编程为将其消息发送给特定的接收者（订阅者），相反，发布的消息被分类为不同的类别，而不知道可能有哪些订阅者（如果有）”
我可以理解为什么发送者不能这样做。被编程以将其消息发送到特定的接收者。但是为什么发布的消息必须是不了解其订阅者的类呢？
似乎一旦消息系统本身就位，随着软件的发展，通常会改变的是发送的消息、发布者和接收者。将消息与订阅者分开似乎意味着订阅模型也可能会发生变化。是这个原因吗？另外，现实世界中会出现这种情况吗？
我意识到这可能是一个基本问题，但我正在尝试理解这个范例，非常感谢您的回复。
From Wikipedia: "Publish/subscribe (or pub/sub) is a messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there may be"
I can understand why a sender must not be programmed to send its message to a specific receiver. But why must published messages be classes that do not have knowledge of their subscribers?
It would seem that once the messaging system itself is in place, what typically changes as software evolves is the messages sent, the publishers and the receivers. Keeping the messages separate from the subscribers seems to imply that the subscription model might also change. Is this the reason? Also, does this occur in the real world?
I realize this may be a basic question, but I'm trying to understand this paradigm and your replies are very much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不认为这条规则是绝对的，如果你能找到一种情况，其中了解订阅者的消息是有用的，我认为没有人会告诉你你错了（他们可能会告诉你有然而，这是一个更好的方法）。
但请记住，可扩展性和向后兼容性将直接受到消息了解其订阅者的影响。
从兼容性角度来看，当新进程想要订阅消息时会发生什么？谁负责让消息知道（这是否默认为发布者）？这个新要求如何阻止您保留过去的消息以供将来使用，因为它们不知道未来的订阅者。
在可扩展性方面，当您的消息系统变得流行并且每个人和他们的母亲开始为您的应用程序（例如 Twitter）开发不同的订阅者时会发生什么？如何处理每条消息被发送一千次（每个订阅客户端一次）或发送一条更大的消息？这可能会阻止您使用 SMS 等其他技术，或为可靠的传输技术带来更大的延迟。
这么说可能是为了避免以后出现麻烦。
I don't think the rule is absolute by any means, and if you can find a situation where the message having knowledge of the subscriber is useful I don't think anyone will tell you you're wrong (they may tell you there is a better way, however).
Keep in mind, however, that scalability and backwards compatibility would be directly impacted by the message being aware of its subscribers.
Compatibility-wise, What happens when a new process wants to subscribe to a message? Who's responsible for letting the message know (would this default to the publisher)? And how does this new requirement preclude you from preserving past messages for future consumption, as they wouldn't be aware of future subscribers.
Scalability wise, what happens when your message system becomes popular, and everyone and their mother begin to develop different subscribers to your app (like twitter)? How do you handle each message being sent one thousand times (one for each subscription client) or sending one much larger message? This could preclude you from using other technologies, like SMS, or creating greater latency for reliable transmission technology.
It's probably stated that way to avoid headaches further down the line.
它只是关于关注点分离、遵守接口和隔离。您认为他们为什么需要了解订阅者？
一条消息发布到公告板上。有多个不同主题的公告板。可能没有读者。可能会有读者（订阅者）每天进来并查看论坛上是否有感兴趣的主题。可能有 10,000 名读者全部阅读过。
只要消息是用读者应该知道的语言编写的，为什么发布者（发布者）或消息本身需要了解有关订阅者的任何其他信息？
我认为该消息了解用于消息的接口/合约接收者，但仅此而已。
看起来这个模型也允许单向信息流......为了了解您的订户的一些信息，必须有双向信息流。
It's just about separation of concerns, adherence to an interface, and isolation. Why do you think they would need knowledge of their subscribers?
A message is posted to a bulletin board. There are multiple bulletin boards of different topic. There may be no readers. There may be readers (subscribers) who come in every day and check the board for topics of interest. There may be 10,000 readers who read them all.
As long as the message is written in a language the readers are expected to know, why would the poster (publisher) or the messages themselves need to know anything else about the subscribers?
I think the message has knowledge of the interface/contract receivers use for messages, but that's about it.
It seems like this model also allows one-way information flow... in order to know something about your subscriber, there must be a two-way flow of information.