1.微服务管理-11.缓存-3.实践-缓存使用

Posted 2023-05-05

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了1.微服务管理-11.缓存-3.实践-缓存使用相关的知识，希望对你有一定的参考价值。

参考技术A

微服务实践目录，可以参见连接。

缓存系列包括：
1.微服务管理-11.缓存概述
1.微服务管理-11.缓存-0.技术
1.微服务管理-11.缓存-1.多级缓存设计
1.微服务管理-11.缓存-2.典型缓存架构设计
1.微服务管理-11.缓存-3.实践-缓存使用
1.微服务管理-11.缓存-4.总结

在前面的几篇文章中讨论了很多关于缓存使用时要注意的事项。但在实际的工作中在哪些地方考虑这些事项其实还是不明确。为了帮助读者在生产中更好的使用缓存，本文主要以例子的方式说明在生产环境中使用缓存的方式。

结合前面几篇文章中的内容，并通过尽量的减少对于（相对）慢速服务/设备的访问来提高业务处理速度。但在业务处理过程中减少对于慢速服务/设备的访问并不一定就可以提升业务处理速度，并还有可能带来其他的问题。所以，这里展示几个例子来解释这些问题，并提供可用的生产环境方案。

在前几篇文章中出现过大量请求的时候的一个终极方案，如下：

这个方案参照了之前使用cdn缓存业务接口的方式来设计。通过OpenResty中支持的脚本语言Lua去控制本地返回还是使用Redis中结果返回。还有如果发生miss之后还需要调用后端服务来更新缓存。

这种方式的缓存的特点：适合IO密集型业务中，不适合计算密集型业务。并在业务过程中查看的业务占系统业务的绝大部分。例如：大型线上商城中的商品展示，新闻网站，网站门户，微博/陌生人社交，音视频服务，图片网站等。

在实际的缓存更新过程中一般有以下几种方式来更新缓存:

这几种方式针对不同的缓存模型来进行。

被动更新的特点在于有一个系统中的触发源去触发数据的更新动作。主动更新的特点在于只有用户在使用系统的特定功能时才会触发更新的动作。被动更新可以保证缓存和数据源之间的数据永远是一致的，并且不需要过多的补偿机制来保证数据一致性。主动更新的方式就会发生缓存和数据源中数据不一致的问题。所以，在后面会讨论在主动更新模式下尽量保证数据一致性的方式。

定时更新的方式在很多地方都有使用，例如CDN的定时溯源的机制就是以这种方式运行的。

事件更新中最核心的概念是事件，这里的事件最好是在领域驱动设计中的事件风暴阶段中这里出来的事件。因为这种事件代表着业务发生的动作，也代表着业务价值的流动。

在微服务架构模式下，任务、定时器都会由一个任务调度中心来完成。所以，在使用定时触发缓存更新时还是使用分布式任务调度中心来完成任务的调度工作。这样可以保证同一时间只有一个实例在处理。以这种方式简单的进行排他工作，防止同时操作缓存的问题。

用户触发更新也可以称为非固定周期更新，因为用户的触发时间是不确定的、任何时候都可能。有一种随机数的产生方式就是使用类似的机制：操作系统使用内核接受到中断的时间点作为随机数使用。所以，用户触发更新的方式就是一种随机发生的缓存更新。

下面一一说明图中内容的含义：

如上图中箭头所指向位置，在这里使用同步方式还是使用异步方式。从这两种方式产生的问题角度入手分析他们的优缺点：

不管同步还是异步都有可能造成 缓存击穿 问题，所以更新缓存的过程中最好进行一些排他动作以防止洪泛的发生。

主动更新、被动更新这些技术适应于不同的场景。它们各自有各自的优缺点，在技术设计阶段需要考虑实际的业务场景来决策到底使用那种方式合适。这个很多时候是需要设计人员的经验来进行决策。所以，任何一种软件设计过程都是一个决策和权衡的过程。

使用缓存的目标就是： 通过减少对慢速服务的访问，来提速 。所以在实际的缓存环境中，最主要的目标是减少访问慢速来达到使用缓存提速的目标。而在这个过程中可以使用的整体方案很多，可以通过不同事项的调整来完成自己的方案。

浅谈 Cache

前端缓存最佳实践

来源：黑金团队——掘金

前言

缓存，这是一个老生常谈的话题，也常被作为前端面试的一个知识点。

本文，重点在于探讨在实际项目中，如何进行缓存的设置，并给出一个较为合理的方案。

在介绍缓存的时候，我们习惯将缓存分为强缓存和协商缓存两种。两者的主要区别是使用本地缓存的时候，是否需要向服务器验证本地缓存是否依旧有效。顾名思义，协商缓存，就是需要和服务器进行协商，最终确定是否使用本地缓存。

两种缓存方案的问题点

强缓存

我们知道，强缓存主要是通过 http 请求头中的 Cache-Control 和 Expire 两个字段控制。Expire 是 HTTP1.0 标准下的字段，在这里我们可以忽略。我们重点来讨论的 Cache-Control 这个字段。

一般，我们会设置 Cache-Control 的值为 “public, max-age=xxx”，表示在xxx秒内再次访问该资源，均使用本地的缓存，不再向服务器发起请求。

显而易见，如果在xxx秒内，服务器上面的资源更新了，客户端在没有强制刷新的情况下，看到的内容还是旧的。如果说你不着急，可以接受这样的，那是不是完美？然而，很多时候不是你想的那么简单的，如果发布新版本的时候，后台接口也同步更新了，那就gg了。有缓存的用户还在使用旧接口，而那个接口已经被后台干掉了。怎么办？

协商缓存

协商缓存最大的问题就是每次都要向服务器验证一下缓存的有效性，似乎看起来很省事，不管那么多，你都要问一下我是否有效。但是，对于一个有追求的码农，这是不能接受的。每次都去请求服务器，那要缓存还有什么意义。

最佳实践

缓存的意义就在于减少请求，更多地使用本地的资源，给用户更好的体验的同时，也减轻服务器压力。所以，最佳实践，就应该是尽可能命中强缓存，同时，能在更新版本的时候让客户端的缓存失效。

在更新版本之后，如何让用户第一时间使用最新的资源文件呢？机智的前端们想出了一个方法，在更新版本的时候，顺便把静态资源的路径改了，这样，就相当于第一次访问这些资源，就不会存在缓存的问题了。

伟大的 webpack 可以让我们在打包的时候，在文件的命名上带上 hash 值。

 
   
   
 
  
    
    
  entry:{
  
    
    
   main: path.join(__dirname, ./main.js ),
  
    
    
   vendor: [ react ,  antd ]
  
    
    
  },
  
    
    
  output:{
  
    
    
   path:path.join(__dirname, ./dist ),
  
    
    
   publicPath:  /dist/ ,
  
    
    
   filname:  bundle.[chunkhash].js
  
    
    
  }

综上所述，我们可以得出一个较为合理的缓存方案：

HTML：使用协商缓存。
CSS&JS&图片：使用强缓存，文件命名带上hash值。

哈希也有讲究

webpack 给我们提供了三种哈希值计算方式，分别是 hash、chunkhash 和 contenthash。那么这三者有什么区别呢？

hash：跟整个项目的构建相关，构建生成的文件hash值都是一样的，只要项目里有文件更改，整个项目构建的hash值都会更改。
chunkhash：根据不同的入口文件(Entry)进行依赖文件解析、构建对应的chunk，生成对应的hash值。
contenthash：由文件内容产生的hash值，内容不同产生的contenthash值也不一样。

显然，我们是不会使用第一种的。改了一个文件，打包之后，其他文件的 hash 都变了，缓存自然都失效了。这不是我们想要的。

那 chunkhash 和 contenthash 的主要应用场景是什么呢？

在实际在项目中，我们一般会把项目中的 css 都抽离出对应的 css 文件来加以引用。如果我们使用 chunkhash，当我们改了 css 代码之后，会发现 css 文件 hash 值改变的同时，js 文件的 hash 值也会改变。这时候，contenthash 就派上用场了。

ETag计算

Nginx

Nginx 官方默认的 ETag 计算方式是为"文件最后修改时间16进制-文件长度16进制"。

例：ETag：“59e72c84-2404”

Express

Express 框架使用了 serve-static 中间件来配置缓存方案，其中，使用了一个叫 etag 的 npm 包来实现 etag 计算。从其源码可以看出，有两种计算方式：

方式一：使用文件大小和修改时间

 
   
   
 
  
    
    
  function stattag (stat) {
  
    
    
   var mtime = stat.mtime.getTime().toString(16)
  
    
    
   var size = stat.size.toString(16)
  
    
    
  

  
    
    
   return  "  + size +  -  + mtime +  "
  
    
    
  }

方式二：使用文件内容的hash值和内容长度

 
   
   
 
  
    
    
  function entitytag (entity) {
  
    
    
   if (entity.length === 0) {
  
    
    
   // fast-path empty
  
    
    
   return  "0-2jmj7l5rSw0yVb/vlWAYkK/YBwk"
  
    
    
   }
  
    
    
  

  
    
    
   // compute hash of entity
  
    
    
   var hash = crypto
  
    
    
   .createHash( sha1 )
  
    
    
   .update(entity,  utf8 )
  
    
    
   .digest( base64 )
  
    
    
   .substring(0, 27)
  
    
    
  

  
    
    
   // compute length of entity
  
    
    
   var len = typeof entity ===  string
  
    
    
   ? Buffer.byteLength(entity,  utf8 )
  
    
    
   : entity.length
  
    
    
  

  
    
    
   return  "  + len.toString(16) +  -  + hash +  "
  
    
    
  }

ETag 与 Last-Modified 谁优先

协商缓存，有 ETag 和 Last-Modified 两个字段。那当这两个字段同时存在的时候，会优先以哪个为准呢？

在 Express 中，使用了 fresh 这个包来判断是否是最新的资源。主要源码如下：

 
   
   
 
  
    
    
  function fresh (reqHeaders, resHeaders) {
  
    
    
   // fields
  
    
    
   var modifiedSince = reqHeaders[ if-modified-since ]
  
    
    
   var noneMatch = reqHeaders[ if-none-match ]
  
    
    
  

  
    
    
   // unconditional request
  
    
    
   if (!modifiedSince && !noneMatch) {
  
    
    
   return false
  
    
    
   }
  
    
    
  

  
    
    
   // Always return stale when Cache-Control: no-cache
  
    
    
   // to support end-to-end reload requests
  
    
    
   // https://tools.ietf.org/html/rfc2616#section-14.9.4
  
    
    
   var cacheControl = reqHeaders[ cache-control ]
  
    
    
   if (cacheControl && CACHE_CONTROL_NO_CACHE_REGEXP.test(cacheControl)) {
  
    
    
   return false
  
    
    
   }
  
    
    
  

  
    
    
   // if-none-match
  
    
    
   if (noneMatch && noneMatch !==  * ) {
  
    
    
   var etag = resHeaders[ etag ]
  
    
    
  

  
    
    
   if (!etag) {
  
    
    
   return false
  
    
    
   }
  
    
    
  

  
    
    
   var etagStale = true
  
    
    
   var matches = parseTokenList(noneMatch)
  
    
    
   for (var i = 0; i < matches.length; i++) {
  
    
    
   var match = matches[i]
  
    
    
   if (match === etag || match ===  W/  + etag ||  W/  + match === etag) {
  
    
    
   etagStale = false
  
    
    
   break
  
    
    
   }
  
    
    
   }
  
    
    
  

  
    
    
   if (etagStale) {
  
    
    
   return false
  
    
    
   }
  
    
    
   }
  
    
    
  

  
    
    
   // if-modified-since
  
    
    
   if (modifiedSince) {
  
    
    
   var lastModified = resHeaders[ last-modified ]
  
    
    
   var modifiedStale = !lastModified || !(parseHttpDate(lastModified) <= parseHttpDate(modifiedSince))
  
    
    
  

  
    
    
   if (modifiedStale) {
  
    
    
   return false
  
    
    
   }
  
    
    
   }
  
    
    
  

  
    
    
   return true
  
    
    
  }

我们可以看到，如果不是强制刷新，而且请求头带上了 if-modified-since 和 if-none-match 两个字段，则先判断 etag，再判断 last-modified。当然，如果你不喜欢这种策略，也可以自己实现一个。

后端需要怎么设置

上文主要说的是前端如何进行打包，那后端怎么做呢？我们知道，浏览器是根据响应头的相关字段来决定缓存的方案的。所以，后端的关键就在于，根据不同的请求返回对应的缓存字段。以 nodejs 为例，如果需要浏览器强缓存，我们可以这样设置：

 
   
   
 
  
    
    
  res.setHeader( Cache-Control ,  public, max-age=xxx );

如果需要协商缓存，则可以这样设置：

 
   
   
 
  
    
    
  res.setHeader( Cache-Control ,  public, max-age=0 );
  
    
    
  res.setHeader( Last-Modified , xxx);
  
    
    
  res.setHeader( ETag , xxx);

总结

在做前端缓存时，我们尽可能设置长时间的强缓存，通过文件名加 hash 的方式来做版本更新。在代码分包的时候，应该将一些不常变的公共库独立打包出来，使其能够更持久的缓存。

专注分享当下最实用的前端技术。关注前端达人，与达人一起学习进步！

长按关注"前端达人"

以上是关于1.微服务管理-11.缓存-3.实践-缓存使用的主要内容，如果未能解决你的问题，请参考以下文章

从优化性能到应对峰值流量：微博缓存服务化的设计与实践

微服务化之缓存的设计

微服务框架 SpringCloud微服务架构多级缓存 48 多级缓存 48.7 Redis 缓存预热

Redis最佳实践

surging 微服务框架使用系列之缓存-reids