不会这些东东,不敢说你会nginx?

一直以为自己很懂nginx,不就是配置一些负载一些路由嘛,直到这次需要自己进行调试部署时才发现依然存在好多概念不清的情况,比如location匹配的几种优先级,rewrite 阶段、access 阶段以及 content 阶段的运行顺序

因为工作需要,这里主要总结我们常用的server,location模块的一些信息

先来看一下nginx配置文件的大体分区

不会这些东东,不敢说你会nginx?不会这些东东,不敢说你会nginx?

mian全局块:

影响nginx全局的配置模块,一般有运行nginx服务器的用户组,nginx进程pid存放路径,日志存放路径,配置文件引入,允许生成worker process数等。

events模块:

 events{
  use epoll;
  worker_connections      65536;
}

use epoll;use是个事件模块指令,用来指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是标准的工作模式,kqueue和epoll是高效的工作模式,不同的是epoll用在Linux平台上,而kqueue用在BSD系统中。==对于Linux系统,epoll工作模式是首选。==在操作系统不支持这些高效模型时才使用select。

worker_connections 65536;每一个worker进程能并发处理(发起)的最大连接数(包含与客户端或后端被代理服务器间等所有连接数)。nginx作为反向代理服务器,计算公式 最大连接数 = worker_processes * worker_connections/4,所以这里客户端最大连接数是65536,这个可以增到到8192都没关系,看情况而定,但不能超过后面的worker_rlimit_nofile。当nginx作为http服务器时,计算公式里面是除以2。进程的最大连接数受Linux系统进程的最大打开文件数限制,在执行操作系统命令ulimit -n 65536后worker_connections的设置才能生效。
http块:可以嵌套多个server,配置代理,缓存,日志定义等绝大多数功能和第三方模块的配置。如文件引入,mime-type定义,日志自定义,是否使用sendfile传输文件,连接超时时间,单连接请求数等。

下面进入重点模块

server块

Server块: 一个server可以看作一个nginx的虚拟主机拷贝一份server段的文件如下

 upstream backend {
#    ip_hash;    #优先IP hash的规则
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}
server {
        listen       9033;             #虚拟机监听的端口
        server_name  localhost;  #匹配的域名
        root /data/htdocs/www;  #服务器默认的网站根目录位置(html文件存放目录)
        index index.html index.htm index.php;  #默认访问的html名称   一般在root定义的路径下存放
        location /ftpFile {   #匹配方式见下方
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
   #         alias   /home/migu_nginx/ftpdata;
        }
location /img/ {
    alias /var/www/image/;     #alias会直接覆盖上面的匹配内容/img,并替换成定义内容加上截取的后缀
}
location /img/ {
    root /var/www/image;   #root不会直接覆盖上面的匹配内容/img,并替换成定义内容加上截取的后缀
}

location匹配规则:

语法规则: location [=||*|^~] /uri/ {… }首先匹配 =,其次匹配^~,其次是按文件中顺序的正则匹配,最后是交给 /通用匹配。当有匹配成功时候,停止匹配,按当前匹配规则处理请求。
不会这些东东,不敢说你会nginx?不会这些东东,不敢说你会nginx?
值得注意的是,有一种暂不能理解的情况,但确实存在
不会这些东东,不敢说你会nginx?不会这些东东,不敢说你会nginx?

root和alias的区别

配置一:

location /img/ {
alias /var/www/image/;
}

#若按照上述配置的话,则访问/img/目录里面的文件时,ningx会自动去/var/www/image/目录找文件
配置二:

location /img/ {
root /var/www/image;
}

#若按照这种配置的话,则访问/img/目录下的文件时,nginx会去/var/www/image/img/目录下找文件。]比如访问链接为 /img/a/a.html则回去/var/www/image/img/a目录下找a.html

set指令
set $task_flag 0; 设置变量task_flag为0

反向代理 proxy_pass

如果一个请求过来了,比如 http:/127.0.0.1/mg/123/2.html,如果是下面这种配置,那最后的路由地址是http://apimigu/mg/123/2.html

location /mg{
proxy_pass http://apimigu;
}

若是下面带/的这种配置,那路由后得到的地址是http://apimigu/123/2.html

location /mg{
proxy_pass http://apimigu/;
}

所以结尾有没有/符号很重要
如果转发的和后台有多台服务器,我们可以定义一个upstream 负载均衡

 location /mg{ 
 proxy_pass         http://apimigu/;
 }
upstream apimigu{
#    ip_hash;    #优先IP hash的规则
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}
serve

rewrite语法

rewrite是实现URL重写重定向的重要指令,他根据regex(正则表达式)来匹配内容跳转到replacement,结尾是flag标记

配置语法:

 Syntax: rewrite regex replacement [flag];

rewrite的含义:该指令是实现URL重写的指令。
regex的含义:用于匹配URI的正则表达式。
replacement:将regex正则匹配到的内容替换成 replacement。
flag: flag标记。
举个小例子

 rewrite ^/(.*) http://www.baidu.com/ break;     # 匹配成功后跳转到百度

找了份正则表达式符号含义表,以供查询
不会这些东东,不敢说你会nginx?不会这些东东,不敢说你会nginx?
rewrite 的最后一项参数flag的作用,一般有四个
值得一提的是,正常情况下nginx会收集所有的rewrite结果集,这和之后要介绍的nginx的三个级别有关

不会这些东东,不敢说你会nginx?不会这些东东,不敢说你会nginx?
对于临时重定向和永久重定向的区别,这里着重说明以下
首先客户端浏览器的URL都会改变;

  1. 302重定向是暂时的重定向,搜索引擎会抓取新的内容而保留旧的地址。因为服务器返回302,所以搜索引擎会认为新的网址是暂时的;
  2. 301重定向是永久的重定向,搜索引擎会抓取新的内容的同时将旧的地址替换为重定向后的网址;

nginx中 $1,$2 的含义,有个博客讲的很简单易懂,这里直接拷贝

Nginx中,set $para $1,$1表示路径中正则表达式匹配的第一个参数。
以下是一个示例,用以实验$1,$2。

如:location ~/yxl/(.)/(.) {
set $para1 $1
set $para2 $2
content_by_lua_block {
ngx.say(ngx.var.para1)
ngx.say(ngx.var.para2)
}
}

此时,若访问路径为localhost:8080/yxl/qwe/asd时,则浏览器会输出

qwe
asd

nginx请求执行的几大阶段

详细分的话一共有11个阶段,这里着重介绍rewrite 、access 以及 content 三大阶段

不按代码顺序执行,是按阶段执行,顺序如下:
先执行命中的所有rewrite层指令(下面的set),
再执行access,再执行content(下面的echo)

举个例子语法:

 location  = / { 
       set $a 32;      
         echo $a;       
           set $a 64;   
           eho $a;
           }

因为是先收集结果,最后再content,所以最后两个打印都是64

本文地址:https://www.linuxprobe.com/hown-nginx-connect.html

代码下载地址: https://pan.quark.cn/s/a4b39357ea24 在计算机视觉技术中,数据集扮演着训练和评估模型的核心角色。Labelme作为一个广受欢迎的开源工具,能够支持用户以交互方式对图像进行标注,而COCO(Common Objects in Context)则是一种被广泛采纳的数据集标准格式,适用于包括物体检测、图像分割在内的多种任务。本文将详细阐述如何将Labelme生成的标注数据转换为COCO数据集的标准格式。 Labelme标注的图像在输出为JSON格式时,会包含以下核心内容: 1. `version`: 指明JSON文件的版本信息。 2. `flags`: 目前未定义或保持为空,预留用于未来的功能扩展。 3. `shapes`: 列表形式存储对象的形状信息,每个形状项包含`label`(对象类别名称),`points`(构成对象边缘的多边形顶点),以及`shape_type`(通常为“polygon”)。 4. `imagePath`和`imageData`: 提供原始图像的存储路径和二进制数据,便于后续图像的还原。 5. `imageHeight`和`imageWidth`: 明确标注图像的垂直和水平尺寸。 COCO数据集的标准格式中定义了三种主要的标注类型: 1. Object instances(目标实例):主要用于执行物体检测任务。 2. Object keypoints(目标上的关键点):适用于人体姿态估计相关应用。 3. Image captions(看图说话):用于生成图像的文本描述。 COCO的JSON结构中包含以下基本组成部分: 1. `images`:记录图像的基本属性,包括`height`(高度)、`...
内容概要:本文围绕基于Basisformer模型的时间序列锂离子电池SOC(State of Charge,荷电状态)预测展开研究,利用PyTorch深度学习框架构建并训练模型,旨在提升锂电池SOC估计的准确性与鲁棒性。该方法融合Transformer架构的核心机制,通过引入基函数(Basis)分解策略,有效捕捉电池充放电过程中长时序、非线性动态特征,增强模型对复杂工况的适应能力。研究仅详细阐述了Basisformer的网络结构设计、注意力机制优化与训练流程,还提供了完整的Python代码实现方案,涵盖数据预处理、模型搭建、损失函数定义、训练验证及结果可视化等环节,便于科研人员快速复现、调优并拓展至其他电池状态预测任务。; 适合人群:具备一定深度学习与Python编程基础,熟悉PyTorch框架,从事电池管理系统(BMS)、新能源汽车、储能系统、智能传感等领域的高校研究生、科研人员及工程技术人员。; 使用场景及目标:①应用于动力电池与储能系统的实时SOC估算模块,提升系统安全性与能量利用效率;②作为学术研究的基础模型,用于复现、改进基于Transformer的时间序列预测方法在电化学系统中的应用;③为数据驱动的电池健康状态(SOH)、剩余使用寿命(RUL)联合估计提供可扩展的技术框架。; 阅读建议:建议读者结合所提供的代码与公开电池数据集(如NASA、CALCE等)进行动手实践,深入理解模型的输入输出结构与时序建模逻辑,同时可尝试引入温度、老化周期等多维特征,或融合物理模型构建混合预测架构,以进一步提升预测精度与泛化能力。
内容概要:本文系统阐述了基于动态规划算法优化插电式混合动力电动汽车(PHEV)能源管理的技术方案,结合Matlab与Simulink工具实现完整的仿真建模与代码开发。通过动态规划这一全局优化方法,在已知驾驶循环条件下,精确求解发动机、电机及电池之间的最优能量分配策略,以实现燃油消耗与排放的最小化目标,解决PHEV多能源路径规划中的复杂决策问题。文中提供了详尽的仿真模型构建流程与算法实现步骤,涵盖车辆动力学建模、能量管理架构设计、状态空间定义、代价函数构造、最优控制律求解及结果可视化分析等关键环节,全面揭示PHEV能量管理系统的内在机制与优化逻辑。; 适合人群:具备一定Matlab/Simulink编程基础,从事新能源汽车、智能控制、电力电子、自动化或交通运输工程等相关领域的研究生、科研人员及工程技术人员,尤其适合专注于车辆能量管理策略、节能控制算法研究的专业人士。; 使用场景及目标:①深入掌握动态规划在混合动力汽车能量管理中的理论基础与工程实现方法;②学习如何在Matlab/Simulink环境中搭建PHEV整车仿真平台并实施多目标优化仿真;③为学术研究、学位论文撰写或实际工程项目提供可复用的算法框架、模型模板与技术支持,支撑后续对等效燃油消耗最小化策略(ECMS)、模型预测控制(MPC)、实时优化算法等的对比研究与性能评估。; 阅读建议:建议读者结合所提供的完整代码与Simulink模型文件,逐模块调试运行,重点理解状态变量离散化处理、前后向递推求解过程、惩罚项设置以及边界条件处理等核心技术细节,同时可进一步拓展应用于同工况场景、同车型结构或与其他优化算法(如庞特里亚金极小值原理PMP)的对比验证,从而深化对PHEV能量管理实时性与全局性平衡问题的理解。
内容概要:本文围绕基于多虚拟同步发电机(VSG)的独立微网系统,开展多目标二次控制策略的MATLAB/Simulink建模与仿真研究。通过构建包含多个VSG单元的独立微网系统,设计并实现了能够同时实现频率与电压的无静差恢复、有功/无功功率精确分配以及环流有效抑制的综合控制目标的二次控制方法。研究重点在于控制策略的整体架构设计、关键控制模块的数学建模及其在Simulink环境中的精细化实现,通过大量仿真实验验证了所提控制策略在同工况下的有效性、动态响应性能及系统鲁棒性。; 适合人群:具备电力系统分析、自动控制理论及现代电力电子技术等专业知识背景,熟悉MATLAB/Simulink仿真工具,从事新能源发电、微电网运行与控制、分布式能源系统集成等相关领域的科研人员、工程技术人员及高校研究生。; 使用场景及目标:① 深入掌握多VSG独立微网系统的建模方法与稳定性分析要点;② 理解并复现兼顾静态精度与动态品质的多目标二次协同控制算法;③ 为新型微网控制保护装置的研发及先进控制策略的工程化应用提供可靠的仿真验证平台和技术储备。; 阅读建议:学习者应在巩固电力系统基础理论的前提下,重点关注控制算法的设计逻辑、各控制环节间的耦合关系以及Simulink模块的搭建技巧,建议通过调整系统参数、设置同的负载投切与故障扰动工况进行反复仿真,以深刻理解控制策略的内在机理与适应能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值