关于点赞模块在高并发下的优化处理，求方案

[totoro52]

目前我涉及到做点赞这块，起初的设计是直接落库，用户的点赞和取消点赞直接对记录进行加减，这样的方案似乎很简单看起来也没啥问题，但是一旦流量多了起来，数据库肯定扛不住这么频繁的读写。

我参考了一些网上教程，基本都是采用 redis 异步入库，就是点赞和取消都交给 redis，redis 记录了点赞人和被点赞人，同时在另外记录点赞总数，然后通过定时任务进行异步落库并删除 redis 中的指定数据。

但是现在新的问题来了，当我要查询某个文章的点赞总数的时候，怎么保证数据的一致性呢，岂不是查询的总数的时候需要 mysql+redis = 总数才能保证唯一性，因为 redis 入库后记录就被删除了，防止内存庞大，而且 redis 并不会做持久化，麻烦做过这方面的大牛给我指点指点

[IMCA1024]

非要实时的点赞数据吗，有特殊需求？

[totoro52]

有的，点赞在前台展示是需要保证实时的

[fdingiit]

为什么要删 redis 数据？

[Veneris]

[微博计数器的设计(下)]( https://blog.cydu.net/weidesign/2012/09/09/weibo-counter-service-design-2/)

[totoro52]

@IMCA1024 我的考虑是不实时，然后异步入库的定时时间设置短点，比如 5 分钟，但是这样的解决方案不满足需求。

[palmers]

是不是可以通过期策略 来解决部分问题?

[totoro52]

@fdingiit 防止内存庞大

[luckyrayyy]

超大并发下查询准确实时的点赞数量，本身不就是个伪需求嘛...谁会关心这个？

[yuzo555]

Redis 设置过期时间，根据周期使用不同的 Redis 键名，比如周期一天，文章 ID 是 123，那么点赞键名比如说是 like_123_20200811 （计数），like_123_20200811_user （ list，记录用户）。

第一次创建时（用 incr 增加计数键，判断返回值即可知道是否为第一次）设置一个 25 小时的过期时间。

定时比如每天 0:30 统计昨天的数量，加到数据库。

[yuzo555]

如果更短的周期可以用时间戳除以周期秒数取整来代替日期

[ericgui]

@luckyrayyy 其实这些都可以解决的，但就看你花费多大的成本。

比如，超大并发下查询交易金额（双十一），这绝地的刚需，必须保证数据准确，对吧
但超大并发下查询点赞数，就有点那啥了，确实没必要。

[rushssss]

入库后删 redis 数据是个啥操作

[liyunlong41]

Redis 使用 hash，大 key 使用文章 ID，小 key 为 userid，定时任务隔一段时间落库，没做过点赞，不知道这样是否能满足需求？

[limboMu]

mysql 里记录的数也可以放到 redis 啊,只要加一个版本号，按版本更新 redis 和 mysql 里的值就好了呀

[rogwan]

实时入库并没有什么大的压力，主要是查询。每次请求都要查询很多个点赞数的统计，这个有点过渡消耗了。一个取巧的方式是超过一定数量之后，就不再计算了，之间显示 “999” 这样。如果点赞数是一个重要的指标，那还是 redis 实时处理，批量入库。

[lithbitren]

点赞的精确需求一般都是前端解决，来回点赞取消前端先切数量，其他人的赞可以延迟处理

[sujin190]

多高的并发啊，就算 mysql update +1 这个性能是非常高的吧，再加上分库分表啥的，十万级 tps 应该是能轻松达到的吧，而点赞的日志会受限写入性能，那么完全可以异步队列落地就是了

先把点赞数加上去，前端缓存结果，然后用队列异步落地点赞记录，绰绰有余了

再不行把点赞数加在 redis 里，点赞记录也在 redis 加缓存，然后点赞记录推队列，异步落地 mysql 一小短时间后再回写 redis 确保准确，这样还不够你用的话，估计预算该上亿了吧，还问啥啊，找点牛人再做一个专门为点赞优化的的数据库就是了，千万级 tps 都小 case 了

[CoderGeek]

redis 自增为啥不行呢

[janxin]

感觉是个伪需求，要看你们的数据量大概是什么样子的。

其实你提到的加和处理就是一个方案，而且基本也能满足绝大部分场景下的需求。

更进一步方案需要根据你的数据量评估啊，比如你并发很高但是热点很集中和并发很高热点数据不是相对集中做法都是不一样的...

[wysnylc]

要性能就得接受延时,要实时就得接受低速,二者不可皆得