vlambda博客
学习文章列表

点赞功能是目前 app 开发基本的功能

今天我们就来聊聊 点赞、评论、收藏等这些场景的 db 数据库设计问题

1. 我们先来看看场景的需求：

• 显示点赞数量

• 判断用户是否点过赞，用于去重，必须的判断

• 显示个人点赞列表，一般在用户中心

• 显示文章点赞列表

我们先看一下头条和微博的例子

这两个都是具有顶级流量的，后端肯定有复杂的架构，我们今天只谈大众化的方案。

2.1 mysql 方案

mysql 方案，随着 nosql 的流行，大数据的持续热点，但是 mysql 仍然不可替代，对于大多数的中小项目，低于千万级的数据量，采用 mysql 分表 + cache，是完全可以胜任的，而且稳定性是其他方案无可比拟的：

-- 文章表
create table post {
        post_id int(11) NOT NULL AUTO_INCREMENT,
        ......
        star_num int(11) COMMENT '点赞数量'
}

-- 用户表
create table user {
        user_id int(11) NOT NULL AUTO_INCREMENT,
        ......
        star_num int(11) COMMENT '点赞数量'

}

-- 点赞表
create table star {
        id int(11) NOT NULL AUTO_INCREMENT,
        post_id,
        user_id,
        ......
}

常用的查询：

查询用户点赞过的文章

select post_id from star where user_id=?

查询文章的点赞用户

select user_id from star where post_id=?

点赞数量可以通过定时异步统计更新到 post 和 user 表中。

数据量不大的时候，这种设计基本可以满足需求了，

缺点：

数据量大时，一张表在查询时压力巨大，需要分表，而不论用 post_id 还是 user_id 来 hash 分表都与我们的需求有冲突，唯一的办法就是做两个表冗余。这增加了存储空间和维护工作量，还可能有一致性问题。

2.2 redis 方案

当数据量达到上亿的量，上 cache 是必经的阶段，由于点赞这种动作很随意，很多人看到大拇指就想点，所以数据量增长很快，数据规模上来后，对 mysql 读写都有很大的压力，这时就要考虑 memcache、redis 进行存储或 cache。

为什么一般都选择 redis， redis 作为流行的 nosql，有着丰富的数据类型，可以适应多个场景的需求。

采用 redis 有两种用途，一种是 storage，一种是纯 cache，需要 + mysql 一起。纯 cache 就是把数据从 mysql 先写入 redis，用户先读 cache，miss 后再拉取 MySQL，同时 cache 做同步。

多数场景二者是同时使用的，并不冲突。

下面说下 redis 作为 storage 的方案：

场景 a ：显示点赞数量

在点赞的地方，只是显示一个点赞数量，能区分用户是否点赞过，一般用户不关心这个列表，这个场景只要一个数字就可以了，当数量比较大时，一般显示为 "7k" ,"10W" 这样。

以文章 id 为 key

//以文章id=888为例
127.0.0.1:6379[2]> set star:tid:888 898 //设置点赞数量 
OK 
127.0.0.1:6379[2]> incr star:tid:888 //实现数量自增 (integer) 
899

场景 b：点赞去重，避免重复点赞

要实现这个需求，必须有文章点赞的 uid 列表，以 uid 为 key 场景 c：一般在用户中心，可以看到用户自己的点赞列表

这个需求可以使用场景 b 的数据来实现。

场景 c：文章的点赞列表，类似场景 b，以文章 id 为 key

//以文章id=888为例
127.0.0.1:6379[2]> sadd star:list:tid:888 123 456 789  //点赞uid列表 (integer)
3
127.0.0.1:6379[2]> sismember star:list:tid:888 456  //判断是否点赞 (integer)
1

点赞的地方，如果点赞过显示红色，没有则显示黑白色

今日头条是没有地方可以看到点赞列表的，而微博点进去，详情页可以看到点赞列表，但是只会显示最近的几十条，没有分页显示。

如下图，我选了一条热点，拥有众多粉丝的 “猪猪”

可能有人觉得，点赞列表没人关心，存储又会浪费大量资源，不如不存！但是，这个数据是必须要有的。两点：

• 去重。点赞数可以不精确，但去重必须是精确的，

• 另外一个社交产品，用户行为的一点一滴都需要记录，对于后续的用户行为分析和数据挖掘都是有意义的。

上面使用 string 存储的用户点赞数量，除了 string，还可以用 hash 来存储，对文章 id 分块，每 100 个存到一个 hash，分别存入 hash table，每个文章 id 为 hash 的一个 key，value 存储点赞的用户 id，如果点赞用户很多，避免 id 过多产生性能问题，可以单列出来，用 sorted set 结构保存，热点的毕竟是少数。

方案优缺点比对

hash：使用了更少的全局 key ，节省了内存空间；但是也带来了问题

• 如何根据文章 id 路由到对应的 hash？

• 查找一个用户 id 是在 hash 还是 set？存在不确定性

• 使用 hash 虽然节省了空间，但增加了复杂度，如何选择就看个人需求了。

除此之外，你还有其他的方法吗？

3. 数据一致性

redis 作为 storage 使用时，一定要做好数据的持久化，必须开启 rdb 和 aof，这会导致业务只能使用一半的机器内存，所以要做好容量的监控，及时扩容。

另外只要有数据 copy，就会有一致性问题，这就是另外一个很重要的话题了。

各位程序员大佬们，请让我听到你们的声音！不管你是前端开发、后端研发、测试开发、移动端开发、全栈工程师、运维工程师、网络工程师、架构师、研发经理还是其他职位，不管你在做 Android 开发 、iOS 开发、U3D 、COCOS2DX、 自动化测试、功能测试、性能测试、白盒测试、灰盒测试、黑盒测试、ETL、数据仓库、数据开发、数据挖掘、数据分析、数据架构、算法研究、精准推荐、分布式、系统集成、地图引擎、人工智能、大数据、深度学习、机器学习、图像处理、图像识别、语音识别、语音学习、机器视觉、自然语言处理、视频开发、区块链还是其它技术支持。欢迎在评论中踊跃发表意见！

博客：niuzhendong.com

Github：github.com/niuzhendonglm

点个赞再走嘛！