切图仔学后端-缓存

简介: 切图仔学后端-缓存

前言

你好,我是一个前端切图仔。这是一篇切图仔学后端的学习笔记,今天我们盘的是缓存。本文实例搭建依赖的是 Node.js

缓存(cache),原始意义是指访问速度比一般随机存取存储器(RAM)快的一种高速存储器。

而在广义意义上,同样是存储的结构,若前者比后者的访问速率快一个量级,则称前者为后者的缓存。比如cache比内存快,内存取值比硬盘快等。

缓存简介

一般缓存都有如下特征:

  • 命中率:命中率=正确结果数/请求缓存次数。它是衡量缓存有效性的重要指标,命中率越高,表名缓存的使用率越高
  • 最大空间:可以存放元素的最大数量,若超过这个值,那么会触发清空策略
  • 清空策略:
  • FIFO(first in first out)先进先出策略,最先进入缓存的优先被清除掉。
  • LFU(less frequently used)最少使用策略,无论是否过期,清除最少使用的元素
  • LRU(least recently used)最近最少使用策略,无论是否过期,根据元素最后一次被使用的时间戳,清除最远使用时间戳的元素释放空间。

客户端缓存

打开 ChromeNetwork 面板,我们可以看到如下信息: 8.png

看到 Size 栏,我们可以看到这些资源部分是来自memory cache亦或是disk cache,还有 status 栏里面没有显示出来的 304 状态码。下面分别介绍这些。

加载资源顺序一般如下:

  1. 先去内存看,如果有,加载
  2. 内存没有,去硬盘看,如果有,加载
  3. 硬盘没有,则发起网络请求
  4. 加载到的资源根据规则缓存到硬盘和内存

memory cache & disk cache

  • 内存缓存(from memory cache):内存缓存具有两个特点,分别是快速读取和时效性:
  • 快速读取:内存缓存会将编译解析后的文件,直接存入该进程的内存中,占据该进程一定的内存资源,以方便下次运行使用时的快速读取。
  • 时效性:一旦该进程关闭,则该进程的内存则会清空。
  • 硬盘缓存(from disk cache):硬盘缓存则是直接将缓存写入硬盘文件中,读取缓存需要对该缓存存放的硬盘文件进行I/O操作,然后重新解析该缓存内容,读取复杂,速度比内存缓存慢。

在浏览器中,浏览器会在js和图片等文件解析执行后直接存入内存缓存中,那么当刷新页面时只需直接从内存缓存中读取(from memory cache);而css文件则会存入硬盘文件中,所以每次渲染页面都需要从硬盘读取缓存(from disk cache)。

强缓存&协商缓存

在网络请求中,缓存一般分为强缓存和协商缓存,下面分别介绍:

强缓存

强制缓存就是向浏览器缓存查找该请求结果,并根据该结果的缓存规则来决定是否使用该缓存结果的过程,强制缓存的情况主要有三种(暂不分析协商缓存过程),如下:

  • 不存在该缓存结果和缓存标识,强制缓存失效,则直接向服务器发起请求
  • 存在该缓存结果和缓存标识,但该结果已失效,强制缓存失效,则使用协商缓存
  • 存在该缓存结果和缓存标识,且该结果尚未失效,强制缓存生效,直接返回该结果

那么强制缓存的缓存规则是什么?

当浏览器向服务器发起请求时,服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器,控制强制缓存的字段分别是ExpiresCache-Control,其中Cache-Control优先级比Expires高。

Expires

ExpiresHTTP/1.0控制网页缓存的字段,其值为服务器返回该请求结果缓存的到期时间,即再次发起该请求时,如果客户端的时间小于Expires的值时,直接使用缓存结果。

ExpiresHTTP/1.0的字段,但是现在浏览器默认使用的是HTTP/1.1,那么在 HTTP/1.1 中网页缓存还是否由 Expires 控制?

到了HTTP/1.1Expire已经被Cache-Control替代,原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比,那么如果客户端与服务端的时间因为某些原因(例如时区不同;客户端和服务端有一方的时间不准确)发生误差,那么强制缓存则会直接失效,这样的话强制缓存的存在则毫无意义,那么Cache-Control又是如何控制的呢?

Cache-Control

HTTP/1.1 中,Cache-Control是最重要的规则,主要用于控制网页缓存,主要取值为:

  • public :所有内容都将被缓存(客户端和代理服务器都可缓存)
  • private :所有内容只有客户端可以缓存,Cache-Control的默认取值
  • no-cache客户端缓存内容,但是是否使用缓存则需要经过协商缓存来验证决定
  • no-store所有内容都不会被缓存,即不使用强制缓存,也不使用协商缓存
  • max-age=xxx :缓存内容将在xxx秒后失效

协商缓存

协商缓存就是强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程,主要有以下两种情况:

  • 协商缓存生效,返回304
  • 协商缓存失效,返回200和请求结果结果

同样,协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的,控制协商缓存的字段分别有:Last-Modified / If-Modified-SinceEtag / If-None-Match,其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。

Last-Modified / If-Modified-Since

Last-Modified是服务器响应请求时,返回该资源文件在服务器最后被修改的时间,如下。

If-Modified-Since则是客户端再次发起该请求时,携带上次请求返回的Last-Modified值,通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求,发现请求头含有If-Modified-Since字段,则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比,若服务器的资源最后被修改时间大于If-Modified-Since的字段值,则重新返回资源,状态码为200;否则则返回304,代表资源无更新,可继续使用缓存文件。

Etag / If-None-Match

Etag是服务器响应请求时,返回当前资源文件的一个唯一标识

If-None-Match是客户端再次发起该请求时,携带上次请求返回的唯一标识Etag值,通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后,发现该请求头中含有If-None-Match,则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比,一致则返回304,代表资源无更新,继续使用缓存文件;不一致则重新返回资源文件,状态码为200

注:Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since,同时存在则只有Etag / If-None-Match生效。

小结

强制缓存优先于协商缓存进行,若强制缓存(Expires和Cache-Control)生效则直接使用缓存,若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match),协商缓存由服务器决定是否使用缓存,若协商缓存失效,那么代表该请求的缓存失效,重新获取请求结果,再存入浏览器缓存中;生效则返回304,继续使用缓存。

Node实现

有了上面的理论知识支持之后,我们可以尝试用Node.js来添加缓存的支持。缓存配置文件如下:

ps:source 为资源信息,部分代码已省略

const cache = {
    maxAge:3600,
    expires:true,
    cacheControl: true,
    lastModified: true,
    etag: true
}
module.exports = cache

接下来实现缓存判断的中间件逻辑


function refreshRes(stats, res) {
    const {maxAge, expires, cacheControl, lastModified, etag} = cache;
    if(expires) {
        res.setHeader('Expires', (new Date(Date.now() + maxAge*1000)).toUTCString());
    }
    if(cacheControl) {
        res.setHeader('Cache-Control', `public, max-age=${maxAge}`);
    }
    if(lastModified) {
        res.setHeader('Last-Modified', stats.mtime.toUTCString());
    }
    if(etag) {
        res.setHeader('ETag', generateETag(stats));
    }
}

function isFresh(source){
    refresh(source,res)
    const lastModified = req.headers['if-modified-since'];
    const etag = req.headers['if-none-match'];
    if(!lastModified && !etag) {
        return false;
    }
    if(lastModified && lastModified !== res.getHeader('Last-Modified')) {
        return false;
    }
    if(etag && etag !== res.getHeader('ETag')) {
        return false;
    }
    return true;
}
module.exports = isFresh

在返回资源时判断:

if(isFresh(resource, req, res)) {
    res.statusCode = 304;
    res.end();
    return;
}

服务端缓存

在一些比较大流量的网站中,离不开缓存层。为的也是减轻数据库层面的负担,常用的缓存系统有 MemcachedRedis。我们先来手写一个简单的缓存类,来看看这类型的缓存是咋的一回事。

Cache.js

一开始我们希望Cache有如下特征:

  • 键值对存储
  • 增删查方法
  • 过期机制

新建一个Cache.js,如下编码:

class Cache {
    constructor(maxAge = 1000 * 60 * 30,max = 10) {
        this.maxAge = maxAge
        //保存缓存的 Map
        this.cache = new Map()
        //过期时间 Map
        this.ttl = new Map()
        this.max = max
    }
    getCache(key) {
        let ttl = this.ttl.get(key)
        if ((+new Date()) - ttl >= this.maxAge) {
            //过期了则删除
            this.deleteCache(key)
            return null
        } else {
            return this.cache.get(key)
        }
    }
    setCache(key, value) {
        this.cache.set(key) = value
        this.ttl.set(key) = +new Date()
    }
    deleteCache(key) {
        this.cache.delete(key)
        this.ttl.delete(key)
    }
}

module.exports = Cache
  • 写出缓存时同时写入当前时间戳
  • 拿缓存时对比时间戳,过期则删除,返回空

LRU缓存淘汰

下面加入缓存淘汰机制,以当前用的最多的LRU机制为例。(貌似面试也很喜欢让手写这个)

  • set流程:
  1. 已经存在,提升
  2. 达到max,淘汰最后一个
  3. 更新过期时间
  • get流程:
  1. 不存在则返回空
  2. 过期则删除
  3. 提升数据,返回
  • delete流程:
  1. 不存在则直接返回
  2. 依次让key后面的元素覆盖
  3. 删除ttl的key
class Cache {
    constructor(maxAge = 1000 * 60 * 30, max = 10) {
        this.maxAge = maxAge
        //保存缓存的object
        this.cache = [];
        this.max = max
        //过期时间object
        this.ttl = new Map()
    }
    getCache(key) {
        let index = this.findIndex(key);
        if (index === -1) {
            return undefined;
        }
        if ((+new Date()) - this.ttl.get(key) >= this.maxAge) {
            this.deleteCache(key)
            return undefined
        } else {
            // 删除此元素后插入到数组第一项
            let value = this.cache[index].value;
            this.cache.splice(index, 1);
            this.cache.unshift({
                key,
                value,
            });
            return value;
        }
    }
    setCache(key, value) {
        let index = this.findIndex(key);
        // 已经存在,提升
        if (index > -1) {
            this.cache.splice(index, 1);
        } else if (this.cache.length >= this.capacity) {
            // 若已经到达最大限制,先淘汰一个最久没有使用的
            this.cache.pop();
        }
        this.cache.unshift({
            key,
            value
        });
        this.ttl[key] = +new Date()
    }
    deleteCache(key) {
        let index = this.cache.findIndex(key)
        if(index == -1)return
        //依次提升
        for (let i = index; i < this.cache.length - 1; i++) {
            this.cache[i] = this.cache[i + 1]
        }
        delete this.ttl[key]
    }
    findIndex(key) {
        return this.cache.findIndex(item => key === item.key)
    }
}

module.exports = Cache

Memcached

简介

随着互联网的发展,传统的关系型数据库开始出现瓶颈。例如:

  • 对数据库的高并发读写,处理过程复杂耗时。
  • 海量数据处理,对于关系型数据库查询海量数据效率会很低

Memcached是高性能的分布式缓存服务器,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度。

简单实例

在本地安装好Memcached后,安装node依赖:npm install memcached --save。再次简单封装一个Cache类如下:

const Memcached = require('memcached');
const memcached = new Memcached('localhost:11211');

class Cache {
    get(key) {
        return new Promise((resolve, reject) => {
            memcached.get(key, (err, data) => {
                if (err) {
                    reject(err)
                } else {
                    resolve(data)
                }
            })
        })
    }
    set(key, value, lifetime) {
        return new Promise((resolve, reject) => {
            memcached.set(key, value, lifetime, (err, data) => {
                if (err) {
                    reject(err)
                } else {
                    resolve(data)
                }
            })
        })
    }
}


const cache = new Cache()
async function test() {
    var json = {
        name: 'abc',
        age: 12,
        sa: 16
    }
    await cache.set('t', JSON.stringify(json), 0)
    const res = await cache.get('t')
    console.log(res)
}
test()

当一个请求过来时,比如要获取首页的文章,可先从缓存中取,若取不到则读取数据库然后加入缓存,下次来时可以直接从缓存返回。

ps:MySQL数据库操作:为Node.js加一个DB类

async getSubject(){
    let sql = `SELECT * FROM subject`
    let key = md5(sql)
    let data = await cache.get(key)
    let result
    if(!data){
        result = await db.table('subject').select()
        cache.set(key,JSON.stringify(result))
    }
    return result
}

分布式布置方案

当1台不能满足我们的需求,需要布置多台时,怎么保证一个数据保存到哪台服务器上呢?有两种方案,一种是普通Hash分布,另一种是一致性Hash分布。下面分别介绍

普通Hash分布

普通Hash函数大概如下:

function hash($key) {
    let md5Str = md5($key).substring(0, 8)
    let seed = 31
    let hash = 0
    for (let i = 0; i < 8; i++) {
        hash = hash * seed + md5Str[i].charCodeAt()
        i++
    }
    return hash & 0x7FFFFFFF
}
  • md5key处理成一个32位的字符串,取前8位
  • hash处理成一个整数返回

假设配置两台服务器,则可以如下映射:

let servers = [{
    host: '192.168.1.12',
    port: 6397
}, {
    host: '192.168.1.20',
    port: 6397
}]

let key = 'key'
let value = 'value'
let config = servers[hash(key) % 2]
const memcached = new Memcached(config)

一致性Hash分布

在服务器数量不发生变化时,普通Hash可以很好地运作。但是当服务器数量发生改变时,增加一台服务器,同一个key经过hash之后会跟增加之前的结果不一样,这会导致数据丢失。为了把丢失的数据减少到最少,可以使用一致性Hash算法。

相关文章
|
21天前
|
缓存 NoSQL Java
后端开发中缓存的作用以及基于Spring框架演示实现缓存
后端开发中缓存的作用以及基于Spring框架演示实现缓存
17 1
|
2月前
|
NoSQL Redis 缓存
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
【5月更文挑战第17天】Redis常被称为单线程,但实际上其在处理命令时采用单线程,但在6.0后IO变为多线程。持久化和数据同步等任务由额外线程处理,因此严格来说Redis是多线程的。面试时需理解Redis的IO模型,如epoll和Reactor模式,以及其内存操作带来的高性能。Redis使用epoll进行高效文件描述符管理,实现高性能的网络IO。在讨论Redis与Memcached的线程模型差异时,应强调Redis的单线程模型如何通过内存操作和高效IO实现高性能。
51 7
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?
|
2月前
|
缓存 数据库 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?--主从切换方案
【5月更文挑战第16天】该方案提出了解决Redis缓存穿透、击穿和雪崩问题的策略。通过使用两个或多个互为备份的Redis集群,确保在单个集群故障时,另一个可以接管。在故障发生时,业务会与备用集群保持心跳检测,并根据业务重要性分批转移流量,逐步增加对备用集群的依赖,同时监控系统稳定性。对于成本敏感的小型公司,可以采用低成本的单机或小规模自建Redis备份。此方案强调渐进式流量转移,以保护系统免受突然压力冲击。
31 1
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?--主从切换方案
|
2月前
|
缓存 NoSQL Redis
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?--epoll调用和中断
【5月更文挑战第18天】`epoll`包含红黑树和就绪列表,用于高效管理文件描述符。关键系统调用有3个:`epoll_create()`创建epoll结构,`epoll_ctl()`添加/删除/修改文件描述符,`epoll_wait()`获取就绪文件描述符。`epoll_wait()`可设置超时时间(-1阻塞,0立即返回,正数等待指定时间)。当文件描述符满足条件(如数据到达)时,通过中断机制(如网卡或时钟中断)更新就绪列表,唤醒等待的进程。
54 6
|
2月前
|
缓存 NoSQL 中间件
【后端面经】【缓存】36|Redis 单线程:为什么 Redis 用单线程而 Memcached 用多线程?epoll、poll和select + Reactor模式
【5月更文挑战第19天】`epoll`、`poll`和`select`是Linux下多路复用IO的三种方式。`select`需要主动调用检查文件描述符,而`epoll`能实现回调,即使不调用`epoll_wait`也能处理就绪事件。`poll`与`select`类似,但支持更多文件描述符。面试时,重点讲解`epoll`的高效性和`Reactor`模式,该模式包括一个分发器和多个处理器,用于处理连接和读写事件。Redis采用单线程模型结合`epoll`的Reactor模式,确保高性能。在Redis 6.0后引入多线程,但基本原理保持不变。
45 2
|
2月前
|
存储 缓存 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存穿透
【5月更文挑战第14天】解决缓存穿透问题有两种策略。一是回写特殊值,当数据不存在时,在缓存中存储特殊值以标记,避免下次重复查询数据库。但此方法可能被恶意请求利用,浪费内存。二是使用布隆过滤器,预先判断数据是否存在,减少无效数据库查询。布隆过滤器虽有假阳性可能,但概率低,可接受。此外,可先查缓存再查布隆过滤器,优化正常请求的效率。两种方式各有优劣,实际应用需根据场景选择。
30 3
|
2月前
|
缓存 数据库 算法
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存击穿和雪崩、限流
【5月更文挑战第15天】本文介绍了如何解决缓存击穿和雪崩问题。对于缓存击穿,采用singleflight模式,确保即使热点数据导致大量请求未命中缓存,也只允许一个请求真正查询数据,其他请求等待其结果。对于缓存雪崩,解决方案是在设置过期时间时添加随机偏移量,避免所有数据同时过期。偏移量应与过期时间成正比。此外,限流也是一个重要策略,可以在服务层和数据库层实施,以限制请求流量,保护数据库免受高并发压力。
30 0
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---解决缓存击穿和雪崩、限流
|
2月前
|
缓存 数据库 NoSQL
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---缓存穿透、击穿和雪崩
【5月更文挑战第13天】本文讨论了三种常见的缓存问题:穿透、击穿和雪崩。缓存穿透发生时,请求的数据既不在缓存也不在数据库,可能导致数据库崩溃。缓存击穿指数据仅存在于数据库,热点数据的大量未命中请求会压垮数据库。缓存雪崩则是大量缓存在同一时间过期,引发数据库瞬间压力过大。为应对这些问题,需了解Redis部署(如Cluster或Sentinel)、故障恢复策略,以及公司如何保护数据库。解决缓存问题的经验和预防措施是面试中的重要话题。
27 0
【后端面经】【缓存】35|缓存问题:怎么解决缓存穿透、击穿和雪崩问题?---缓存穿透、击穿和雪崩
|
2月前
|
canal 缓存 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存,但面临缓存一致性问题,可借鉴Write Back策略解决。SingleFlight限制并发加载,减少数据库压力,适合热点数据。删除缓存模式在更新数据库后删除缓存,一致性问题源于读写线程冲突。延迟双删模式两次删除,理论上减少不一致,但可能降低缓存命中率。选用模式需权衡优劣,延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式,无侵入地增强现有缓存系统。
77 2
|
2月前
|
缓存 数据库 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。
35 0
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back