我很想听听你对实现社交活动流的最佳方式(Facebook就是最著名的例子)的看法。涉及的问题/挑战有:
不同类型的活动(张贴，评论..) 不同类型的对象(帖子，评论，照片..) 1-n个不同角色的用户(“用户x回复了用户y对用户Z帖子的评论”) 同一活动项的不同视图(“您评论了..”vs。“你的朋友x评论”vs。"用户x评论说.."3个“评论”活动的表示)
. .还有更多，特别是如果你把它提高到一个高度复杂的水平，比如，把几个活动项目合并成一个(“用户x, y和z评论了那张照片”)。
任何关于模式、论文等关于最灵活、有效和强大的方法来实现这样一个系统、数据模型等的想法或建议都将受到欢迎。
尽管大多数问题与平台无关，但我最终有可能在Ruby on Rails上实现这样一个系统
当前回答
关于这样的活动流有两个铁路广播:
http://railscasts.com/episodes/406-public-activity(带有gem public_activity的活动提要) http://railscasts.com/episodes/407-activity-feed-from-scratch(从头开始是一样的)
这些解决方案不包括你所有的要求，但它应该给你一些想法。
其他回答
如果您愿意使用单独的软件，我建议使用Graphity服务器，它完全解决了活动流的问题(构建在neo4j图形数据库之上)。
算法已经作为一个独立的REST服务器实现，因此您可以托管自己的服务器来交付活动流:http://www.rene-pickhardt.de/graphity-server-for-social-activity-streams-released-gplv3/
在论文和基准测试中，我展示了检索新闻流只依赖于你想要检索的条目的数量，而没有任何冗余，你会从反规范化数据中得到:
http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks/
在上面的链接中，您可以找到屏幕视频和这种方法的基准测试(显示graphity能够每秒检索超过10k个流)。
// one entry per actual event
events {
id, timestamp, type, data
}
// one entry per event, per feed containing that event
events_feeds {
event_id, feed_id
}
创建事件时，决定它出现在哪个提要中，并将这些提要添加到events_feeds中。 要获取提要，请从events_feeds中选择，加入事件，按时间戳排序。 然后可以对该查询的结果进行过滤和聚合。 使用此模型，您可以在创建后更改事件属性，而不需要额外的工作。
我创建了这样一个系统，我采取了这样的方法:
数据库表中包含以下列:id、userId、类型、数据、时间。
userId是生成活动的用户 type是活动的类型(即写博客，添加照片，评论用户照片) Data是一个带有活动元数据的序列化对象，您可以在其中放入任何您想要的内容
这限制了用户、时间和活动类型的搜索/查找，但在facebook类型的活动提要中，这并不是真正的限制。如果表上有正确的索引，查找就会很快。
在这种设计中，您必须决定每种类型的事件需要什么样的元数据。例如，新照片的feed活动可以是这样的:
{id:1, userId:1, type:PHOTO, time:2008-10-15 12:00:00, data:{photoId:2089, photoName:A trip to the beach}}
可以看到，虽然照片的名称肯定存储在包含照片的其他表中，我可以从那里检索名称，但我将在元数据字段中复制名称，因为如果想加快速度，您不希望对其他数据库表进行任何连接。为了显示50个不同用户的200个不同事件，你需要速度。
然后我有一些类，这些类扩展了一个基本的FeedActivity类，用于呈现不同类型的活动条目。事件分组也将在呈现代码中构建，以避免数据库的复杂性。
如果你决定用Rails实现，也许你会发现下面的插件很有用:
ActivityStreams: http://github.com/face/activity_streams/tree/master
如果没有其他问题，您将从数据模型和为推拉活动提供的API两方面来研究一个实现。
我昨天开始执行一个这样的系统，这就是我要做的…
我创建了一个带有属性Id、ActorId、TypeId、Date、ObjectId和附加细节键/值对哈希表的StreamEvent类。这在数据库中由一个StreamEvent表(Id, actid, TypeId, Date, ObjectId)和一个StreamEventDetails表(StreamEventId, DetailKey, DetailValue)表示。
ActorId、TypeId和ObjectId允许捕获一个Subject-Verb-Object事件(以及稍后查询)。每个操作都可能导致创建多个StreamEvent实例。
然后，我为StreamEvent的每种类型的事件创建了一个子类，例如LoginEvent, PictureCommentEvent。这些子类中的每一个都有更多上下文特定的属性，如PictureId, ThumbNail, CommenText等(事件所需的任何属性)，这些属性实际上存储为hashtable/StreamEventDetail表中的键/值对。
当从数据库中提取这些事件时，我使用一个工厂方法(基于TypeId)来创建正确的StreamEvent类。
StreamEvent的每个子类都有一个Render(context As StreamContext)方法，该方法根据传递的StreamContext类将事件输出到屏幕。StreamContext类允许基于视图的上下文设置选项。以Facebook为例，主页上的信息流会列出参与每个行动的每个人的全名(以及他们个人资料的链接)，而查看朋友的信息流，你只能看到他们的名字(但其他参与者的全名)。
我还没有实现一个聚合提要(Facebook家)，但我想我会创建一个AggregateFeed表，其中有字段UserId, StreamEventId，这是基于某种“嗯，你可能会发现这个有趣的”算法。
任何意见都将非常感激。
