澳门十大正规网站排行榜-点赞功效，用mysql还是redis？

点赞功效是现在app开发基本的功效今天我们就来聊聊 点赞、评论、收藏等这些场景的db数据库设计问题，1. 我们先来看看场景的需求： a. 显示点赞数量 b. 判断用户是否点过赞，用于去重，必须的判断 c. 显示小我私家点赞列表，一般在用户中心 d. 显示文章点赞列表我们先看一下头条和微博的例子头条的点赞微博的点赞 这两个都是具有顶级流量的，后端肯定有庞大的架构，我们今天只谈普通化的方案。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做同步。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 点赞的地方，如果点赞过显示红色，没有则显示黑白色， 今日头条是没有地方可以看到点赞列表的，而微博点进去，详情页可以看到点赞列表，可是只会显示最近的几十条，没有分页显示。如下图，我选了一条热点，拥有众多粉丝的“猪猪”帖子点赞列表 可能有人以为，点赞列表没人体贴，存储又会浪费大量资源，不如不存！可是，这个数据是必须要有的。

两点：a. 去重。点赞数可以不准确，但去重必须是准确的，b.另外一个社交产物，用户行为的一点一滴都需要记载，对于后续的用户行为分析和数据挖掘都是有意义的。上面使用string存储的用户点赞数量，除了string，还可以用hash来存储，对文章id分块，每100个存到一个hash，划分存入hash table，每个文章id为hash的一个key，value存储点赞的用户id，如果点赞用户许多，制止id过多发生性能问题，可以单列出来，用sorted set结构生存，热点的究竟是少数。

hash 方案优缺点比对hash：使用了更少的全局key ，节约了内存空间；可是也带来了问题如何凭据文章id路由到对应的hash？查找一个用户id是在hash还是set？存在不确定性使用hash虽然节约了空间，但增加了庞大度，如何选择就看小我私家需求了。除此之外，你另有其他的方法吗？3. 数据一致性 redis作为storage使用时，一定要做好数据的持久化，必须开启 rdb 和 aof，这会导致业务只能使用一半的机械内存，所以要做好容量的监控，实时扩容。

另外只要有数据copy，就会有一致性问题，这就是另外一个很重要的话题了。以后有时间再细聊吧！ 写在最后：把问题写明确，真不是一件容易的事情，请大家多多关注，留言，谢谢！ 前几天写的一篇文章，受到众多同行的热情回复，能和众多同行一起交流，深感荣幸！对于工程类问题，没有尺度的方案，一千小我私家有一千个方案，哪个最适合你只有你自己知道！期待你更好的思路和方法。

本文来源：澳门十大正规网站-www.syzhenglin.com