菜单开关

周梦康 发表于 2017-08-05 3295 次浏览 标签 : 网站架构实战

https://segmentfault.com/a/1190000010455076#articleHeader35

多级缓存

  1. 请求内缓存
    static 变量存储,比如朋友圈信息流,在一次性获取20条信息的时候,有可能,点赞的人里面20条里面有30个人是重复的,他们点赞你的a图片也点赞了你的b图片,所以这时,如果能使用static数组来存放这些用户的基本信息就高效了些。
  2. 本地缓存
    请求结束了,下拉更新朋友圈,里面又出现了上面的同样的好友,还得重新请求一次。所以本地常驻内存的缓存就更高效了。
  3. 分布式缓存
    在A服务器上已经查询过了,在下拉更新的时候被分配到B服务器上了,难道同样的数据再查一次再存到B服务器的本地缓存里面吗,弄一个分布式缓存吧,这样防止了重复查询。但是多了网络请求这一步。

很多时候是三者共存的。

避免缓存的滥用

案例分析

  1. 用户积分更新

    • 比如用户的基本信息和积分混在一起,当用户登录的时候赠送积分。则需要更新用户的积分,这个时候更新整个用户的基本信息缓存么?
    • 所以这里也可以运用下面 hashes 分片的原则去更新
  2. 礼物和主题绑定缓存
    为了取数据方便把多个数据源混合缓存了,这种情况,相比大家可能都见过,这是灾难性的设计。
{
id:x,
title:x,
gift:{
        id:x,
        name:x,
        img:x,
    }
}

如果需要更新礼物的图片,那么所有用到过这个礼物的话题的缓存都要更新。

redis 使用场景举例

由于比较基础基础好的老司机就可以忽略了,新人同学可以看下 https://mengkang.net/356.html

redis 优化

  1. 多实例化,更高效地利用服务器 cpu
  2. 内存优化,官方意见 https://redis.io/topics/memory-optimization 有点老
  3. 尽可能的使用 hashes ,时间复杂度低,查询效率高。同时还节约内存。Instagram 最开始用string来存图片id=>uid的关系数据,用了21g,后来改为水平分割,图片id 1000 取模,然后将分片的数据存在一个hashse 里面,这样最后的内容减少了5g,四分之一基本上。

每一段使用一个Hash结构存储,由于Hash结构会在单个Hash元素在不足一定数量时进行压缩存储,所以可以大量节约内存。这一点在String结构里是不存在的。而这个一定数量是由配置文件中的hash-zipmap-max-entries参数来控制的。

评论列表

回复 路人甲 2018-01-06 16:57:14
多级缓存可以讲得详细些吗?
比如:本地缓存是指存储到用户自己的本地吗,比如APP的话,存到用户自己手机
分布式缓存这块怎么理解
回复 周梦康 2018-02-03 12:19:48
回复路人甲: 存在app里对于客户端来说就是本地缓存,对于服务端和客户端整个体系来说它就是分布式缓存的一部分。