我很想听听你对实现社交活动流的最佳方式(Facebook就是最著名的例子)的看法。涉及的问题/挑战有:
不同类型的活动(张贴,评论..)
不同类型的对象(帖子,评论,照片..)
1-n个不同角色的用户(“用户x回复了用户y对用户Z帖子的评论”)
同一活动项的不同视图(“您评论了..”vs。“你的朋友x评论”vs。"用户x评论说.."3个“评论”活动的表示)
. .还有更多,特别是如果你把它提高到一个高度复杂的水平,比如,把几个活动项目合并成一个(“用户x, y和z评论了那张照片”)。
任何关于模式、论文等关于最灵活、有效和强大的方法来实现这样一个系统、数据模型等的想法或建议都将受到欢迎。
尽管大多数问题与平台无关,但我最终有可能在Ruby on Rails上实现这样一个系统
我昨天开始执行一个这样的系统,这就是我要做的…
我创建了一个带有属性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,这是基于某种“嗯,你可能会发现这个有趣的”算法。
任何意见都将非常感激。
我们开放了我们的方法:
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的早期工作,他也在这里提供了答案)来构建引擎。
如果您希望自己托管引擎或需要特殊功能,其核心代码实际上是非商业用途的开源代码,因此欢迎您查看。