我工作的项目也是 mysql，redis 混用，redis 一般做聊天系统，排行榜，存储用户的一些临时数据，我觉得你说的这个需求不太适合 redis 的使用场景吧

#1 楼 @jasonliu 点击数这种东西更新十分频繁，放在 redis 里面也不合适么

#2 楼 @42thcoder 记录帖子的点击数和喜欢数这个很适合 redis 哈

#2 楼 @42thcoder 可以看下这个http://blog.nosqlfan.com/html/2235.html

优化之前测一下数据，真的成为瓶颈了吗？

针对你提到的例子，我想可以这样子解决：

同时在 MySQL 里存储一份数据，也就是说帖子的喜欢数和点击数同时也放在帖子表（或者新建一张帖子统计信息表），因为实时更新 MySQL 可能导致性能问题，可以定期同步数据，比如每天凌晨的时候跑一个任务更新数据表。 这样就可以使用 MySQL 查询过滤获取所需数据，但是存在数据不那么精确问题，需要考虑需求方能否接受。

推广到更广泛的问题，因为 Redis 和 MySQL 分开存储，如果业务需要联合使用这两部分的数据，就需要聚合数据，简单的聚合数据可以在程序里完成，复杂的聚合可能需要在 MySQL 同时保持数据的副本，而且可能导致数据非实时同步问题。

再广泛的情况，聚合数据，还可以通过建立数据集市（数据仓库），导入专门的检索系统（比如 solr / elastic search）完成。

简单玩的话老老实实把 redis 作为 cache 构成 tied storage。 点击数喜欢数先写在 redis 里，然后每隔一段时间 flush 到 db 里去就好了。 等你的论坛已经大到计数会影响性能的时候，这一段时间的延迟已经根本不是问题了。

实测统计数据先存在 redis 然后再写入数据库，对于每分钟批量更新约 15000 请求来说，在一台 i5 的机器上 CPU 消耗不会超过 5%。 根本不是瓶颈。

#6 楼 @vincent thks a lot

@jasonliu @hooooopo @Rei @42thcoder @msg7086 可能对于论坛帖子的例子优化的必要性不大，但楼主提到的情形还是有很多现实的场景。

例如：有很大的用户表 users（数千万），用户有一些属性包括性别，年龄，地区等等，另外通过 redis 记录用户最新访问时间，业务上有很多筛选客户的需求，需要组合各种属性条件和最新访问时间，这个时候就需要聚合数据了。

#4 楼 @jasonliu 果断学习下

#10 楼 @vincent 我还是觉得定期写入数据库比较好。毕竟要做查询，数据库比较方便。

#10 楼 @vincent 其实就是数据分级咯？甚至一些陈年数据可以迁移至另外的数据库以减轻服务器压力？

?

#12 楼 @msg7086 对的，关系数据库查询比较方便，有强大的 SQL 支持，而 NoSQL 通常查询有很大限制。

#13 楼 @cassiuschen 的确和数据分离解决问题思路有点儿类似，但还是很大不同，这里相当于异构数据库（NoSQL 和 SQL）的数据聚合，历史数据分离通常还是在同一种数据库中进行。

#16 楼 @vincent 我比较了解的项目中，有一个极端案例：全国高校数字图书馆的编目库，上千万的条目而且随时在变，它们解决的思路是所有信息存在 Mongo 里，索引存在 Oracle 里，目前来说两者配合的很好

#15 楼 @vincent :plus1: