我很想听听你对实现社交活动流的最佳方式(Facebook就是最著名的例子)的看法。涉及的问题/挑战有:

不同类型的活动(张贴,评论..) 不同类型的对象(帖子,评论,照片..) 1-n个不同角色的用户(“用户x回复了用户y对用户Z帖子的评论”) 同一活动项的不同视图(“您评论了..”vs。“你的朋友x评论”vs。"用户x评论说.."3个“评论”活动的表示)

. .还有更多,特别是如果你把它提高到一个高度复杂的水平,比如,把几个活动项目合并成一个(“用户x, y和z评论了那张照片”)。

任何关于模式、论文等关于最灵活、有效和强大的方法来实现这样一个系统、数据模型等的想法或建议都将受到欢迎。

尽管大多数问题与平台无关,但我最终有可能在Ruby on Rails上实现这样一个系统


当前回答

After implementing activity streams to enable social feeds, microblogging, and collaboration features in several applications, I realized that the base functionality is quite common and could be turned into an external service that you utilize via an API. If you are building the stream into a production application and do not have unique or deeply complex needs, utilizing a proven service may be the best way to go. I would definitely recommend this for production applications over rolling your own simple solution on top of a relational database.

我的公司collaboration (http://www.collabinate.com)就是从这种实现中发展出来的,我们在图形数据库上实现了一个可伸缩的高性能活动流引擎来实现它。实际上,我们使用了Graphity算法的变体(改编自@RenePickhardt的早期工作,他也在这里提供了答案)来构建引擎。

如果您希望自己托管引擎或需要特殊功能,其核心代码实际上是非商业用途的开源代码,因此欢迎您查看。

其他回答

我在几个月前解决了这个问题,但我认为我的实现太基础了。 我创建了以下模型:

HISTORY_TYPE

ID           - The id of the history type
NAME         - The name (type of the history)
DESCRIPTION  - A description

HISTORY_MESSAGES

ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE      - The message to print, I put variables to be replaced by the actual values

HISTORY_ACTIVITY

ID
MESSAGE_ID    - The message ID to use
VALUES        - The data to use

例子

MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}

我们开放了我们的方法: https://github.com/tschellenbach/Stream-Framework 它是目前最大的开源库,旨在解决这个问题。

构建Stream Framework的同一团队还提供了一个托管API,为您处理复杂性。看看getstream。io有Node、Python、Rails和PHP的客户端。

另外,看看这篇高可伸缩性的文章,我们解释了一些涉及到的设计决策: http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html

本教程将帮助您使用Redis设置像Pinterest的提要这样的系统。这很容易上手。

要了解更多关于feed设计的知识,我强烈建议阅读一些我们基于Feedly的文章:

雅虎研究报告 Twitter 2013 Redis的基础上,与后退 Cassandra在Instagram Etsy feed缩放 Facebook的历史 Django项目,具有良好的命名约定。(仅限数据库) http://activitystrea.ms/specs/atom/1.0/(行动者,动词,对象,目标) Quora上关于最佳实践的帖子 Quora扩展了社交网络 Redis红宝石示例 FriendFeed的方法 Thoonk设置 Twitter的方法

虽然Stream Framework是基于Python的,但从Ruby应用程序中使用它并不太难。你可以简单地将它作为服务运行,并在它前面插入一个小的http API。我们正在考虑添加一个API来从其他语言访问Feedly。不过现在你得扮演你自己的角色。

After implementing activity streams to enable social feeds, microblogging, and collaboration features in several applications, I realized that the base functionality is quite common and could be turned into an external service that you utilize via an API. If you are building the stream into a production application and do not have unique or deeply complex needs, utilizing a proven service may be the best way to go. I would definitely recommend this for production applications over rolling your own simple solution on top of a relational database.

我的公司collaboration (http://www.collabinate.com)就是从这种实现中发展出来的,我们在图形数据库上实现了一个可伸缩的高性能活动流引擎来实现它。实际上,我们使用了Graphity算法的变体(改编自@RenePickhardt的早期工作,他也在这里提供了答案)来构建引擎。

如果您希望自己托管引擎或需要特殊功能,其核心代码实际上是非商业用途的开源代码,因此欢迎您查看。

事件流最大的问题是可见性和性能;您需要将显示的事件限制为只显示该特定用户感兴趣的事件,并且需要保持整理和识别这些事件所需的时间。我建立了一个小型的社交网络;我发现,在小范围内,在数据库中保留“事件”表是可行的,但在中等负载下就会出现性能问题。

对于较大的消息流和用户,最好使用消息传递系统,将事件作为消息发送到单个配置文件。这意味着您不能很容易地订阅人们的事件流,也不能很容易地查看以前的事件,但是当您需要为特定用户呈现流时,您只是呈现了一小组消息。

I believe this was Twitter's original design flaw- I remember reading that they were hitting the database to pull in and filter their events. This had everything to do with architecture and nothing to do with Rails, which (unfortunately) gave birth to the "ruby doesn't scale" meme. I recently saw a presentation where the developer used Amazon's Simple Queue Service as their messaging backend for a twitter-like application that would have far higher scaling capabilities- it may be worth looking into SQS as part of your system, if your loads are high enough.

我认为Plurk的方法很有趣:他们以一种看起来很像谷歌Finance的股票图表的格式提供你的整个时间轴。

想要了解一个社交网络是如何运作的,不妨看看Ning。开发人员页面看起来特别有用。