点赞功能是目前 app开发基本的功能，今天我们就来说说 点赞、评论、收藏等这种场景的db数据库设计问题。
1、我们先来瞧瞧场景的需求：
我们先看一下头条和微博的事例
这两个都是具有顶尖流量的，后端肯定有复杂的构架，我们明天只谈大众化的方案。
2.1 mysql方案
mysql方案, 随着nosql的流行，大数据的持续热点，但是mysql一直不可取代快手双击点赞是什么功能，对于大多数的中小项目，低于千万级的数据量，采用mysql分表+cache，是完全可以胜任的，而且稳定性是其他方案无可比拟的：
--文章表createtablepost{
post_idint(11)NOTNULLAUTO_INCREMENT,
......
star_numint(11)COMMENT'点赞数目'
}--用户表createtableuser{
user_idint(11)NOTNULLAUTO_INCREMENT,
......
star_numint(11)COMMENT'点赞数目'
}--点赞表createtablestar{idint(11)NOTNULLAUTO_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]>setstar:tid:888898//设置点赞数目
OK127.0.0.1:6379[2]>incrstar:tid:888//实现数目自增(integer)899
场景b：点赞去重，避免重复点赞
要实现这个需求，必须有文章点赞的uid列表，以uid为key场景c：通常在用户中心，可以看见用户自己的点赞列表
这个需求可以使用场景b的数据来实现。
场景d：文章的点赞列表，类似场景b快手双击点赞是什么功能，以文章id为key
//以文章id=888为例127.0.0.1:6379[2]>saddstar:list:tid:888123456789//点赞uid列表(integer)3127.0.0.1:6379[2]>sismemberstar:list:tid:888456//判定是否点赞(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，就会有一致性问题，这就是另外一个很重要的话题了。以后有时间再细聊吧！
中国程序员VS法国程序员，这也太形象了吧...研究主攻数据库和c盘故障优化，曾经复读才考上三本，他现在让华为开出201万月薪 DBA林工：OracleDG 环境主备业务数据不同步备库报 ORA-600 错误如何整？ 那种从上海流水线去了洛杉矶做程序员的女工，最近待业了乘风破浪的中国数据库有个程序员女友有多爽？？？做一个国产操作系统，有多难？MySQL 的这个 BUG，坑了多少人？为什么不建议把数据库布署在docker容器内？A里正在拆中台，你还在建中台吗？腾讯技术专家：解密小程序云开发数据库 | 干货微服务构架框架？这里为你汇总了15种阿里P8税前收入170万？P8、P9 及以上到底是什么水平？机房生存手册交易、账务系统去 Oracle 经验误执行了 rm -rf /*删库以后，除了跑路能够如何整？！
DTCC中国数据库技术会议2020-2019SACC2019中国系统架构师会议PostgreSQL 2019中国技术会议 点击上方文字可以直接步入小程序浏览， 下载请在后台分别回复关键词 DTCC、SACC、PG19 即可直接收到完整版 PPT 下载链接
你「在看」吗？
