点赞收藏功能该如何设计？

这周给一个小伙伴做模拟面试，因为他在公司的项目是一个短视频+电商的项目，模仿的是微博。看到他简历里写了做了短视频的收藏功能，于是让他讲讲具体的做法是什么样子的。

结果回答的并不理想，答案里有不少硬伤，今天松哥就来和大家简单聊一聊这个话题。

一 为什么用 Redis

首先就是为什么要用 Redis？直接存到数据库不行吗？

用 Redis 主要是有下面一些优势。

1.1 高性能

因为点赞收藏是一个高频操作，所以利用 Redis 就能做到非常低的延迟和极高的吞吐量，这是一个巨大的优势。

1.2 简化架构

对于简单的点赞和收藏功能，Redis 提供了内置的数据结构（如 Hash 和 Sorted Set），这使得实现起来非常简便。你不需要编写复杂的 SQL 查询或设计复杂的索引来支持这些功能。

1.3 弹性和扩展性

Redis 支持主从复制、集群部署以及持久化机制，这使得它非常适合需要高度可用性和可扩展性的应用。即使在数据量增长的情况下，你也可以通过增加 Redis 实例来水平扩展系统。

1.4 实时数据分析

Redis 还支持实时分析和聚合功能，这对于实时展示点赞数量或热门内容非常有用。例如，你可以轻松地计算出最受欢迎的内容或用户的活动趋势。

因为这个小伙伴的项目是互联网项目，所以用 Redis 去做点赞和收藏我相信大家应该没有什么异议。

具体问题具体分析，如果就是常规的企业级系统开发，并发量不大甚至数据量也不大的话，那么也可以直接上数据库。

二 使用哪种数据结构

如果用 Redis 来实现点赞或者收藏功能的话，一般来说我们有两种数据结构可以选择：

• Hash
• Sorted Set

这两种数据结构各有特点，我们要结合具体情况来分析。

2.1 Hash

如果你的收藏功能只需要记录用户对某个项目是否收藏了，并不需要对这些收藏项进行排序，那么可以考虑使用 Hash。

可以用用户名做 key，value 则是一个 list，表示用户收藏项的 id。

使用 Hash 的优点是:

1. 空间效率高，因为 Hash 可以存储多个字段值对。
2. 查询单个用户的收藏状态非常快。

不过 Hash 有一个问题就是无法按收藏或者点赞时间对数据进行排序。

2.2 Sorted Set (ZSET)

如果你需要根据某个 score（例如收藏的时间戳或者其它数值指标）来给收藏的项目排序，那么就可以考虑使用 Sorted Set。

使用 Sorted Set 的话，key 依然是用户 id，value 则是收藏数据项的 id，score 则是收藏的时间戳。

这样将来在查询的时候，就可以根据时间对收藏/点赞行为进行排序。

使用 Sorted Set 的优点有：

1. 可以轻松地获取用户的最近收藏、最热门收藏等。
2. 支持范围查询，例如获取某个用户收藏列表中的前 N 项。

三 小结

如果你只需要记录收藏状态而不需要排序，使用 Hash 是一个简单且高效的选择。

如果你需要排序功能（例如按照时间顺序显示收藏），则使用 Sorted Set 更合适。

根据你的具体需求选择最适合的数据结构。如果需要更复杂的逻辑，也可以考虑结合使用这两种数据结构。