Nginx是俄罗斯人用c语言编写的十分轻量级的HTTP服务器,同时也能作为邮件服务器、反向代理服务器、静态资源服务器。
用户访问代理服务器。网站对用户不透明。对用户服务。
用户访问反向代理服务器。但是用户不知道访问的是反向代理服务器多个站点中的哪一个站点。对服务器服务。
nginx 的 upstream目前支持 4 种方式的分配 1)、轮询(默认):每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 2)、weight:指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 2)、ip_hash :每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 3)、fair(第三方):按后端服务器的响应时间来分配请求,响应时间短的优先分配。 4)、url_hash(第三方)
和node类似Nginx 采用了异步非阻塞的方式来处理请求。Nginx 采用的是多 worker 的方式来处理请求,每个 worker 里面只有一个主线程,每个worker线程都继承了高并发的特性。 想想 apache 的常用工作方式(apache 也有异步非阻塞版本,但因其与自带某些模块冲突,所以不常用),每个请求会独占一个工作线程,当并发数上到几千时,就同时有几千的线程在处理请求了。这对操作系统来说,是个不小的挑战,线程带来的内存占用非常大,线程的上下文切换带来的 cpu 开销很大,自然性能就上不去了,而这些开销完全是没有意义的。
osx 用homebrew
brew install nginx
命令 | 注释 | |
---|---|---|
nginx | 启动nginx,按照默认路径 | |
nginx -t | 测试配置正确性、也可查询默认配置路径 | |
nignx -c 路径 | 按照指定路径[启动 | ...] |
nginx -s reload | 平滑重启 | |
nginx -s stop | 停止nginx | |
nginx -v | 显示 nginx 的版本 | |
nginx -V | nginx 的版本,编译器版本和配置参数。 |
启动nginx后会根据配置生成一个master进程和多个worker进程(由参数worker_processes配置,一般为机器cpu核数)master 来管理 worker 进程,所以我们只需要与 master 进程通信就行了。master 进程会接收来自外界发来的信号,再根据信号做不同的事情。所以我们要控制 Nginx,只需要通过 kill 向 master 进程发送信号就行了,例如:
kill -HUP pid
//平滑重启nginx//pid是nginx的进程//若在nginx.conf配置了pid文件存放路径则该文件存放的就是Nginx主进程号//可用路径代替pid ,例如: '/usr/nginx/logs/nginx.pid'
master进程:
信号 | 注释 |
---|---|
TERM, INT | 快速关闭 |
QUIT | 从容关闭 |
HUP | 重载配置 \ 用新的配置开始新的工作进程 \ 从容关闭旧的工作进程 |
USR1 | 重新打开日志文件 |
USR2 | 平滑升级可执行程序。 |
WINCH | 从容关闭工作进程 |
worker进程:
信号 | 注释 |
---|---|
TERM, INT | 快速关闭 |
QUIT | 从容关闭 |
USR1 | 重新打开日志文件 |
#运行用户
user nobody;
#启动进程,通常设置成和cpu的数量相等
worker_processes 2;
#nginx pid进程号存储地址pid
logs/nginx.pid;
events {
#ulimit -n 一个进程所能够打开的文件的最大数
#反向代理,最大并发数
worker_connections * worker_processes/2
worker_connections 1024;
}
在http节点里添加: #定义负载均衡设备的 Ip及设备状态
upstream myServer {
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
ip_hash;
}
在需要使用负载的Server节点下添加
proxy_pass http://myServer;
upstream 每个设备的状态:
ip_hash 使用负载均衡服务器一多就会出现一个问题,那怎么实现多台服务器之间session的共享。其中一个方案就是ip_hash。nginx中的ip_hash能够将某个ip的请求定向到同一台后端,这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session;
Nginx 变量的创建和赋值操作发生在全然不同的时间阶段。Nginx 变量的创建只能发生在 Nginx 配置加载的时候,或者说 Nginx 启动的时候;而赋值操作则只会发生在请求实际处理的时候。这意味着不创建而直接使用变量会导致启动失败,同时也意味着我们无法在请求处理时动态地创建新的 Nginx 变量。
server {
listen 8080;
location /foo {
echo "foo = [$foo]";
}
location /bar {
set $foo 32;
echo "foo = [$foo]";
}
}
我们使用了标准 ngx_rewrite 模块的 set 配置指令对变量 $a 进行了赋值操作。特别地,我们把字符串 hello world 赋给了它。 这里我们使用第三方 ngx_echo 模块的 echo 配置指令将 $foo 变量的值作为当前请求的响应体输出。
我们用curl访问地址:
$ curl 'http://localhost:8080/foo'
//foo = []$ curl 'http://localhost:8080/bar'
//foo = [32]
例如由 ngx_http_core 模块提供的内建变量 $uri,可以用来获取当前请求的 URI(经过解码,并且不含请求参数),而 $request_uri 则用来获取请求最原始的 URI (未经解码,并且包含请求参数)。但是大部分内建变量类似保留值不可被赋值。
location /test {
echo "uri = $uri";
echo "request_uri = $request_uri";
echo "name: $arg_name";//name不区分大小写
}
$ curl "http://localhost:8080/test?Name=aaa"
:uri = /test
:request_uri = /test
:name: aaa
$ curl "http://localhost:8080/test?a=3&b=4":uri = /
test:request_uri = /test?a=3&b=4
:name:
也有一些内建变量是支持改写的,其中一个例子是 $args. 这个变量在读取时返回当前请求的 URL 参数串(即请求 URL 中问号后面的部分,如果有的话),而在赋值时可以直接修改参数串:
location /test {
set $orig_a $arg_a;
set $args "a=5";
echo "original a: $orig_a";
echo "a: $arg_a";
}
$ curl 'http://localhost:8080/test?a=3':original a: 3
:a: 5
原本$arg_a应该返回参数a=3,但是访问时赋值了$args 'a=5',所以取$arg_a时返回了5;
作者:gavinDu 链接:https://www.jianshu.com/p/c51cf712ab05 來源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。