一、前言
在上家公司用到 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 缓存比较典型的业务场景，方案也是当时设计的，可能并非最优方案，如有问题欢迎探讨。