点赞功能：用 MySQL 还是 Redis ？

朴灿烈づ我的快乐病毒、 2021-08-30 01:29 379阅读 1赞

点击上方 [Java后端][Java]，选择 设为星标

优质文章，及时送达

--------------------

作者：一起web编程

链接：toutiao.com/i6825148720728769028

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

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

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

a. 显示点赞数量

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

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

d. 显示文章点赞列表

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

![format_png][]

头条的点赞

![format_png 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做同步。

![format_png 2][]

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的数据来实现。

![format_png 3][]

用户中心点赞列表

**场景d：文章的点赞列表**，类似场景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

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

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

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

![format_png 4][]

帖子点赞列表

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

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

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

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

![format_png 5][]

hash

方案优缺点比对

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

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

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

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

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

**3. 数据一致性**

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

另外只要有数据copy，就会有一致性问题，这就是另外一个很重要的话题了。以后有时间再细聊吧！

写在最后：把问题写明白，真不是一件容易的事情，请大家多多关注，留言，谢谢！

前几天写的一篇文章，受到众多同行的热情回复，能和众多同行一起交流，深感荣幸！对于工程类问题，没有标准的方案，一千个人有一千个方案，哪个最适合你只有你自己知道！期待你更好的思路和方法。

--------------------

\-END-

如果看到这里，说明你喜欢这篇文章，请 转发、点赞。同时 标星（置顶）本公众号可以第一时间接受到博文推送。

**推****荐****阅****读**

***1.*** [浅析 VO、DTO、DO、PO 的概念、区别和用处！][VO_DTO_DO_PO]

***2. ***[宇宙第一 IDE 到底是谁？][IDE]

***3.*** [HashMap 21 问！][HashMap 21]

***4. ***[什么是集群？什么又是负载均衡？][Link 1]

![format_png 6][]

最近整理一份面试资料**《Java技术栈学习手册》**，覆盖了Java技术、面试题精选、Spring全家桶、Nginx、SSM、微服务、数据库、数据结构、架构等等。

获取方式：点“ **在看**，关注公众号 **Java后端** 并回复 **777** 领取，更多内容陆续奉上。

喜欢文章，点个在看 ![format_png 7][]

[Java]: https://blog.csdn.net/qq_37217713/article/details/101445094
[format_png]: /images/20210730/2b750bf0d5b9472396f35b8795cc9429.png
[format_png 1]: /images/20210730/f5d310756d4e494cb52ac3f9bdccb8eb.png
[format_png 2]: /images/20210730/ce92784fc931488c9a7816fc2fbb4f8e.png
[format_png 3]: /images/20210730/82bb5efa83de4a0a9393798f69357e20.png
[format_png 4]: /images/20210730/5042f9d47bdc4f4aa45e9fdf89eb953a.png
[format_png 5]: /images/20210730/f72f202ba55b4fb59d3adc30c685dcb5.png
[VO_DTO_DO_PO]: https://blog.csdn.net/qq_37217713/article/details/106610607
[IDE]: https://blog.csdn.net/qq_37217713/article/details/106596208
[HashMap 21]: https://blog.csdn.net/qq_37217713/article/details/106581089
[Link 1]: https://blog.csdn.net/qq_37217713/article/details/106536450
[format_png 6]: /images/20210730/042f5b6702a648d390155f3f2244673b.png
[format_png 7]: /images/20210730/e3467630059e4e52885b1adb0f3c9dc6.png