Question

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

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

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

用户执行操作，活动直接存储在MYSQL的“活动”表中，并返回唯一的'activity_id'。
从数据库中检索此用户的'关注者'的数组，并为每位关注者将此新的 activity_id 推送到 Redis

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

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

Removing a Follower - 如果用户停止关注某人，我们需要从 Redis 列表中删除与该用户对应的所有activity_id。这需要循环遍历Redis列表中的所有ID，并删除与删除的用户对应的ID。这让我觉得非常不优，有没有更好的方法来管理这个？

'archiving' - 我想将Redis列表保留一段时间比如1000将activity_id作为最大值并经常从MYSQL活动表中删除旧数据，以防止它增长到无法管理的大小。显然这可以实现通过在我们添加新内容时从用户流列表中删除旧ID 一。但是，我不确定如何归档这些数据用户可以选择查看非常旧的活动数据。最好的方法是什么？或者我只是更好完全强制执行此限制并阻止用户查看非常旧的活动数据？

总结一下：我真正想知道的是我当前的设置/逻辑是好还是坏。我是否需要彻底重新考虑？如果是这样，你推荐的型号是什么？如果你觉得一切都好，我该如何处理上述两个问题呢？我意识到这个问题相当广泛，所有答案都是基于意见的，但这正是我所期待的。良好的意见。

非常感谢提前。

Answer 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我不太确定存档。您可以在每个时段创建归档表，并定期将旧活动从主表移动到归档表。看起来像一个正确规范化的活动表应该能够变得非常大。（确保任何“大”活动将活动数据存储在一个单独的表中，主活动表应该“窄”，因为它预计会有很多条目）

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

1 个答案: