如何在社交网络中实现活动流

Question

我正在开发我自己的社交网络，但我还没有在web上找到实现用户操作流的示例……例如，如何为每个用户过滤操作？如何存储动作事件？我可以将哪个数据模型和对象模型用于操作流和操作本身？

Answer 1

总结：对于大约100万个活跃用户和1.5亿个存储的活动，我保持简单：

• 使用关系数据库存储独特的活动(每个活动一条记录/“发生的事情”)，使记录尽可能紧凑。结构，以便您可以快速抓取一批活动的活动ID，或通过使用一组朋友ID与时间constraints.
• Publish活动ID到Redis的活动记录被创建时，添加ID到“活动流”列表为每个用户谁是朋友/订阅者，应该看到该活动。

查询Redis以获取任意用户的活动流，然后根据需要从数据库中获取相关数据。如果用户需要在很久以前浏览数据库(如果您提供此功能的话)，则退回到按时间查询数据库

我使用一个普通的老式MySQL表来处理大约1,500万个活动。

它看起来像这样：

id             
user_id       (int)
activity_type (tinyint)
source_id     (int)  
parent_id     (int)
parent_type   (tinyint)
time          (datetime but a smaller type like int would be better) 

activity_type告诉我活动的类型，source_id告诉我与活动相关的记录。因此，如果活动类型表示“已添加收藏”，则我知道source_id指的是收藏记录的ID。

parent_id/parent_type对我的应用程序很有用-它们告诉我活动与什么相关。如果一本书被收藏，那么parent_id/parent_type会告诉我该活动与具有给定主键(id)的书(type)相关

我在(user_id, time)上建立索引，并查询user_id IN (...friends...) AND time > some-cutoff-point类型的活动。去掉id并选择不同的聚集索引可能是个好主意--我还没有尝试过。

非常基本的东西，但它很有效，它很简单，并且很容易在您的需求变化时使用。此外，如果您不使用MySQL，那么在索引方面可能会做得更好。

为了更快地访问最近的活动，我一直在尝试使用Redis。Redis将所有数据存储在内存中，所以您不能将所有活动都放在内存中，但您可以为站点上大多数常用的屏幕存储足够的数据。每个用户最近的100或类似的东西。有了Redis，它可能是这样工作的：

• Create your MySQL activity record
• 对于创建活动的用户的每个朋友，将ID推送到他们的Redis活动列表中。
• 将每个列表裁剪到最后X个项目

Redis速度很快，并提供了一种在一个连接上传输命令的方法--因此将一个活动推送到1000个朋友只需要几毫秒。

有关我所说的更详细的解释，请参见Redis的推特示例：http://redis.io/topics/twitter-clone

更新2011年2月我目前有5,000万个活跃活动，我没有任何改变。做类似的事情的一个好处是它使用了紧凑的小行。我正在计划做一些改变，这将涉及更多的活动和对这些活动的更多查询，我肯定会使用Redis来保持事情的速度。我在其他领域使用Redis，它对某些类型的问题真的很有效。

更新2014年7月我们每月有大约70万活跃用户。在过去的几年中，我一直在使用Redis (如项目符号列表中所述)来存储每个用户的最后1000个活动in。系统中通常有大约1亿条活动记录，它们仍然存储在MySQL中，并且仍然是相同的布局。这些记录可以让我们使用更少的Redis内存，它们用作活动数据的记录，如果用户需要在时间上更早地翻页来查找某些内容，我们可以使用它们。

这不是一个聪明或特别有趣的解决方案，但它对我很有帮助。

Answer 2

这是我使用mysql实现的活动流。有三个类: Activity、ActivityFeed和Subscriber。

Activity表示一个活动条目，其表如下所示：

id
subject_id
object_id
type
verb
data
time

Subject_id是执行动作的对象的id，object_id是接收动作的对象的id。type和verb描述操作本身(例如，如果用户向一篇文章添加评论，他们将分别是“评论”和“创建”)，数据包含额外的数据以避免连接(例如，它可以包含主题名称和姓氏，文章标题和url，评论正文等)。

每个活动都属于一个或多个ActivityFeeds，并且它们由如下所示的表相关联：

feed_name
activity_id

在我的应用程序中，每个用户有一个提要，每个项目(通常是博客文章)也有一个提要，但它们可以是您想要的任何内容。

订阅者通常是站点的用户，但也可以是对象模型中的任何对象(例如，一篇文章可以订阅其创建者的feed_action )。

每个订阅者都属于一个或多个ActivityFeeds，并且像上面一样，它们通过以下类型的链接表联系在一起：

feed_name
subscriber_id
reason

这里的reason字段解释了订阅者订阅提要的原因。例如，如果用户将博客帖子加入书签，则原因是“书签”。这有助于我稍后过滤通知给用户的操作。

为了检索订阅者的活动，我对这三个表进行了简单的连接。联接很快，因为我选择了很少的活动，这要归功于一个看起来像now - time > some hours的WHERE条件。多亏了活动表中的数据字段，我避免了其他连接。

关于reason字段的进一步解释。例如，如果我想要过滤发送给用户的电子邮件通知的操作，并且用户将博客帖子设置为书签(因此他订阅了带有“书签”原因的帖子提要)，我不希望用户收到有关该项目操作的电子邮件通知，而如果他评论了该帖子(因此它订阅了带有“评论”原因的帖子馈送)，我希望当其他用户向同一帖子添加评论时，他会收到通知。reason字段帮助我进行这种区分(我通过一个ActivityFilter类实现了它)，以及用户的通知首选项。

Answer 3

有一种活动流的当前格式，它是由一群知名的人开发的。

http://activitystrea.ms/。

基本上，每个活动都有一个参与者(执行该活动)、一个动词(活动的操作)、一个对象(参与者在其上执行操作)和一个目标。

例如: Max发布了一个到Adam's wall的链接。

在撰写本文时，他们的JSON规范已经达到了1.0版，其中显示了您可以应用的活动的模式。

他们的格式已经被英国广播公司，Gnip，谷歌Buzz Gowalla，IBM，MySpace，Opera，Socialcast，Superfeedr，TypePad，Windows Live，YIID和许多其他公司采用。