官网:Nginx官网. 建议下载最新版本。
下载后，目录结构如下：
在/conf/文件夹下，找到nginx.conf文件，复制一份重命名为nginx-xxx.conf。下面是一个nginx的常用配置
worker_processes 4;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream tbk_tomcats {
server 127.0.0.1:9001 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://tbk_tomcats;
}
}
server {
listen 8001;
server_name localhost;
location / {
root D://tbk//images;
}
}
server {
listen 9000;
server_name localhost;
location / {
proxy_pass http://tbk_tomcats;
}
}
}启动nginx, 新建一个startup.bat, 代码如：
nginx.exe -c conf/nginx-xxx.conf关闭nginx, 新建一个stop.bat, 代码如：
nginx.exe -s stop- Nginx解析图片静态资源实现动静分离
静态资源尽量不要走应用服务器，而直接走web服务器。ngnix可以直接指定目录，执行配置的域名可以跳转到指定目录下的静态资源文件。
静态资源如图片、css、js、html(静态资源处理时并发非常高).传统项目是把资源一起放到war中，而动静分离是把静态资源从war中剥离出来，单独放到一个目录中。这样当访问静态资源时，就有nginx直接重定向文件资源。当访问动态资源就由tomcat解析。nginx解析静态比tomcat快很多。
nginx默认配置
location / {
root html; #相对路径，配置了一个html目录，我们可以将网站所用到的所有的静态资源从war中移除，放到这个目录下。
index index.html index.htm; #配置的欢迎页面
} 进入conf文件夹，找到nginx.conf文件，为了保留原生配置文件， 我们可以选择拷 贝一份（拷贝的新文件名为:项目名.ngnix.conf），并在上面做我们的修改。下面是一个简单的代理静态资源的配置文件。如果这个时候要访问C://images-upload下的某个静态资源，如image.jpg. 只需要在浏览器中输入`http://image.项目名.com/image.jpg`即可。(如果没有把该域名绑定到DNS中，只是想本机测试模拟，可以配置本地的hosts文件，配置方式会在下面介绍。)
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
#要访问的域名
server_name image.项目名.com;
location / {
#root表示文件夹目录
#目录 C://images-upload//images//1.jpg
#访问 http://image.项目名.com//images//1.jpg
root C://images-upload;
}
}
}- 保证开发环境的请求和真实环境的请求地址一致
可以通过修改本地hosts文件来修改域名映射，模拟在本地访问指定域名。注意不要开代理或者翻墙软件，否则可能造成不能正确转向。
每次这样修改hosts文件比较麻烦， 这里推荐一款可视化工具:SwitchHosts
改完后，点击右下角的按钮即生效，非常方便。
- ngnix实现高负载均衡服务器
Nginx (“engine x”) 是一个高性能HTTP和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器
nginx的完整配置文件：
#worker_rlimit_nofile 一个nginx进程打开最多的文件数目，配置和Linux下文件打开个数一直。 ulimit -n来查看，最大可设置为65535
#对应系统哪个用户，最好专为nginx创建用户和组，并单独设置权限，这样安全。 如:user nginx
#events I/O模型， Linux下推荐使用epoll模型
#尽量打开GZIP压缩， gzip_comp_level通畅设置为3~5，太高会占用cpu
#user nobody;
#习惯配置成当前服务器的core数相同，或者2倍
worker_processes 1;
#日志，运行期间设置crit，可以减少I/O操作
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
#开启数为实际数量的1/4, 浏览器访问时会自动发起2个；反向代理tomcat又是两个。这个数值和操作系统能打开的文件数。理论上并发数=worker_processes * worker_connections.跟物理内存大小也有关系，因为系统打开的文件数和系统的内存成正比。一般1GB内存也可打开大约10w左右。
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
我们可以用使用bat或shell命令来操作nginx
启动 nginx.exe -c conf/项目名.nginx.conf
停止 nginx.exe -s stop
注意：windows下有时停止会无效，造成开启太多，这时候应该手动在进程管理器中找到nginx的进出并结束。
- Linux下部署Nginx
yum安装
yum install nginx #yum安装nginx,方便它的依赖包自动安装
where is nginx #查看安装后的各目录
启动停止和重启
nginx #直接执行，配置文件/etc/nginx/nginx.conf
nginx -s stop #停止
nginx -s reload #重启
测试
nginx -t #测试nginx是否正常
执行结果
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
查看进程
ps -ef|grep nginx
- 正向代理和反向代理
正向代理：
和日常我们上网不同，在公司我们上网时，不是所有电脑直接访问外网，而是访问一个代理服务器，由代理服务器再访问我们要访问的网站，代理服务器获得访问网站的返回信息后，再返回给我们。这种代理我们的电脑的方式叫做正向代理。
反向代理：
nginx和正向代理有所不同，它实现的也是代理，但是代理的后台服务器，我们访问nginx，而ngnix代理后的服务器，由它去决定具体访问哪台服务器。这种方式和正向代理刚好反过来，所以把这种方式称作反向代理。反向代理它屏蔽了后台具体的服务器，我们访问者根本不知道访问的哪台服务器，这样使访问更加安全。
- 请求转发
当使用下面配置时，用户访问http://localhost:80, nginx将这个请求什么也不做，只负责转发到tomcat的访问地址http://localhost:8080
server {
listen 80;
server_name localhost;
location / { #拦截所有的资源
proxy_pass http://127.0.0.1:8080; #转向tomcat的地址
}
}Nginx +Tomcat 实现Tomcat集群
将项目和Tomcat部署到多台主机中（或虚拟机中，如VMWare）
nginx提供了5种负载均衡策略轮询：默认配置。每个请求按时间顺序轮流分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
配置一个upstream, 声明一个名称 XX_tomcats, 配置多个ip地址转向，默认就是轮询。如：upstream状态参数
weight 默认为1. weight越大，负载的权重就越大
max_fails允许请求失败的次数默认为1，当超过最大次数时，返回proxy_next_upstream模块定义的错误
fail_timeout 超时时间
max_fails 多少次失败后，暂停的时间
backup 其他所有的非backup及其down或者忙的时候，请求backup及其。所以这台机器压力会最轻。
upstream XX_tomcats {
server 127.0.0.1:8080;
server 127.0.0.1:8090;
server 127.0.0.1:8100;
}
server {
listen 80;
server_name www.xx.com;
location / { #拦截所有资源
proxy_pass http://XX_tomcats #引用定义的upstream
}
}
轮询方式存在问题：服务器有性能比较好的，有性能比较差的。新的服务器的配置比旧的服务器强悍很多。cpu核也多，内存也大，硬盘容量也大，速度还快。如果还使用轮询的方式，就会造成新服务器资源的浪费，旧的服务器资源压力大。显然资源分配不合理，应该多劳多得。 2. 权重:指定轮训几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
在upstream中加入weight关键字就能够实现权重。
upstream XX_tomcats {
server 127.0.0.1:8080 weight=8; #访问请求分成9份，这个tomcat负责8份。
server 127.0.0.1:8090 weight=1; #访问请求分成9成，这个tomcat负责1份。
server 127.0.0.1:8100 down; #这个tomcat暂时不参加负载均衡
server 127.0.0.1:8110 backup; #其他非backup机器down或忙时，请求这个。
}
server {
listen 80;
server_name www.xx.com;
location / { #拦截所有资源
proxy_pass http://XX_tomcats #引用定义的upstream
}
} 3. IP_HASH : 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，针对解决session共享问题。
upstream XX_tomcats {
ip_hash; #ip_hash方式来实现session共享
server 127.0.0.1:8080 weight=8; #访问请求分成9份，这个tomcat负责8份。
server 127.0.0.1:8090 weight=1; #访问请求分成9成，这个tomcat负责1份。
server 127.0.0.1:8100 down; #这个tomcat暂时不参加负载均衡
}
server {
listen 80;
server_name www.xx.com;
location / { #拦截所有资源
proxy_pass http://XX_tomcats #引用定义的upstream
}
} 4. URL_HASH(第三方):访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，响应时间短的优先分配。针对解决session共享问题。
解决session共享问题：
访问一个网站时，有两类请求。一种请求叫做无状态的请求，一种请求叫做有状态。
无状态：例如登陆页面，类似这种页面，哪个tomcat给我们的响应都是一样的，不需要区分。这是我们最喜欢的。集群的动态伸缩性（增加节点、移除节点）
有状态，例如系统登陆后，加入用户请求被转发到tomcat1上，这时系统会写一个当前用户的信息放入session中。这种情况就称为有状态的，那么问题来了。nginx负载均衡后，下一次用户的请求就被转发tomcat2上。tomcat2上没有session。系统就会要求用户登陆，这显然是不合理的。这问题称作session共享问题。解决方案：
(1). session同步 ： Tomcat支持动态将某个tomcat下的session复制到其他的tomcat中。但是这个方式早期的企业级应用习惯的方式，现在很少使用。这种方式在集群数量很少时，结果还是可以的。但如果集群数量庞大。都需要复制session,这时会因为网络延迟，或者session的内容非常大。都会造成隐患，这时可能读到脏数据。
(2). Session黏着:对ip地址或者域名地址进行hash;或者uri进行hash. 缺点:用户浏览器的ip地址hash以后满足单调性。会可能造成资源的分配不均衡，负载均衡就达不到目的。有的服务器负载均衡过重，有的服务器负载过轻，显然没有充分利用资源。因为uri比ip地址相应数量多，变化就多，因此uri-hash比ip-hash分布更均衡些。uri-hash需要第三方软件支持
(3). 将信息放到cookie - 也就是放在客户端
session存在服务器端，会对服务器产生压力。如果将信息保存到cookie中，减轻了服务器的压力，同时每个客户端的压力也很小。因为只保存自己的信息。这种方式在实际的开发中广泛的采用。但是cookie可以被禁用，cookie要随着浏览器传递，增大了传输的内容，cookie大小也有限制。
(4).单点登录， 比较推荐的做法，将状态如session从系统中独立出来。Apache shiro顶级安全框架，它的session管理就是独立出来的。目前主流做法是利用redis作为session管理的实现，因为redis访问极其快速。
nginx支持故障自动切换。nginx转发请求道tomcat, 如果某个tomcat宕机，tomcat会进行超时判断，如果某个tomcat宕机，访问不了。它会自动的把这个请求转发给其他的tomcat.保证不会因为一个tomcat宕机导致业务无法继续访问。