使用 Redis 作为活动流的键/值存储答案

【问题标题】：Using Redis as a Key/Value store for activity stream使用 Redis 作为活动流的键/值存储
【发布时间】：2013-01-02 14:50:21
【问题描述】：

我正在为我的应用创建一个简单的活动流。

目前的技术层和逻辑如下：

** 与活动相关的所有数据都存储在 MYSQL 中，所有活动 ID 的数组都保存在 Redis 中，供每个用户使用。**

用户执行操作，活动直接存储在 MYSQL 的“活动”表中，并返回唯一的 “活动 ID”。
从数据库中检索到此用户的 'followers' 数组，对于每个关注者，我将这个新的 activity_id 推送到他们在 Redis中的列表中>.

当用户查看他们的流时，我会根据他们的用户 ID 从 redis 中检索活动 ID 数组。然后我执行一个简单的 MYSQL WHERE IN($ids) 查询来获取所有这些活动 ID 的实际活动数据。

我相信这种设置是相当可扩展的，因为查询总是非常简单的 IN 查询。然而，它提出了几个问题。

Removing a Follower - 如果用户停止关注某人，我们需要从他们的 Redis 列表中删除与该用户对应的所有活动 ID。这需要遍历 Redis 列表中的所有 ID，并删除与已删除用户对应的 ID。这让我觉得很不雅，有没有更好的方法来管理这个？
'archiving' - 我想保持 Redis 列表的长度为最多说 1000 个活动 ID，并经常从 MYSQL 活动表中删除旧数据，以防止其增长到无法管理的大小。显然这是可以实现的当我们添加新的 ID 时，从用户流列表中删除旧 ID 一。但是，我不确定如何归档这些数据，所以用户可以选择查看非常旧的活动数据。最好的方法是什么？还是我只是过得更好完全执行此限制并阻止用户查看非常旧的活动数据？

总结：我真正想知道的是我当前的设置/逻辑是好还是坏。我需要重新思考吗？如果是这样，您推荐的型号是什么？如果你觉得一切都好，我应该如何解决上述两个问题？我意识到这个问题非常广泛，所有答案都将基于意见，但这正是我正在寻找的。形成良好的意见。

非常感谢。

【问题讨论】：

嘿，有趣的问题。最近一直在使用redis的发布订阅功能。对于需要保留数据的情况，我使用了 MongoDB。我最终做的是使用我们的主应用程序（用 php 编写）发布到 redis 服务器，然后使用一个小型 node.js 应用程序订阅频道并将消息保存到 MongoDB 或 mysql。我提到这一点的原因是，也许将所有数据保存在一个 DB 中可能会比将键存储在 redis 中并在 mysql 中存储值更有效。但这只是我对 redis 的相对简短的体验......祝你好运！
@StefanCross - 谢谢，我将更仔细地研究发布/订阅功能。也许这就是要走的路。

标签： mysql redis feed

【解决方案1】：

1 似乎并不难执行（没有循环）：

delete Redis from Redis
 join activities on Redis.activity_id = activities.id
                and activities.user_id = 2 
                and Redis.user_id = 1
;

2 我不太确定要归档。您可以在每个期间创建存档表，并定期将旧活动从主表移动到存档表。似乎一个正确规范化的活动表应该能够变得相当大。（确保任何“大”活动将活动数据存储在单独的表中，主活动表应该是“窄”的，因为它预计会有很多条目）

【讨论】：