一个关于分页缓存设计的问题。

我目前开发的项目是一个新闻客户端app。在开发重构过程中对现有缓存设计感觉不是很完善。

对于分页缓存这块，项目需求是这样的：
1.因为经常有实时热点，所以如果出现重大事件发稿之后缓存必须要及时刷新。
2.因为上边的老大哥盯着，所以一些新闻出了问题需要撤稿也必须实时刷新。
3.新闻可以调整顺序，比如可以把某一篇新闻拉倒第1、2、3....等位置。

简单的说，就是要求做到缓存刷新必须及时。

目前我们项目里边对于这块是这么设计：
1.采用redis作为缓存
2.使用缓存id列表+对象进行
3.使用redis的有序集合来存分页列表的id，一个频道对应N篇新闻的id全部放到一个有序集合里，然后设置一个排序值来控制新闻在列表中的顺序。

redis的有序集合作为列表分页的确是个很好使的东西，特别是对于调整顺序、发稿、撤稿不需要刷新整个缓存列表。

但是有个问题就是，redis的这个有序集合类型占用内存有点吓人。目前虽然足够用，但是日后肯定会不够。（因为整个项目里边凡是涉及到分页的全是这种数据类型的缓存。）

如果是用传统的从数据库里查出来，然后缓存这个id列表，在调序、发稿、撤稿时，你几乎要把所有的缓存列表全部都delete掉然后重新reload。

所以，想来请教一下，面对这样的需求，是否有比redis 有序集合更好的解决方案呢？？

mhycy

2015-07-27 00:25:34 +08:00

@pi1ot 目测已经做了触发式了，因为现在是在有序集合里面存放ID于排序值。
这个有序集合看起来有点像是链表，不知道对不对。

其实重构整个缓存在全站的消耗里面应该可以忽略不计才对。
即使文章过亿，需要花费数秒钟时间重构全站缓存，在用户的访问面前都是可以接受的，不必过早优化。