整理/管理数据以填充“现场活动馈送”在网络应用程序中
我有一个关于管理网站上的实时提要/投票的抽象问题。
我正在创建一个 Web 应用程序（基于 Java/Spring/Hibernate 构建），在用户的主页上，我希望实时了解该团队所有成员的最新活动，并且我正在尝试找出处理问题的最佳方法这个查询在服务器端。
强力方法是加载当前用户的队友列表，然后迭代他的每个队友，加载他们最新的对话/文件上传/等，然后将所有这些活动合并到按时间戳排序的单个列表中并返回它（举例来说，我们只返回 feed 的前 10 个最新活动）。
然而，这似乎性能非常差，特别是因为此操作需要定期完成（取决于轮询间隔）。
我还考虑过将所有潜在的活动（对话/状态更新/上传）作为扩展 Activity 类，然后在 DAO 中进行直接 SQL/JPQL 查询，从要返回的一组用户中选择所有最新活动，但担心可能绕过缓存并继续访问数据库也会降低性能。
以前有人处理过此类问题吗？有人知道什么是好的方法吗？
谢谢！
I have something of an abstract question regarding managing live feeds/polling on web sites.
I am creating a web app (built on Java/Spring/Hibernate) and on the user's home page I want a live feed of the latest activity from all the members of there team, and I am trying to work out the best way to handle this query on the server side.
The brute force way would be to load the current users list of team mates, and then iterate through each of his team mates, loading their latest conversations/file uploads/etc, and then merging all this activity in to a single list sorted by timestamp and returning that (lets say for sake of example that we just return the top 10 latest activity for the feed).
However, that seems very un-performant, especially as this operation would need to be done regularly (depending on the polling interval).
I have also considered making all the potential activities (conversations/status updates/uploads) as extending an Activity class and then just having a direct SQL/JPQL query in a DAO that selects all the latest activity from a set of users to be returned, but concerned that might bypass the caching and continued access to the DB would also reduce performance.
Has anyone handled this type of problem before? any one know what a good approach is?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
现在这是一个旧的，但这是我为此所做的：
Activity（情况已经如此）通知 对象中，Notification有一个指向底层Activity的链接和一个指向用户（被通知的用户）的链接。Activity创建了一个预持久钩子，为正在持久化的Activity创建了一个Notification对象 - 它为每个感兴趣的用户执行了此操作（关注持久化活动的用户的所有用户）目前，通知被持久化/检索到数据库 - 可能无法扩展到非常高的容量，但我的方法think 支持迁移到基于队列的系统（例如 LinkedIn 的 Kafka 队列库，它正是为此目的而设计的）。由于它是针对每个用户的，因此它还提供了为重要通知设置已读/未读通知标志的选项。
This is an old one now, but here is what i did for this:
Activity(this was already the case)Notificationobject, theNotificationhad a link to the underlyingActivityand a link to a user (who was being notified).Activitythat created aNotificationobject for theActivitybeing persisted - it did this for every user that was interested (all users following the user that was persisting theActivity)For the moment,
Notificationsare persisted/retrieved to the DB - possibly not scalable to very high volumes, but the approach I think supports moving to a Queue based system (such as LinkedIn's Kafka queue library which is designed exactly for this purpose). As it is per-user, it also provides the option to have a read/unread notification flag for significant notifications.