V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
broadliyn
V2EX  ›  问与答

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

  •  
  •   broadliyn · 2015-07-26 23:55:38 +08:00 · 4061 次点击
    这是一个创建于 3408 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

    6 条回复    2015-07-27 09:52:23 +08:00
    pi1ot
        1
    pi1ot  
       2015-07-27 00:21:22 +08:00
    更新要求高的用push方式主动更新cache就可以。
    绝大部分用户根本不翻页,可以统计一下,选一个合适的范围,一般超过10页就不用缓存了,直接查库更快。
    mhycy
        2
    mhycy  
       2015-07-27 00:25:34 +08:00
    @pi1ot 目测已经做了触发式了,因为现在是在有序集合里面存放ID于排序值。
    这个有序集合看起来有点像是链表,不知道对不对。

    其实重构整个缓存在全站的消耗里面应该可以忽略不计才对。
    即使文章过亿,需要花费数秒钟时间重构全站缓存,在用户的访问面前都是可以接受的,不必过早优化。
    imn1
        3
    imn1  
       2015-07-27 02:54:26 +08:00
    缓存文章,实时刷“序号”,通过序号+css控制显示
    humiaozuzu
        4
    humiaozuzu  
       2015-07-27 07:12:37 +08:00
    内存不够那就要运维做 redis 集群啊,其次就是通过调整存储的数据大小和缓存的时间来看看对命中率的影响,可以省下不少内存 https://ruby-china.org/topics/22761
    zeayes
        5
    zeayes  
       2015-07-27 08:34:48 +08:00
    @imn1 这个是app,不是web。
    handleyan
        6
    handleyan  
       2015-07-27 09:52:23 +08:00
    这么舍不得redis内存,自己基于list的api和跳表的原理实现有序表的增改删不就行了?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1998 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 00:50 · PVG 08:50 · LAX 16:50 · JFK 19:50
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.