我有一个网站，里面有一个帖子提要。当用户查看帖子的时间超过 3 秒时，该帖子将计为一次观看。请求将发出并存储到 Redis 中，格式如下：
user_id: [1,4,5]
其中user_id是键，数组是存储用户查看的帖子列表的集合。我相信这是一种非常简单的方法，但是，我相信从长远来看，每个用户的集合会变得非常非常长。目前，我的网站不大。我正在使用 1GB RAM 和 1 个内核为其供电。我知道在短期内我不会超过我的任何硬件限制，但我想知道这是否是一个好的设计，或者是否有更好的方法来存储用户视图。我选择 Redis 的原因是，与存储在 Redis 中相比，请求在 SQL 数据库中存储数据会更慢。
在您的情况和规模中，分析处理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保持帖子浏览量。
关键点是历史记录，以及跨所有群集的分布式键中历史记录的查询功能。在您的情况下，您需要做一些额外的工作来保持该历史记录处于活动状态。