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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

› Redis

This topic created in 2086 days ago, the information mentioned may be changed or developed.

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

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

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

Redis

总数

异步

29 replies • 2020-08-13 09:50:26 +08:00

IMCA1024

Aug 11, 2020

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

MIUIOS

Aug 11, 2020

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

fdingiit

Aug 11, 2020

为什么要删 redis 数据？

Veneris

Aug 11, 2020

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

MIUIOS

Aug 11, 2020

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

palmers

Aug 11, 2020

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

MIUIOS

Aug 11, 2020

@fdingiit 防止内存庞大

luckyrayyy

Aug 11, 2020

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

yuzo555

Aug 11, 2020

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

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

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

yuzo555

Aug 11, 2020

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

ericgui

Aug 11, 2020

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

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

rushssss

Aug 11, 2020

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

liyunlong41

Aug 11, 2020 via iPhone

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

limboMu

Aug 11, 2020

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

rogwan

Aug 11, 2020

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

lithbitren

Aug 11, 2020

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

sujin190

Aug 11, 2020

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

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

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