点赞功能，到底用 MySQL 仍是 Redis ？

真正聪明的人看似笨拙，实际上是不自炫耀；真正有才华的人看似木讷，实际上是不露锋芒。

点赞功能是目前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的数据来实现。

场景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

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

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

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

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

• 去重。点赞数能够不精确，但去重必须是精确的，
• 另一个社交产品，用户行为的一点一滴都须要记录，对于后续的用户行为分析和数据挖掘都是有意义的。

上面使用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，就会有一致性问题，这就是另一个很重要的话题了。