Nginx

一、Nginx 是何方神圣？

想象一下，你的 Web 应用（比如一个用 Tomcat 跑的 Java 程序）就像一个日理万机的大厨。如果每个客人（用户请求）都直接冲进后厨点菜，大厨估计得原地爆炸。

这时候，Nginx 闪亮登场！它就像一个训练有素、帅到没朋友的餐厅经理。

它是什么？ Nginx (engine x)，一个用 C 语言写的、来自俄罗斯的高性能 Web 服务器。它的核心人设是：快！稳！省内存！
它能干嘛？
1. 反向代理 (Reverse Proxy)：它就是那个站在餐厅门口的经理。所有客人都先找他，他把菜单（请求）接过来，然后优雅地交给后厨的大厨（Tomcat），等菜做好了再端给客人。客人根本不用知道后厨在哪，也不用跟大厨直接打交道。
2. 负载均衡 (Load Balancing)：如果你的餐厅生意太好，一个大厨忙不过来怎么办？Nginx 经理可以管理一整个后厨团队（多台 Tomcat 服务器）。他会把客人平均分配给不同的厨师，确保谁也不闲着，谁也不累趴下。
3. 动静分离 (Separating Static and Dynamic Content)：客人点的菜分两种：现做的热菜（动态内容，由 Tomcat 处理）和冰箱里拿出来的可乐（静态内容，如图片、CSS、JS）。Nginx 经理非常聪明，他会直接把可乐（静态资源）递给客人，根本不去打扰正在炒菜的大厨，让大厨专心处理复杂的业务逻辑。

二、请神上身：Nginx 的安装与启动

想把这位经理请到你的服务器（Linux）上工作？简单，跟着步骤来，保证一次成功！

1. 安装步骤 (以 CentOS 为例)

这就像盖房子，得先准备好砖瓦水泥（依赖环境）。

第一步：准备"建筑材料"

在终端里执行下面这行"咒语"，安装 C 语言编译器和各种依赖库。
bash 复制代码
```
yum -y install gcc pcre pcre-devel zlib zlib-devel openssl openssl-devel
```
- gcc: C 语言编译器，没有它没法编译 Nginx。
- pcre, zlib, openssl: 分别是处理正则表达式、压缩和解压、以及 HTTPS 安全协议的库。
第二步：上传并"拆包"

把你下载好的 Nginx 压缩包（比如 nginx-1.10.0.tar.gz）上传到服务器的 /usr/upload 目录下，然后执行：
bash 复制代码
```
cd /usr/upload
tar -zxvf nginx-1.10.0.tar.gz
```
- tar -zxvf: 这是 Linux 下解压 .tar.gz 文件的万能钥匙。
第三步：指定"办公地点"

进入解压后的目录，告诉系统你想把 Nginx 安装到哪里。
bash 复制代码
```
cd /usr/upload/nginx-1.10.0
./configure --prefix=/usr/local/nginx
```
- --prefix=/usr/local/nginx: 这行命令的意思是："请把 Nginx 安装到 /usr/local/nginx 这个文件夹里"。
第四步：正式"施工"

最后两步，一键搞定！
bash 复制代码
```
make && make install
```
- make: 开始编译，把源代码变成可执行程序。
- make install: 编译完成后，安装到上一步指定的目录。

2. 目录结构：经理的办公室

安装完成后，去 /usr/local/nginx 看看，你会发现里面井井有条：

conf/: 配置文件 。这里是经理的"工作手册"，告诉他怎么接待客人、怎么分配任务。最重要的文件是 nginx.conf。
html/: 静态页面。默认的"样品间"，放一些静态的 HTML 文件。
logs/: 日志文件。经理的"工作日记"，记录了谁来过、点了什么、有没有出错。排查问题就靠它了！
sbin/: 可执行脚本。这里是经理的"总开关"，启动、关闭都在这儿。

3. 启动与关闭：经理的开关

进入 sbin 目录，就可以开始指挥这位经理了。

bash 复制代码

cd /usr/local/nginx/sbin

启动经理 : ./nginx
立刻关闭 : ./nginx -s stop (不管手上有没有活，马上走人)
优雅重启/重载配置 : ./nginx -s reload (这个最常用！修改了配置文件后，用这个命令让经理"热更新"，不中断正在服务的客人)

三、反向代理：让经理去传话

这是 Nginx 最核心的功能，配置起来非常简单。我们修改 conf/nginx.conf 文件，在 http 块里找到 server 块，或者直接新建一个。

nginx 复制代码

server {
    listen       80;               # 经理监听 80 端口，也就是 HTTP 的默认端口
    server_name  localhost;        # 监听的域名，这里写 localhost

    location / {                   # 匹配所有 URL 请求
        # 核心指令！把所有请求都转交给后厨的 Tomcat
        proxy_pass http://127.0.0.1:8080;
    }
}

解读： 当用户访问你的服务器 80 端口时，Nginx 会立刻把请求转发给运行在本机 8080 端口的 Tomcat。用户看到的是 Nginx，但实际干活的是 Tomcat。

四、负载均衡：让经理学会"端水"

现在后厨有多个大厨（多台 Tomcat），Nginx 经理需要学会公平分配工作。

1. 配置"后厨团队"

首先，在 http 块里定义一个"团队"，比如叫 myTomcats。

nginx 复制代码

# 定义一个名为 myTomcats 的上游服务器组
upstream myTomcats {
    server 127.0.0.1:8080; # 大厨 1 号
    server 127.0.0.1:8090; # 大厨 2 号
}

2. 经理开始派活

然后，在 server 块里，让经理把活派给这个团队。

nginx 复制代码

server {
    listen       80;
    server_name  localhost;

    location / {
        # 把请求转发给 myTomcats 团队，让他们自己内部去分配
        proxy_pass http://myTomcats;
    }
}

3. Nginx 经理的 6 种"端水"艺术 (负载均衡策略)

Nginx 默认是轮询，但你可以配置得更智能：

策略	描述	配置示例
轮询 (默认)	最公平，一人一个，挨着来。	`server 127.0.0.1:8080;`
weight (权重)	能者多劳。给 8080 端口的 Tomcat 分配 3 份活，8090 的分配 1 份。	server 127.0.0.1:8080 weight=3;``server 127.0.0.1:8090 weight=1;
ip_hash	认人。同一个客户端 IP 的请求，总是固定分配给同一个 Tomcat。解决 Session 丢失问题的神器！	ip_hash;``server 127.0.0.1:8080;
least_conn	能者多劳（动态版）。哪个 Tomcat 当前连接数最少，就把新请求给它。	least_conn;``server 127.0.0.1:8080;
url_hash	认事。对同一个 URL 的请求，总是分配给同一个 Tomcat，有利于缓存。	`hash $request_uri consistent;`
fair (第三方模块)	看速度。哪个 Tomcat 响应最快，就优先给谁。	需要安装第三方模块

4. 如何防止 Session 丢失？

当 Tomcat-1 挂了，下一个请求被分给 Tomcat-2，用户的登录状态（Session）就没了，这体验太糟糕了。怎么办？

ip_hash: 最简单粗暴。让同一个用户的请求永远只去同一个 Tomcat。缺点是如果那个 Tomcat 挂了，用户的 Session 还是没了。
Session 复制: 让所有 Tomcat 共享 Session。缺点是当 Tomcat 很多时，复制 Session 会非常消耗网络和内存资源。
Redis (推荐): 这是最佳实践！把 Session 统一存到一个叫 Redis 的中央数据库里。所有 Tomcat 都从 Redis 里读写 Session。这样无论请求被分到哪台 Tomcat，都能找到用户的登录状态。Redis 和 Session 都是 Key-Value 结构，简直是天生一对！

五、动静分离：让经理学会"抓重点"

这是性能优化的关键一步。把图片、CSS、JS 这些静态资源交给 Nginx 处理，它能比 Tomcat 快几十倍！

nginx 复制代码

server {
    listen       80;
    server_name  localhost;

    # 1. 处理所有请求
    location / {
        # proxy_pass http://myTomcats; # 动态请求，转发给 Tomcat 团队
        # 注意：动静分离时，这里通常只处理动态请求，静态请求由下面的 location 处理
    }

    # 2. 专门处理静态资源
    # 匹配所有以 .jpg, .png, .css, .js 结尾的请求
    location ~* \.(jpg|png|css|js)$ {
        root /usr/upload/pic; # 直接去服务器的这个目录下找文件
        # 例如：访问 http://yourdomain.com/images/logo.jpg
        # Nginx 会直接去 /usr/upload/pic/images/logo.jpg 找文件返回
    }
}

解读： 当用户请求一个 .jpg 图片时，Nginx 会直接去 /usr/upload/pic 目录下找到对应的文件并返回，完全不会打扰到后厨的 Tomcat。这样，Tomcat 就可以专心处理复杂的业务逻辑，整个系统的响应速度会得到质的飞跃！