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

[totoro52]

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

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

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

[microget]

产品经理的 KPI 吧

[swulling]

其实以你们产品的并发，根本就用不上 redis

[wweir]

既要实时又要高并发，单点可以实现，不过说起来很多业务不敢这么玩

[totoro52]

哈哈哈 谢谢各位的回复，我懂了，我明天 TM 就把产品经理杀了祭天

[locoz]

消息队列慢慢入库+伪实时数量？

[1018ji]

实时点赞，这真是个牛逼的需求

[Leigg]

实时点赞真没必要，非要解决的话上数据放内存里。

[kisshere]

都能把 MySQL 的 update+1 给写崩溃了，你这站的访问量也太大了吧，如果真有那么大，别拿 MySQL 存点赞数，拿其他硬盘型的 nosql 存

[CoderGeek]

减少数据库更新 第一次从库加载在到 redis 做自增 一段时间 定期刷库 不好吗