最近在做一个类似贴吧一样的东西，在数据上想用redis缓存，但是现在有两个想法，不知道哪个更实际一些，求大家指点。
所有内容都会存mysql这个没的说
帖子列表永驻redis这个也没的说
问题是帖子内容怎么办。
一种想法是存一定数量的帖子内容到缓存里，比如1000条。用户访问时根据所在页面和条数，前1000条的请求都从redis中读取，超过1000条之后的旧数据就从mysql中读取。有新帖子且缓存达到1000条时就LPUSH新的RPOP旧的。
另一种想法是所有新增的帖子数据都存在redis中，并且都设置一个过期时间，比如24小时。用户有访问过就将这条数据的过期时间增加到24小时，如果没有访问过就从redis中删除。用户访问的时候先查redis，查不到再去mysql中查，顺便再写入redis。
这两种办法哪个好一些？
回复内容：
最近在做一个类似贴吧一样的东西，在数据上想用redis缓存，但是现在有两个想法，不知道哪个更实际一些，求大家指点。
所有内容都会存mysql这个没的说
帖子列表永驻redis这个也没的说
问题是帖子内容怎么办。
一种想法是存一定数量的帖子内容到缓存里，比如1000条。用户访问时根据所在页面和条数，前1000条的请求都从redis中读取，超过1000条之后的旧数据就从mysql中读取。有新帖子且缓存达到1000条时就LPUSH新的RPOP旧的。
另一种想法是所有新增的帖子数据都存在redis中，并且都设置一个过期时间，比如24小时。用户有访问过就将这条数据的过期时间增加到24小时，如果没有访问过就从redis中删除。用户访问的时候先查redis，查不到再去mysql中查，顺便再写入redis。
这两种办法哪个好一些？
可以说明用户规模。
我认为第二种好，因为通用性强。
第一种如果业务变大，访问增多，就要改代码
第二种当然更实用一些，代码也容易实现。第一个逻辑复杂一些不太好弄。。。。。
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
不过第二个，你还可以改进一下:
在缓存失效的时候，需要先查询redis，找不到数据，再查询MySQL，最后再写入redis。这里更新缓存的时候会多出两次redis查询。
比不使用缓存还要慢。。。
缓存失效的时候，如果有并发请求，则会重复更新redis缓存。
你可以参考我用Python实现的一个类解决了第一点https://github.com/lloydzhou/StaleRedisCache
给缓存多设置一段缓冲时间
若在缓冲期内，直接使用过期数据，并使用异步任务更新缓存。
你还可以借用redis实现一个内存锁，解决上面第二点的并发问题。
(我项目中没有做，是因为外面有nginx页面缓存，在里面应用层很难遇到并发问题)
我说说自己的设计，当然前提是直接查询DB是不可行的情况下，不然也没必要折腾。
首先缓存是必然，优先考虑用户在浏览贴吧时常看的基本就是前10页（举例），那么完全没必要缓存全量数据，最好是仅缓存前10页即可，这个设计无论访问量多大都不会有太大问题，只要不出现大量的用户访问10页之后的数据。对于这个缓存其实我们只需要缓存帖子列表，而非帖子具体内容，所以不会占用太大内存。
对于帖子内容可以采用热点方式解决，即LRU，因为被查看的帖子基本都是固定的，即热点帖子，缓存只需要缓存这些帖子内容即可。
综上，其实就是题主的两种方案的结合，其实这两种方案并不是针对同一个问题的解决方案。
第一种吧，如果用户更新了帖子，同样要更新对应的数据缓存，一般帖子，旧帖子翻的人很少的。
第一种。我在乐视做评论时，就用的第一种
缓存帖子内容，用mysql或redis还不如使用mongodb
