nginx读取新配置文件(nginx配置访问本地文件)

nginx配置访问本地文件

1、首先在地址栏输入URL后，浏览器会搜索自身的DNS缓存，看自身的缓存中是否有www.xxx.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。

2、如果浏览器自身的缓存里面没有找到对应的条目，那么浏览器会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束。

3、如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件，看看这里面有没有该域名对应的IP地址，如果有则解析成功。

4、如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器发起域名解析请求，运营商的DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。

5、域名解析的整个过称就是寻址的过称，解析到对应的IP地址之后，就开始搜寻该物理机上的文件目录

2、URL默认的端口为80，服务器上会有软件程序监听着80端口，一般为tomcat或者nginx，现假设为nginx。

3、nginx收到请求后通过配置的域名路径去本地查找对应的文件根目录，然后在根据文件根目录去查询所设定的文件子目录，最终找到对应的文件。

nginx读取环境变量

Python Web 程序的部署方案

综合而言, 高性能的Python web站点部署方式首推 nginx + uwsgi

apache + mod_wsgi 是简单稳定但性能一般的方式

API服务器 可以直接使用tornado或者gevent

mod_python

非常原始的cgi模式部署python已经没有什么好介绍了。对于不太追求性能的管理系统和网站来说，使用 Apache 部署是一个不错的选择。较早的时候，使用 mode_python 部署python的web应用十分流行,在Django 0.96 的时候官方文档甚至推荐这种方式。

它将Python解释器嵌入到Apache server,以提供一个访问Apache server内部的接口。mod_python 在现在看来性能是不佳的，每一个http请求 mod_python 都会由一个进程初始化python解释器、载入代码、执行、然后销毁进程。

mod_wsgi

如果非要用Apache来部署python应用，mod_wsgi是一个更好的选择。WSGI 全称是 Web Server Gateway Interface ,由 PEP-333 定义。 基本上所有的python web框架都实现了wsgi接口，用mod_wsgi 能部署任何实现了wsgi的框架。实际上，不需要任何框架也可以用mod_wsgi 部署python程序。使用mod_wsgi的daemon模式，python程序会常驻内存，不会有很大的初始化和销毁进程方面的开销，所以性能是好于mod_python的。综合来说，使用Apache部署python web程序，推荐使用mod_wsgi的daemon模式。

Fastcgi

先说观点：不建议用fastcgi的方式部署Python web。

前几年由于lighttpd风头正劲和豆瓣的成功案例，fastcgi是一种很流行的部署方式。fastcgi与具体语言无关，也与web服务器无关。是一种通用的部署方式。fastcgi是对于cgi的增强，CGI程序运行在独立的进程中，并对每个Web请求建立一个进程。面对大量请求，进程的大量建立和消亡使操作系统性能大大下降。

与为每个请求创建一个新的进程不同，FastCGI使用持续的进程来处理一连串的请求。这些进程由FastCGI服务器管理，而不是web服务器。 当进来一个请求时，web服务器把环境变量和这个页面请求通过一个socket比如FastCGI进程与web服务器都位于本地）或者一个TCP connection（FastCGI进程在远端的server farm）传递给FastCGI进程。

主流的web服务器，Apache,lighttpd,nginx 都支持fastcgi，在几年前，lighttpd的mod_fcgi模块性能强劲，lighttpd+fastcgi十分流行。无论是python,ruby还是php，都有大量的站点使用这种方式部署。由于nginx的崛起，现在很少有人使用lighttpd了。

fastcgi 并不是专门为python设计，并不是所有的python框架天然的支持fastcgi，通常需要flup这样的容器来配适。flup由python编写，和专门的c实现的wsgi容器比起来性能显得相当不堪。fastcgi的稳定性对于新兴的wsgi容器来说也有差距。无论从哪个方面来看，部署python web程序，fastcgi 都已经是过去式。

uwsgi

前几年nginx还未内置uwsgi模块的时候，部署uwsgi还是一件挺麻烦的事情。随着能够在nginx中直接使用uwsgi模块，uwsgi已经是最可靠，最方便的高性能python web程序的部署方式了。

在1U的四核XEON服务器上，一个简单的wsgi handler甚至能用AB压到8000以上的qps,这已经是完爆tornado,接近gevent的性能了。 同时，uwsgi的稳定性极好。之前我们有个每天500w-1000w动态请求的站点使用uwsgi部署非常稳定，在一个渣HP 1U 服务器上，基本不用管它。

上面提到的部署方式都是相对于web网站的方式，在移动互联网的时代，我们需要的是高性能的API服务，上面这些都是过时的东西。

tornado

tornado 号称高性能，如果拿他写网站，其实一般般，只不过跟uwsgi加一些简单框架差不多而已。它真正的作用，是用来写API服务器和长连接的服务器。

由于tornado能够直接处理http请求，很多人直接拿他来裸奔直接提供服务。这种方式是不可取的，单线程的tornado只能利用cpu的一个核心，并且一旦阻塞直接就废了。通常情况下，由supervisor启动多个tornado进程，通过nginx进行反向代理负载均衡。nginx 1.14 以后的版本反向代理支持长连接，配合tornado的comet效果很好。

tornado还有一些比较奇葩的用法，比如用来做wsgi容器之类的。

gevent

gevent是一个神器，能做的事情很多。在web方面，处理http请求，用起来其实跟tornado差不多，但是要简陋很多，cookie之类的都没有。用gevent写的一些API服务，部署方式还是类似tornado，用supervisor管理多个守护进程，通过nginx做负载均衡。 同样的它的奇葩用法也和tornado一样，可以当wsgi容器用。

nginx获取参数

nginx配置好负载分担后，测试的时候，如何查看负载分担情况：通过设置nginx日志显示：nginx服务器日志相关指令主要有两条，一条是log_format，用来设置日志格式，另外一条是access_log，用来指定日志文件的存放路径、格式和缓存大小，一般在nginx的配置文件中日记配置(/usr/local/nginx/conf/nginx.conf)。nginx的log_format有很多可选的参数用于指示服务器的活动状态，默认的是：log_formataccess'$remote_addr-$remote_user[$time_local]"$request"''$status$body_bytes_sent"$http_referer"''"$http_user_agent""$http_x_forwarded_for"';

nginx 读取文件

Nginx在不依赖第三方模块的前期下，主要的功能有：

①、正向代理

正向代理，是在用户端的。比如需要访问某些国外网站，我们可能需要购买vpn。并且vpn是在我们的用户浏览器端设置的(并不是在远端的服务器设置)，浏览器先访问vpn地址，vpn地址转发请求，并最后将请求结果原路返回来。

②、反向代理

客户端向服务器发送请求时，会首先经过 Nginx 服务器，由服务器将请求分发到相应的 WEB 服务器。正向代理是代理客户端，而反向代理则是代理服务器，Nginx 在提供反向代理服务方面，通过使用正则表达式进行相关配置，采取不同的转发策略，配置相当灵活，而且在配置后端转发请求时，完全不用关心网络环境如何，可以指定任意的IP地址和端口号，或其他类型的连接、请求等。

③、负载均衡

当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况.

④、动静分离

在Web开发中，通常来说，动态资源其实就是指那些后台资源，而静态资源就是指HTML，JavaScript，CSS，img等文件。一般来说，都需要将动态资源和静态资源分开，将静态资源部署在Nginx上，当一个请求来的时候，如果是静态资源的请求，就直接到nginx配置的静态资源目录下面获取资源，如果是动态资源的请求，nginx利用反向代理的原理，把请求转发给后台应用去处理，从而实现动静分离。在使用前后端分离之后，可以很大程度的提升静态资源的访问速度，同时在开过程中也可以让前后端开发并行可以有效的提高开发时间，也可以有些的减少联调时间。

nginx 获取完整请求路径

不充足因为404错误表示请求的资源不存在，而nginx是一款高性能的WEB服务器，主要用于反向代理和负载均衡等，如果用户在部署nginx时没有正确配置相关的接口路径和服务器地址等参数，就会导致404错误的出现。需要检查nginx的配置文件是否正确，特别是server和location块的配置是否正确，还需要检查端口号和虚拟主机配置等方面，以确保nginx的正常运行，并解决404错误的问题。同时建议学习相关的nginx教程和手册，进一步提高自己的技术水平。