目录
一、Nginx介绍
1、Nginx 相对于 Apache 优点:
2、Nginx效率高的原因:
3、nginx常用命令
二、nginx的代理
1、正向代理的概念:
2、反向代理的概念:
3、反向代理的实现:
三、nginx负载均衡策略
1. weight(权重)
2.ip_hash(访问ip)
3. fair(第三方)
4.url_hash(第三方)
四、其他了解的功能
1、站点访问
2、静态资源访问
3、跨域方案解决
首先Nginx是一个http服务器,中间件,那么已经有了tomcat、weblogic等服务器为什么还需要nginx呢
1) 高并发响应性能非常好,官方 Nginx 处理静态文件并发 5w/s
2) 反向代理性能非常强。(可用于负载均衡)
3) 内存和 cpu 占用率低。(为 Apache 的 1/5-1/10)
4) 对后端服务有健康检查功能。
5) 配置代码简洁且容易上手。
Tomcat最大并发量500,http默认端口号80
1>IO多路复用:一个线程得到IO请求就去处理,阻塞就抽出来去处理下一个IO请求,阻塞完毕继续回来处理。既减少了IO等待,也减少了频繁创建线程浪费的资源,这样的理论就叫IO多路复用,也就是多条IO操作都由一个线程来处理
2>轻量级,源代码只保留与http 及核心功能代码,出于性能考虑,不像httpd 有那么丰富的插件
3>cpu亲和,CPU核心和NGINX 工作进程绑定的方式,把每个worker进程固定在一个cpu上执行,减少切换cpu的cache miss,获得更好的性能。
4>内核空间零拷贝(nginx的sendfile),直接通过内核空间进行数据的拷贝,sendfile利用了linux在2.2 零拷贝传递模式
在sbin 目录下 通过./ 启动命令
./nginx -s stop # 快速关闭Nginx,可能不保存相关信息,并迅速终止web服务。
nginx -s quit #平稳关闭Nginx,保存相关信息,有安排的结束web服务。
./nginx -s reload #因改变了Nginx相关配置,需要重新加载配置而重载。
nginx -s reopen #重新打开日志文件。
nginx -c filename #为 Nginx 指定一个配置文件,来代替缺省的。
nginx -t #不运行,而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性,并尝试打开配置文件中所引用到的文件。
nginx -v #显示 nginx 的版本。
nginx -V #显示 nginx 的版本,编译器版本和配置参数。
正向代理 是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。
反向代理正好相反,对于客户端而言它就像是原始服务器,并且客户端不需要进行任何特别的设置。客户端向反向代理 的命名空间(name-space)中的内容发送普通请求,接着反向代理将判断向何处(原始服务器)转交请求,并将获得的内容返回给客户端,就像这些内容 原本就是它自己的一样。例用户访问 http://ooxx.me/readme,但ooxx.me上并不存在readme页面,他是偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户,但用户并不知情
nginx反向代理配置与执行流程详解
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况
如下所示,10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。
upstream linuxidc{
server 10.0.0.77 weight=5;
server 10.0.0.88 weight=10;
}
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
upstream favresin{
ip_hash;
server 10.0.0.10:8080;
server 10.0.0.11:8080;
}
按后端服务器的响应时间来分配请求,响应时间短的优先分配。与weight分配策略类似。
upstream favresin{
server 10.0.0.10:8080;
server 10.0.0.11:8080;
fair;
}
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
注意:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法。
upstream resinserver{
server 10.0.0.10:7777;
server 10.0.0.11:8888;
hash $request_uri;
hash_method crc32;
}
当一个网站功能越来越丰富时,往往需要将一些功能相对独立的模块剥离出来,独立维护。这样的话,通常,会有多个 webapp。
举个例子:假如 www.helloworld.com 站点有好几个webapp,finance(金融)、product(产品)、admin(用户中心)。访问这些应用的方式通过上下文(context)来进行区分:
www.helloworld.com/finance/
www.helloworld.com/product/
www.helloworld.com/admin/
我们知道,http的默认端口号是80,如果在一台服务器上同时启动这3个 webapp 应用,都用80端口,肯定是不成的。所以,这三个应用需要分别绑定不同的端口号。
那么,问题来了,用户在实际访问 www.helloworld.com 站点时,访问不同 webapp,总不会还带着对应的端口号去访问吧。所以,你再次需要用到反向代理来做处理。
http {
#此处省略一些基本配置
upstream product_server{
server www.helloworld.com:8081;
}
upstream admin_server{
server www.helloworld.com:8082;
}
upstream finance_server{
server www.helloworld.com:8083;
}
server {
#此处省略一些基本配置
#默认指向product的server
location / {
proxy_pass http://product_server;
}
location /product/{
proxy_pass http://product_server;
}
location /admin/ {
proxy_pass http://admin_server;
}
location /finance/ {
proxy_pass http://finance_server;
}
}
}
有时候,我们需要配置静态站点(即 html 文件和一堆静态资源)。
举例来说:如果所有的静态资源都放在了 /app/dist 目录下,我们只需要在 nginx.conf 中指定首页以及这个站点的 host 即可。
然后,添加 HOST:
127.0.0.1 static.zp.cn
此时,在本地浏览器访问 static.zp.cn ,就可以访问静态站点了。
web 领域开发中,经常采用前后端分离模式。这种模式下,前端和后端分别是独立的 web 应用程序,例如:后端是 Java 程序,前端是 React 或 Vue 应用。
各自独立的 web app 在互相访问时,势必存在跨域问题。解决跨域问题提供两种思路:
1.CORS
在后端服务器设置 HTTP 响应头,把你需要运行访问的域名加入 Access-Control-Allow-Origin 中。
2.jsonp
把后端根据请求,构造json数据,并返回,前端用 jsonp 跨域
Nginx跨域配置
3、nginx反向代理解决跨域问题
大家需要去看看:
https://www.cnblogs.com/renjing/p/6394725.html
九种跨域方案详解 (可重点参考)