我正在为我的应用创建一个简单的事件流。
目前的技术层和逻辑如下:
** 与事件相关的所有数据都存储在 MYSQL 中，所有事件 ID 的数组都保存在 Redis 中，供每个用户使用。**
- 用户执行的操作和事件直接存储在 MYSQL 的“事件”表中，并返回一个唯一的“activity_id”。
- 从数据库中检索该用户的'followers' 数组，对于每个关注者，我将这个新的activity_id 推送到他们在Redis.
当用户查看他们的流时，我根据他们的用户 ID 从 Redis 中检索事件 ID 数组。然后我执行一个简单的 MYSQL WHERE IN($ids) 查询来获取所有这些事件 ID 的实际事件数据。
我相信这种设置应该是相当可扩展的，因为查询总是非常简单的 IN 查询。然而，它存在几个问题。
删除关注者- 如果用户停止关注某人，我们需要从他们的 Redis 列表中删除与该用户对应的所有 activity_id。这需要遍历 Redis 列表中的所有 ID，并删除与已删除用户相对应的 ID。这让我觉得很不优雅，有没有更好的方法来管理它？'archiving'- 我想将 Redis 列表的长度保留为 假设 1000 个 activity_id 作为最大值，并经常从 MYSQL 事件表中删除旧数据，以防止它增长到无法管理的大小。显然这是可以实现的 通过在我们添加新用户时从用户流列表中删除旧 ID 一。但是，我不确定如何着手归档这些数据 用户可以选择查看非常旧的事件数据。 最好的方法是什么？或者我只是过得更好 完全执行此限制并防止用户查看非常旧的事件数据？
总结:我真正想知道的是我当前的设置/逻辑是好还是坏。我需要彻底重新考虑吗？如果是这样，您推荐的型号是什么？如果你觉得没问题，我应该如何解决上面的两个问题呢？我意识到这个问题非常广泛，所有答案都将基于意见，但这正是我正在寻找的。形成良好的意见。
非常感谢。
最佳答案
1 看起来并不难执行(没有循环):
delete Redis from Redis
join activities on Redis.activity_id = activities.id
and activities.user_id = 2
and Redis.user_id = 1
;
2 我不太确定存档。您可以在每个时期创建归档表，并定期将旧事件从主表移动到归档表。不过，似乎一个经过适当规范化的事件表应该能够变得相当大。 (确保任何“大”事件都将事件数据存储在单独的表中，主事件表应该是“窄”的，因为它预计会有很多条目)
关于mysql - 使用 Redis 作为事件流的键/值存储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14124079/