有关 Redis 缓存的一些应用场景及踩过的坑

在上家公司用到 Redis 作为缓存的场景比较多，常用的数据结构除了 Hash 其他均有用到，总结下当时部分业务场景的实现方案以及上线之后遇到的问题。

二、业务场景

如上图所示，这是个游戏评论页，整个页面的数据按照某些维度分开存储在 Redis 中，在返回 APP 端数据时拼装到一起。着重介绍一下「游戏评分」及「游戏评论」这两个典型案例。

2.1 游戏评分

要求：

• 评分后实时展示最终结果

2.2 游戏评论（含回复）

要求：

• 用缓存实现评论的 CRUD 功能，最大限度的减少数据库压力

三、实现方案

3.1 游戏评分

最终方案：

将评论中的评分累加得到一个总分及总评论数，放入 Redis 中，总分除以总评论数即得到平均评分，此后用户评论实时操作 Redis 中的值。

3.2 游戏评论（含回复）

注意点：

• 冷热数据（通常只有前几页的访问频率较高）
• 排序（点赞、头衔、回复等因素影响排序）
• 数据写入方式（实时 or 定时）

如上图所示，分别有三种 Redis 缓存的设计方案，从左到右逐步优化。

最终方案：

首次进入页面只加载前 50 条热点数据，同时将评论ID 及具体的评论内容分开存储到 Redis 中。评论ID 用 Zset 存储，评论内容用 String 或者 Hash 存储。这样做的好处是删除或修改某个热点评论时，能最大限度的减少影响的数据，只需要从 Zset 中删除一个 id，或者修改对应的评论内容缓存即可。排序通过 Zset 中的 score 属性实现。

下面用时序图的方式介绍 CRUD 的流程：

① 获取评论列表

sequenceDiagram
title: 获取评论列表流程
participant user as 用户
participant hero as 服务端
user->>hero: 用户进入评论列表页
hero->>hero: 从数据库中查询前 50 条热点数据
hero->>hero: 将 50 个评论ID 放入 Zset 中，评论内容用单独 key 存储
hero->>hero: 根据页码计算偏移量，用 zrevrang 方法获取当前页评论ID 列表
hero->>hero: 如果偏移量大于 50 则继续从数据库中查询并追加到 Zset 中
hero->>hero: 拼装点赞数、回复数等附加数据
hero-->>user: 返回评论列表

② 添加评论（影响评分）

sequenceDiagram
title: 添加评论流程
participant user as 用户
participant hero as 服务端
participant timer as 定时器
user->>hero: 用户发表评论
hero->>hero: 查询数据库中最大的评论ID 并放入 Redis 中
hero->>hero: 缓存的最大评论ID + 1
hero->>hero: 拼装评论内容并放入 Redis 中
hero->>hero: 将评论ID 添加到热点评论ID 缓存列表中
note over hero: 实时变动游戏评分
hero->>hero: 相应评分数 + 1
hero->>hero: 总评论数 + 1 且总评分累加
hero-->>user: 返回评论成功
note over timer: 每隔半小时
note over timer: 数据库回写
timer->>timer: 回写在「数据库最大评论ID 及 Redis 最大评论ID」 区间内的数据

③ 删除评论（不影响评分）

sequenceDiagram
title: 删除评论流程
participant user as 用户
participant hero as 服务端
user->>hero: 用户删除评论
hero->>hero: 根据评论ID 查询数据库是否存在
hero->>hero: 存在则逻辑删除数据库中的数据
hero->>hero: 删除 Zset 中相应的元素
hero->>hero: 删除对应的评论内容缓存
hero->>hero: 删除对应的评论回复
hero->>hero: 总评论数 - 1
hero-->>user: 返回删除成功

四、线上遇到的问题

4.1 我下载的、我试玩的、我喜欢的、我点评的列表数据经常变为 1 条，与个人主页的统计数不符

原因：列表缓存 10 分钟，有序集合类型，通过 zadd 命令追加数据，而缓存失效后如果用户点下载或者试玩，zadd 命令会自动创建一个空的列表，并将刚操作的游戏ID加入，导致列表只有一条数据。

解决方法：在追加数据前先判断缓存是否存在，不存在则从数据库加载并放入 Redis，之后再通过 zadd 命令往里追加。

4.2 腾讯视频人气从几百万突然变为几百，此前几天无异常

原因：人气、点赞等数据缓存时间为一周，失效后通过 incr 命令会自动创建 key 并从 0 开始累加。

解决方法：累加前先判断缓存是否存在，不存在则从数据库加载并放入 Redis，之后再通过 incr 命令累加。

4.3 某个用户下拉游戏推荐列表到第 14 页时无返回数据

原因：该用户下拉到第 13 页后，过了将近 20 分钟后才继续下拉到第 14 页，此时 Redis 中游戏推荐列表的缓存已失效，重新加载是默认加载前50条，而第 14 页是需要 131~140 的数据，故而找不到对应的下标则返回空列表。

解决方法：适当延长缓存时间规避这种情况，当然这并不能百分百解决。

4.4 判断当前用户是否点赞「点赞数为 0」的评论或者回复时每次都要查询数据库

原因：点赞记录会加载进 Redis 缓存中，如果点赞数为 0 则代表没点赞记录也就是没缓存，进而导致每次都发生缓存穿透。

解决方法：缓存中设置一条默认的点赞记录。

五、结语

以上就是在上家公司涉及到 Redis 缓存比较典型的业务场景，方案也是当时设计的，可能并非最优方案，如有问题欢迎探讨。