cache 应用加速
NGINX 向云原生演进,All in OpenNJet
需求
为了节省带宽、能够快速获取资源,在中间代理服务器上,通常会配置缓存。缓存机制的基本原理是将 Web 资源(如 HTML、CSS、JavaScript、图像等)保存在客户端或中间代理服务器上,以便在后续请求中直接使用该缓存副本,而不必重新获取资源。当客户端或代理服务器收到对资源的请求时,它们首先检查缓存,如果存在有效的缓存副本,可以直接返回缓存的副本,从而避免请求的发送和服务器端的处理过程。
但是上述的缓存机制仍然存在一定的问题,第一次访问资源是没有缓存的,所以首先要跟服务器通信,然后下载资源,如果带宽有限而且资源很大的情况(比如视频文件),客户端就会长时间处于下载阶段,效率低下。针对这种情况,我们就需要实现 cache 应用加速的功能。
cache 应用加速由 Web 管理员提前通过下发配置到代理服务器,由代理服务器提前下载资源并进行缓存,这样当客户端首次访问的时候也能够直接从缓存中获取资源,避免等待。
下面假设一种场景进行详细说明:
比如某银行总部上传了一个很大的文件,各银行分部第二天就需要使用这个文件,当银行分部员工下载这个文件的时候,由于带宽有限或者带宽资源紧张就可能导致该员工一直等待下载文件中,从而影响客户的办理进度。
基于该场景,现有 cache 缓存功能时序图如下:
而使用cache应用加速功能后,时序图如下:
方案
消息持久化
通过在 ctrl 进程中开启一个 cache 动态 API 入口,分别实现添加、删除配置接口以及动态获取进度接口
dyn_http_cache_module
Bash |
消息持久化:
采用与健康检查类似的持久化方式,使用 kv_get\kv_set 进行存取
reload:
reload 重启之后通过 kv_get 获取所有 cache 配置进行处理
前提:
- 需要 http 层配置 proxy_cache_path(zone下面以cache作为示例)
- 需要 http 层配置 map $purge_method (支持通过PURGE方法删除)
Bash |
proxy_cache_path参数说明:
参数 | 说明 |
/data/njet/cache | 缓存文件存放本地磁盘位置 |
levels=1:2 | 最多三级存放 |
keys_zone=cache:10m | 缓存使用的共享内存名称以及大小 |
purger=on | 是否支持purge清除 |
max_size=20g | 最大 cache 空间 |
inactive=30m | 缓存资源不活跃时间,超过该时间没被访问,该资源就会被清理 |
- 关于缓存是否缓存以及缓存时间:
被代理服务器上需要通知代理服务器缓存内容的时间,否则代理服务器不会对内容进行缓存,通过X-Accel-Expires,expires,Cache-Control “max-age=”其中一个参数指定时间。如果代理服务器上配置了proxy_cache_valid的时间,那么被代理服务器可以不指定缓存内容的时间。
下面的示例配置,代理缓存时间主要由两个参数来控制
proxy_cache_path指令后面的inactive 表示不活跃时间,在该时间内资源没有被访问就会被清理
proxy_cache_valid 指令后面的时间表示最长缓存时间,在满足上面inactive时间内保持访问,也最多到这个最长缓存时间有效
比如要缓存一周,可使用下面的配置:
http { |
API 接口
添加cache加速配置
PUT http://192.168.40.136:8081/cache
- 往特定server下添加特定的资源location,通过调用动态location 添加接口实现
比如往80端口,servername为www.a.com下添加一个/music.mp4 location
server { |
动态location api 添加location格式如下
{ |
cache api 收到该请求后,组装动态location api需要的格式如下:
{ |
- 启动一个访问该资源location的事件,在该事件中创建对该资源的http连接,维护读写时间,读取的数据丢弃即可
调用njt_event_connect_peer创建一个peer_connection, 如果是ssl,需要再调用njt_http_hc_ssl_init_connection
然后设置该connection的读写handler
peer_connection->write->handler= njt_http_cache_write_handler;
peer_connection->read->handler= njt_http_cache_read_handler;
write handler 组装http报文发送
read handler 接收数据并丢弃,同时维护数据下载的元数据
- 维护资源的下载情况
根据http response 的content_length作为资源总大小,试试读取返回的资源大小累计作为已下载大小
request:
{ |
参数 | 类型 | 必填 | 取值 | 说明 |
type | string | 是 | add |
|
location_name | string | 是 | location 名字 |
|
backend_server | string | 是 | http://{ip}:{port} 或者https://{ip}:{port}
| #代理的server类型与backend_server的类型一致 |
response:
Bash |
删除cache加速配置
根据输入的信息组装动态删除location结构,调用删除location api删除该资源
根据输入的信息从动态hash结构查找资源,将其删除
PUT http://192.168.40.136:8081/cache
删除cache配置如下,与动态删除location接口一致
{ |
参数 | 类型 | 必填 | 取值 | 说明 |
type | string | 是 | del |
|
location_name | string | 是 | location 名字 |
|
backend_server | string | 是 | http://{ip}:{port} 或者https://{ip}:{port} |
|
response:
{ |
查询特定cache下载进度
根据输入的信息从动态hash结构查找资源,根据目前已下载大小和总大小,计算出下载进度
PUT http://192.168.40.136:8081/cache
request:
{ |
参数 | 类型 | 必填 | 取值 | 说明 |
type | string | 是 | download_status |
|
location_name | string | 是 | location 名字 |
|
backend_server | string | 是 | http://{ip}:{port} 或者https://{ip}:{port} |
|
response:
{ |
查询所有cache配置
查询所有cache加速配置
GET http://192.168.40.136:8081/cache
response:
{ |
测试
配置示例
njet.conf
... |
njet_ctrl.conf
... |
HTTP cache测试
添加一项cache 配置
下载完成后,查询进度
通过curl访问,会显示命中缓存
删除该cache配置,查询不到该信息
Https cache测试
添加一项cache 配置
下载完成后,查询进度
通过curl访问,会显示命中缓存
curl https://192.168.40.136:443/music.mp4 -v -k
删除该cache配置,查询不到该信息
遗留问题&注意事项
- reload后或者njet停掉重新启动后,只会加载配置项,不会去重新下载,如果需要重新下载,可以先删除规则再重新添加规则可触发下载
- 缓存的有效期时间依赖于客户端的cache header等设置或者server端proxy_cache_valid 指令的影响
- 如果需要主动删除缓存,可以通过PURGE方法删除
- 对于失败的规则,查询会在status字段提示错误原因,比如配置项错误等或者内部错误,可根据提示选择删除该规则,并进行新规则添加
- 目前删除规则后并不会自动清理本地缓存的文件内容

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
OurBMC 首个版本1.0.0正式发布!
2023 年 12 月 29 日,经过社区开发者的共同努力,OurBMC 首个版本 1.0.0 正式发布。OurBMC 1.0.0 提供从 host 端到 BMC 端的全栈 BMC 技术实现,适配多种软硬件场景,并为开发者提供全面、高效的 BMC 全栈解决方案。 发布内容 OurBMC 1.0.0 发布内容包含了 bmc-uboot、bmc-linux、bmc-openbmc、bmc-web、host-UEFI 以及 host-linux 6 大模块。 bmc-uboot Bmc-uboot v1.0.0基于U-Boot v2019.04开发,在支持业界主流BMC芯片的基础上,使能飞腾腾珑E2000S BMC芯片,包括运行状态心跳灯、多级复位、pinctrl配置等功能。 bmc-linux Bmc-linux v1.0.0 基于openbmc Linux dev-5.15新增飞腾腾珑E2000S BMC功能支持,主要功能包括IPMI通信、虚拟串口、JPEG、USB vHub、JTAG。 bmc-openbmc Bmc-openbmc 基于 OpenBMC v2.11.0 完善 ARM ...
- 下一篇
白话文解析LiteFlow的理念是什么?什么时候用该怎么用?干货满满
官网:https://liteflow.cc/ Gitee:https://gitee.com/dromara/liteFlow Github:https://github.com/dromara/liteflow LiteFlow一个现代化的开源规则引擎框架,以下文中简称LF。 前言 时常在社区里看到有的小伙伴在那提问: LF在一个流程中如何暂停,等待操作员完成后,进行下一步该怎么做? LF流程失败后,下一次能否继续上次的执行? LF流程适不适合某个我的业务? LF流程如何定时执行我的某个流程? 还有的同学表示即便全部看完文档,也不知道LF该用在何种业务场景。能够带来什么好处。 究其原因是错误理解了流程的概念和不知道规则引擎的概念。 流程 我们先说流程。 LiteFlow定位是一个规则引擎,而不是流程引擎。它并不完成流程所要做的事,其实压根LF和流程一点关系也没有。 那什么是流程呢,标准的定义是,流程由流程定义,节点要做的事和角色组成。每一个角色做一件事,根据定义的流程定义串起来就叫流程。最典型的例子就是审批流:采购员提交了一张采购申请,部门领导审核,审核通过则到了财务这里,财务专员...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启