点赞收藏功能该如何设计？
这周给一个小伙伴做模拟面试，因为他在公司的项目是一个短视频+电商的项目，模仿的是微博。看到他简历里写了做了短视频的收藏功能，于是让他讲讲具体的做法是什么样子的。
结果回答的并不理想，答案里有不少硬伤，今天松哥就来和大家简单聊一聊这个话题。
一 为什么用 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 的优点是:
- 空间效率高，因为 Hash 可以存储多个字段值对。
- 查询单个用户的收藏状态非常快。
不过 Hash 有一个问题就是无法按收藏或者点赞时间对数据进行排序。
2.2 Sorted Set (ZSET)
如果你需要根据某个 score（例如收藏的时间戳或者其它数值指标）来给收藏的项目排序，那么就可以考虑使用 Sorted Set。
使用 Sorted Set 的话，key 依然是用户 id，value 则是收藏数据项的 id，score 则是收藏的时间戳。
这样将来在查询的时候，就可以根据时间对收藏/点赞行为进行排序。
使用 Sorted Set 的优点有：
- 可以轻松地获取用户的最近收藏、最热门收藏等。
- 支持范围查询，例如获取某个用户收藏列表中的前 N 项。
三 小结
如果你只需要记录收藏状态而不需要排序，使用 Hash 是一个简单且高效的选择。
如果你需要排序功能（例如按照时间顺序显示收藏），则使用 Sorted Set 更合适。
根据你的具体需求选择最适合的数据结构。如果需要更复杂的逻辑，也可以考虑结合使用这两种数据结构。
