我是否应该只将 ID 存储到 Redis 中，然后使用 ID 查询 SQL答案

【问题标题】：Should I only store IDs into Redis and then query SQL using the IDs我是否应该只将 ID 存储到 Redis 中，然后使用 ID 查询 SQL
【发布时间】：2011-10-02 05:01:02
【问题描述】：

如果我想在页面上显示最近 X 个最近的帖子\cmets，我使用 LPUSH 存储一个 ID 列表，然后使用 LTRIM 保持列表一定大小。

然后我是否使用从LRANGE 返回的 ID 从以下位置获取 post\cmets 的详细信息：

a) Redis 使用 MGET 我通过的地方：

MGET comment.1.author、comment.1.content、comment.1.timestamp、comment.2.author 等

这样在Redis中存储所有的cmets细节可以吗？

b) SQL 数据库在查询中使用 ID 列表

【问题讨论】：

标签： c# redis

【解决方案1】：

如果您想像这样单独存储字段，hash 似乎比每个 5 个键更合适，即“comment.1”是键，子键为“作者”，“内容”等。但是，除非您有理由只想要 ID，否则我很想将整个内容存储为序列化的 json 或二进制块 - 然后您只需 LRANGE 和您有数据 - 不用大惊小怪，行程最少。

为了减少带宽，我会使用 protobuf-net 之类的东西进行存储（尽管我可能有偏见），如果你需要一个二进制安全客户端 BookSleeve 会做得很好。

【讨论】：

Marc，深度分页性能成本如何？开销可以忽略不计吗？此外，如果我们让用户选择每页显示的项目数量，我们最终会多次缓存相同的项目，不是吗？提前致谢
@CarlosMendes 我不太明白这个问题——你能改述一下吗？
@MarcGravell，以 SO 为例，用户可以选择他们希望每页查看的问题数量（15、30 或 50）。我假设仅将 ID 存储在列表中可能是一个好主意，因为我们可以获得与特定页面的问题相对应的“X”ID（15、30 或 50），然后获取数据。关于深度分页，由于 Redis 列表中的 LRANGE 操作是“O(S+N) S 是起始偏移量，N 是元素数”我想知道通过带有 LRANGE 的 REDIS 列表分页数据的性能成本是否对于较高的页面不会很高（例如：显示页面 1500）
@Carlos 啊，对。是的，[S]tart 和 [N]number 确实是 O(S+N)，但仍然非常快