在你的情况下，在你的规模，分析处理， redis 就足够了，直到一个重要的规模和场景。我还是建议从 postgresql 或者 yandex clickhouse 广泛的查询功能和更好的数据结构方面的分析。
由于你可能有未来的计划，使顶部职位（每周，每月，所有时间或用户为基础），你可能需要一个所有的用户和职位之间的互动历史。8个月后，当你决定根据用户段、时间间隔或其他因素发布热门帖子时，你将需要这个历史记录。在 redis sets 你不会得到的。如果你想拥有它，那么你将需要额外的 sets / sorted sets 跟踪后期用户关系。每当您将一篇新文章添加到用户集时，就需要将该文章添加到文章的用户排序集。我认为在不同的时间看到相同的帖子也应该是这种情况下的另一个考虑。

127.0.0.1:6379> sadd user:1 post1 post2 post3 post4
(integer) 4
127.0.0.1:6379> sadd user:1:posts post1 post2 post3 post4
(integer) 4
127.0.0.1:6379> zadd post1:users 1589791701 user:1
(integer) 1
127.0.0.1:6379> zadd post2:users 1589791701 user:1
(integer) 1
127.0.0.1:6379> zadd post3:users 1589791701 user:1
(integer) 1
127.0.0.1:6379> zadd post4:users 1589791701 user:1
(integer) 1
127.0.0.1:6379> zrange post1:users 0 -1 withscores
1) "user:1"
2) "1589791701"
127.0.0.1:6379>

如果用户基数增加，那么您需要使用 spop , smembers 或者 srandmember 获取这些帖子-但我不确定它是否能满足您的期望-因为您不能分页（不使用spop并移动到另一个集合）。如果您需要根据多个用户进行查询-那么您需要跟踪所有用户以查询他们的集合（您可能已经有了它）-交叉点等。
如果你决定和redis一起去；那么你可以考虑使用 lists 为了更好地分页，请使用 incrby / hincrby .
关键点是历史，以及在整个集群中分布式密钥中查询历史的能力。在您的情况下，您需要做一些额外的工作，以保持该历史记录处于活动状态。