实施社交活动流的最佳方式是什么？[关闭]

我很想听听您的意见，这是实施社交活动流的最佳方法（Facebook是最著名的例子）。涉及的问题/挑战是：

• 不同类型的活动（发布，评论..）
• 不同类型的对象（帖子，评论，照片..）
• 1-n位用户扮演不同的角色（“用户x在用户Z帖子上回复了用户y的评论”）
• 相同活动项目的不同视图（“您评论..”与“您的朋友x评论”与“用户x评论..” =>“评论”活动的3种表示形式）

等等，尤其是如果您将其高度复杂化时，例如Facebook，例如，将多个活动项合并为一个（“用户x，y和z在该照片上发表了评论”

关于模式，纸张等的任何想法或指针，关于实现这种系统，数据模型等的最灵活，有效和强大的方法。

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

我已经创建了这样的系统，并采用了这种方法：

数据库表具有以下列：id，userId，类型，数据，时间。

• userId是生成活动的用户
• type是活动的类型（例如，写博客文章，添加照片，对用户的照片发表评论）
• 数据是带有活动元数据的序列化对象，您可以在其中放入所需的任何内容

这限制了您可以在提要中进行的搜索/查找，用户，时间和活动类型，但是在Facebook型活动提要中，这并不是真正的限制。并且在表上有正确的索引，查找速度很快。

使用这种设计，您将不得不决定每种事件类型都需要哪些元数据。例如，一张新照片的供稿活动可能如下所示：

{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类，以呈现不同类型的活动条目。事件分组也将内置在呈现代码中，以使数据库免于复杂性。

这是一个很好的演示，概述了Etsy.com如何设计其活动流。这是我在该主题上找到的最佳示例，尽管它不是特定于Rails的。

http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture

我们已经开源了我们的方法：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的系统。入门非常容易。

要了解有关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。目前，您必须扮演自己的角色。

事件流的最大问题是可见性和性能。您需要将显示的事件限制为仅是该特定用户感兴趣的事件，并且需要保持整理和识别这些事件所需的时间量是可管理的。我建立了一个很小的社交网络；我发现在较小的规模上，在数据库中保留“事件”表是可行的，但是在中等负载下它将成为性能问题。

随着消息和用户流的增加，最好使用消息传递系统，在该系统中，事件作为消息发送到各个配置文件。这意味着您无法轻松地订阅人们的事件流并非常轻松地查看以前的事件，但是当您需要为特定用户呈现流时，您只是呈现一小群消息。

我相信这是Twitter的原始设计缺陷-我记得曾读过他们访问数据库以提取和过滤事件的信息。这与体系结构完全无关，而与Rails无关（不幸的是，Rails产生了“红宝石无法缩放”模因）。我最近看到一个演示，其中开发人员使用Amazon的Simple Queue Service作为类似Twitter的应用程序的消息传递后端，该应用程序具有更高的扩展能力-如果您的负载足够高，则值得将SQS作为系统的一部分进行研究。

如果您愿意使用单独的软件，我建议使用Graphity服务器，它可以完全解决活动流的问题（在neo4j图形数据库的基础上构建）。

该算法已实现为独立的REST服务器，因此您可以托管自己的服务器以交付活动流： http //www.rene-pickhardt.de/graphity-server-for-social-activity-streams-released-gplv3 /

在论文和基准测试中，我表明检索新闻流仅线性依赖于要检索的项目数量，而不会因对数据进行非规范化而产生任何冗余：

http://www.rene-pickhardt.de/graphity-an-efficiency-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks/

在上面的链接中，您可以找到此方法的截屏视频和基准（显示图形性每秒可以检索1万多个流）。

昨天我开始实施这样的系统，这是我要做的...

我使用属性Id，ActorId，TypeId，Date，ObjectId和其他Details键/值对的哈希表创建了StreamEvent类。在数据库中，这由StreamEvent表（Id，ActorId，TypeId，Date，ObjectId）和StreamEventDetails表（StreamEventId，DetailKey，DetailValue）表示。

该actorId来，TYPEID和的ObjectId允许被捕获的主语-动词-对象事件（后来查询）。每个操作可能导致创建几个StreamEvent实例。

然后，我为每种事件类型的StreamEvent创建了一个子类，例如LoginEvent，PictureCommentEvent。这些子类中的每一个都有更多特定于上下文的属性，例如PictureId，ThumbNail，CommenText等（事件需要什么），这些属性实际上作为键/值对存储在hashtable / StreamEventDetail表中。

当从数据库中拉回这些事件时，我使用工厂方法（基于TypeId）来创建正确的StreamEvent类。

StreamEvent的每个子类都有一个Render（context As StreamContext）方法，该方法根据传递的StreamContext类将事件输出到屏幕。StreamContext类允许根据视图的上下文设置选项。例如，如果您查看Facebook，则主页上的新闻提要会列出每个动作所涉及的每个人的全名（及其个人资料的链接），而在朋友的提要中，您只会看到他们的名字（但其他演员的全名） 。

我尚未实现聚合供稿（Facebook主页），但我想我将创建一个具有字段UserId，StreamEventId的AggregateFeed表基于某种“嗯，您可能会发现这个有趣的”算法填充的。

任何评论将不胜感激。

//每个实际事件一个条目
事件{
  id，时间戳，类型，数据
}

//每个事件一个条目，包含该事件的每个供稿
events_feeds {
  event_id，feed_id
}

创建事件后，请确定事件显示在哪个供稿中，并将其添加到events_feeds中。要获取供稿，请从events_feeds中选择，加入事件，并按时间戳排序。然后可以对该查询的结果进行过滤和聚合。使用此模型，您可以在创建后更改事件属性，而无需进行额外的工作。

如果您确定要在Rails中实现，也许您会发现以下插件很有用：

ActivityStreams：http : //github.com/face/activity_streams/tree/master

如果没有其他问题，您将在数据模型以及为推入和拉出活动提供的API方面看一下实现。

我有一个与Heyman类似的方法-一个非规范化表，其中包含将在给定活动流中显示的所有数据。对于活动受限的小型站点，它工作正常。

如上所述，随着站点的增长，它很可能面临可伸缩性问题。就个人而言，我现在不担心扩展问题。我稍后会担心。

Facebook显然在扩展方面做得很出色，所以我建议您阅读他们的工程博客，因为它有很多很棒的内容-> http://www.facebook.com/notes.php?id=9445547199

我一直在寻找比上面提到的非规范化表更好的解决方案。我发现实现此目标的另一种方法是将给定活动流中的所有内容压缩为一行。它可以以XML，JSON或某些序列化格式存储，您的应用程序可以读取它。更新过程也将很简单。在活动之后，将新活动放入队列中（也许使用Amazon SQS或其他方式），然后继续在队列中轮询下一项。抓取该项目，对其进行分析，然后将其内容放置在数据库中存储的相应Feed对象中。

这种方法的好处是，只要请求特定的提要，您就只需要读取一个数据库表，而不用获取一系列表。而且，它允许您维护活动的有限列表，因为每当更新列表时，都可能会弹出最旧的活动项目。

希望这可以帮助！:)

关于这样的活动流有两个警告：

• http://railscasts.com/episodes/406-public-activity（带有gem public_activity的活动供稿）
• http://railscasts.com/episodes/407-activity-feed-from-scratch（从头开始也是一样）

这些解决方案并不包含您的所有要求，但是应该可以给您一些想法。

我认为Plurk的方法很有趣：它们以类似于Google财经的股票图表的格式提供您的整个时间表。

这可能是值得考虑的宁看到了社交网络是如何工作的。该开发者页面看起来特别有帮助。

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

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"}

在实现活动流以在多个应用程序中启用社交提要，微博和协作功能之后，我意识到基本功能非常普遍，可以通过API转化为外部服务。如果您要将流构建到生产应用程序中，并且没有独特或非常复杂的需求，则使用行之有效的服务可能是最好的方法。我绝对建议在生产应用程序中使用它，而不是在关系数据库之上滚动自己的简单解决方案。

我的公司Collabinate（http://www.collabinate.com）正是基于这种认识而发展起来的，我们已经在图形数据库的顶部实现了可扩展的高性能活动流引擎来实现它。实际上，我们利用了Graphity算法的一种变体（改编自@RenePickhardt的早期工作，在此也提供了答案）来构建引擎。

如果您想自己托管引擎或需要特殊功能，那么核心代码实际上是出于非商业目的的开源代码，因此欢迎您查看。