马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
×
办理发布H5后由于当地缓存白屏方案
一、 焦点设置优化(条件是访问网站的哀求能抵达服务器)
方案一:前端项目设置全局不缓存方案
- 运行逻辑:在H5服务器设置中增长Cache-Control: no-cache或max-age=0相应头,禁用静态资源缓存;
- 优点:能在服务器出口处最大大概地办理发布项目缓存题目
- 缺点:用户在差别界面跳转都会重新加载界面信息,影响整个前端加载速率,高并发时轻易造成带宽压力
方案二: 首页index.html资源缓存修正,禁制index.html文件缓存
- server {
- listen 8080;
- root /var/www/web/;
- location /index.html {
- add_header Cache-Control "no-cache, no-store, must-revalidate, private";
- add_header Pragma "no-cache";
- add_header Expires "0";
- try_files $uri /index.html;
- }
- location / {
- try_files $uri $uri/ /index.html;
- }
- }
复制代码
- 优点: 单页面应用设置首页模板欺凌不缓存,用户欣赏器不会缓存 index.html 文件,每次都会向服务器拉取新的首页模板,确保用户不会利用汗青模板。
- 缺点: 用户不缓存首页,每次都会拉取,导致每次进入体系都会等候相对较长的时间。
方案三: 首页 index.html 资源添加 ETag和Last-Modified 参数
- server {
- listen 8080;
- root /var/www/web/;
- location /index.html {
- etag on;
- if_modified_since exact;
- add_header Cache-Control "public, max-age=0";
- expires modified +1y;
- try_files $uri /index.html;
- }
- location / {
- try_files $uri $uri/ /index.html;
- }
- }
复制代码
- ETag:是服务器为资源天生的唯一标识符(如哈希值或版本号),内容厘革时标识会更新。
- Last-Modified: 服务器返回资源的末了修改时间戳
- 运行逻辑:客户端初次哀求资源时,服务器返回 ETag 和 Last-Modified。后续哀求中,客户端大概同时发送 If-None-Match 和 If-Modified-Since。服务器优先查抄 ETag 与 Last-Modified(若存在),直接返回 304,欣赏器利用缓存文件;因 ETag 精度更高,若匹配,则会忽略 Last-Modified。
- 优点:能检测到内容字节级别的厘革大概文件体系时间戳的厘革,从而让用户端利用新的文件;通过查验文件的方式实验高效缓存战略,可有效利用客户端缓存,提拔网站性能并低沉服务器压力。
- 缺点:
若多服务器间文件属性或文件时间戳不同等,大概导致 ETag/Last-Modified 辩论(假如是一个jenkins编译,将一个编译包放到两个服务器(服务器体系版本同等)中实现负载平衡,可以利用ETag,假如利用k8s等其他工具发布必要注意文件同步,可以利用分布式文件体系或同步工具);
高并发时每一次哀求都会查验哀求的ETag会占用相对校对的CPU性能(针对现在在线理赔的并发量,可忽略不计);
太过于依靠当地缓存,假如哀求头校验通过但是当地缓存非常会造成未知非常(现在有人说大概会出现的题目,但是并未在某处真的搜刮到干系bug内容);
可以用:curl -I https://域名 来检察哀求头内容
二、 jenkins发布流程优化方案
- 运行逻辑:每次发布 jenkins 时不删除上一个版本的js文件,直接将新的js放在原有目次下,到达新老版本js共存的目的,当用户利用欣赏器缓存的界面读取老版本的js不会由于文件不存在而报错。等候用户欣赏器辨认到更新后会更新到新版本。
- 优点:
用户不会由于发布拿不到js文件而白屏,根本可以办理由于发布缓存而白屏的题目。
- 缺点:
用户利用老版本的js进入体系后,无法利用新功能,假如前后端代码功能不同等会导致用户利用失败;假如用户长时间没有触发更新机制,会导致更新功能在一段时间内用户无法利用;
随着每次发布,服务器上的js文件会越来越多,当到达肯定命量级后会影响服务器对文件的读取速率必要不定时人为处置处罚久远的汗青版本(服务器脚本示例,注意不要复制利用,必要根据本身的项目确认删除的数据,数据无价删除许审慎:保存迩来2个版本
ls -t /path/to/dist/js/app.*.js | tail -n +3 | xargs rm -f)。
三、 利用版本号方案
通事后端更新版本号
- 运行逻辑:后端在体系中开放一个公开接口用于吸收并返回当前版本号,前端必要给装备界说一个唯一装备号生存在欣赏器;前端每次加载完 index.html 首页模板后,在渲染js之前对后端发起一个版本号对比哀求,后端日志
生存前端提交哀求的版本号与装备号并返回当前体系版本,假如前端当地生存的版本与后端不同等,则前端利用Service Worker缓存控制通过workbox-webpack-plugin扫除旧版本文件缓存,然后再革新界面渲染js。
- 优点:可以在发布代码之后,通过日志
检察是否有效户仍然是老版本发起哀求,可以通过参数查询同一装备是否在进入老版本后又重新进入了新版本,同时拥有汗青日志 可以判断装备号属于哪个用户,而且可以人为在数据库修改版本号来实现控制用户革新次数。
- 缺点:开辟测试工作量相对较大,每次发布必要人为修改数据库版本号(大概写成接口放在jenkins中主动触发);
|