PubSub 基础知识 - 很多关注者场景？
我有一个网络应用程序，用户可以在其中互相关注。当一个用户发布某些操作时，我希望该操作出现在关注者的提要中。一个简单的方法可能是为每个用户保留一个 feed.xml 文件，该文件的更新如下：
用户 A 后面跟着用户 B、用户 C。
用户A发布了一些内容。
更新 UserB、UserC xml feed，例如：
// feed-UserB.xml
UserA flew a kite.
UserX blah blah blah.
....
// feed-UserC.xml
UserA flew a kite.
UserY blah blah blah.
....
这就像 pubsub（我认为）。但我不需要它是实时的。我不确定许多追随者的情况是如何处理的。如果一个用户有 100 万粉丝，难道中心不需要坐在那里通知所有 100 万订阅者吗？如果集线器在单个服务器上运行，这可能会长时间占用 CPU，对吗？
谢谢
I have a web app where users can follow one another. When one user publishes some action, I'd like that action to appear in the feeds of followers. A simple approach might be keeping a feed.xml file for each user, which is updated like:
UserA is followed by UserB, UserC.
UserA publishes some content.
Update UserB, UserC xml feeds, like:
// feed-UserB.xml
UserA flew a kite.
UserX blah blah blah.
....
// feed-UserC.xml
UserA flew a kite.
UserY blah blah blah.
....
this is like pubsub (I think). I don't need it to be realtime though. I'm not sure how the case of many followers is handled. If a user has 1 million followers, doesn't the hub have to sit there and notify all 1 million subscribers? If the hub is run on a single server, this could tie up the cpu for a long time, right?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要知道的是，您的情况是少数发布者有许多订阅者，还是有许多发布者有很少订阅者的更均匀分布的解决方案。
如果是前者，那么在 A 更新时编写所有 XML 文件可能并不明智，而只是“根据”需求生成，假设相关需求足够低，以便您不必生成所有 X ,Y,Z 文件用于 A 的每个更新。这将被称为：读取更新。
如果是后者，那么，您的方法更好：写入更新：每次 A 更新时都构建 X、Y 和 Z。
What you need to know is whether you have a situation with many subscribers to a few publishers or a more evenly distributed solution with few subscribers to many publishers.
If this is the former, it may not be smart to write all XML files when A updates, but just generate "upon" demand, assuming that the demand in question will be low enough so that you don't have to generate all the X,Y,Z files for each of A's updates. This would be called : updates on reads.
If this is the latter, then, you're approach is better : updates on writes : you build X, Y and Z's every time A updates.