目录
🎫 前言
🎉 开篇福利
🎁 开篇福利 x2 Double happiness
# 介绍
# 地址
# 下载
💻 命令及解析
# 整个文件系统中搜索名为nginx.conf的文件
# 编辑nginx.conf文件
# 重新加载配置文件
# 快速查找nginx.conf文件并使用vim编辑器打开它
# 默认80端口代理配置
# 设置一个简单的代理服务器
# 反向代理
# 负载均衡
## RR策略
## 权重
## ip_hash
## fair(第三方)
## url_hash(第三方)
## rewrite
# 压缩和解压缩
🎫 前言
1. nginx官网地址：nginx news
2. 实践以下代码功能，需要服务器
方案a. 虚拟机 : 参阅 http://t.csdnimg.cn/Y7QYA
方案b. 云服务器：参阅 http://t.csdnimg.cn/iRkv3
3. 阿里云 云服务器 ECS 购买直达：云小站_专享特惠_云产品推荐-阿里云
🎉 开篇福利
vscode可安装 nginx-formatter 插件
创建一个 nginx.conf 文件
在linux系统中，使用FinalShell工具SSH链接服务器，查看 nginx.conf 文件内容
sudo cat /etc/nginx/nginx.conf
复制到本地 nginx.conf 文件中，对其代码右键，选择 使用...格式化文档
选择 nginx-formatter
这样看起来就舒服多了，也可以在本地编辑好之后写入到服务中。
🎁 开篇福利 x2 Double happiness
# 介绍
NGINX 配置配置高性能、安全、稳定的NGINX服务器的最简单方法。
# 地址
NGINXConfig | DigitalOcean
# 下载
下载 生成的配置: nginxconfig.io-example.com.tar.gz
然后 上传 到你的服务器的 /etc/nginx 目录.
或, 复制压缩配置的base64字符串，将其粘贴到服务器的命令行并执行。
a.进入你的 NGINX服务器上的配置目录:
cd /etc/nginxb.创建当前NGINX配置的备份:
tar -czvf nginx_$(date +'%F_%H-%M-%S').tar.gz nginx.conf sites-available/ sites-enabled/ nginxconfig.io/c.使用tar解压新的压缩配置
tar -xzvf nginxconfig.io-example.com.tar.gz | xargs chmod 0644💻 命令及解析
# 整个文件系统中搜索名为nginx.conf的文件
sudo find / -name "nginx.conf"# 编辑nginx.conf文件
vim /etc/nginx/nginx.conf# 重新加载配置文件
nginx -s reload
# windows
nginx.exe -s reload# 快速查找nginx.conf文件并使用vim编辑器打开它
find /etc/nginx -name "nginx.conf" -exec vim {} \;# 默认80端口代理配置
# 访问 https://www.example.com/,nginx指向服务端的/www/wwwroot目录，并寻找index.html文件。
# 访问 https://www.example.com/images/example.jpg,nginx指向服务端的/www/images目录，并寻找example.jpg文件。
http {
server {
location / {
root /www/wwwroot;
}
location /images/ {
root /www;
}
}
}
# 设置一个简单的代理服务器
# 新服务(服务处理)
server {
listen 8080;
root /www/wwwroot;
location / {
}
}
# 代理配置，数据转发
server {
location / {
proxy_pass http://localhost:8080;
}
location ~ \.(gif|jpg|png)$ {
root /www/images;
}
}# 反向代理
server {
listen 80;
server_name localhost;
client_max_body_size 1024M;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host:$server_port;
}
}
# 负载均衡
## RR策略
upstream vinca {
server localhost:8080;
server localhost:8081;
}
server {
listen 81;
server_name localhost;
client_max_body_size 1024M;
location / {
proxy_pass http://vinca;
proxy_set_header Host $host:$server_port;
}
}## 权重
upstream vinca {
server localhost:8080 weight=9;
server localhost:8081 weight=1;
}
- 在Nginx的upstream块中，weight参数用于指定服务器的权重。权重越高，服务器在负载均衡时被选中的概率就越大。
- 示例中，upstream块定义了名为"vinca"的后端服务器组，其中包含了2个服务器。第一个服务器的配置：server localhost:8000 weight=9;
- 这里的weight=9表示该服务器的权重是9。而另外一个服务器没有显式的指定权重，因此它们的默认权重为1。
- 在请求分发时，Nginx会根据服务器的权重比例来选择哪个服务器处理请求。由于第一个服务器的权重是9，而其他服务器的权重是默认的1，所以第一个服务器被选中的概率要高于另外一个服务器。
- 通过调整服务器的权重，可以在负载均衡时实现更为精细的控制，将请求按照一定比例分配给不同的服务器。
## ip_hash
upstream vinca {
ip_hash;
server localhost:8080;
server localhost:8081;
}
- 在上述示例中，ip_hash是Nginx的负载均衡算法之一。它的作用是基于客户端IP地址来实现会话粘性（Session Affinity），也称为IP哈希负载均衡。
- 当使用ip_hash时，Nginx通过计算客户端IP地址的哈希值，将每个请求分配给一台服务器。一旦确定了一个客户端请求应该被分派到的特定服务器，后续该客户端的所有请求都将被发送到同一台服务器上，从而实现会话的保持。
- 这在某些情况下非常有用，例如当你的应用程序需要确保用户的会话状态始终保持在同一台后端服务器上时。通过使用ip_hash，可以确保同一IP地址的客户端请求都被分发到相同的后端服务器，从而避免了会话状态的丢失。
- 需要注意的是，ip_hash算法可能会导致负载不均衡的问题，因为某些IP地址可能会产生更多的请求。如果你的后端服务器能够处理不同IP地址之间的请求不平衡，并且你需要确保会话粘性，那么ip_hash是一个可行的负载均衡选择。
## fair(第三方)
upstream backend {
fair;
server localhost:8080;
server localhost:8081;
}
- 在这段代码中，upstream块定义了一个名为"backend"的后端服务器组。同时使用了fair参数，这表明Nginx将使用fair模块来进行负载均衡。
- fair模块是Nginx的第三方扩展模块，它提供了一种称为"fair load balancing"的负载均衡算法。fair load balancing算法旨在更加公平地分配请求到后端服务器，而不是简单地根据权重或者轮询来进行分发。
- fair模块会考虑每个后端服务器的当前连接数和响应时间等因素，以便更合理地分配负载。具体来说，fair模块会根据服务器的响应时间和连接数动态地调整请求的分发，以确保每台服务器都能获得相对公平的负载。
- 通过使用fair，你可以让Nginx在进行负载均衡时更加智能地考虑每台服务器的负载情况，从而提高系统的性能和稳定性。
- 需要注意的是，fair模块并非Nginx自带的标准模块，它是一个可选的第三方模块，因此在使用前需要确保该模块已经被正确编译并加载到Nginx中。
## url_hash(第三方)
upstream backend {
hash $request_uri;
hash_method crc32;
server localhost:8080;
server localhost:8081;
}这段Nginx配置代码定义了一个名为"backend"的后端服务器组。它使用了hash指令来进行负载均衡，并指定了哈希算法和哈希键。
具体解释如下：
- hash $request_uri;：这行代码指定了使用$request_uri作为哈希键。每个请求的URI将被计算哈希值，以决定将请求发送到哪台后端服务器。
- hash_method crc32;：这行代码指定了使用CRC32算法作为哈希算法。CRC32是一种快速的哈希算法，用于计算请求URI的哈希值。
- server localhost:8080;和server localhost:8081;：这两行代码定义了两台后端服务器的地址和端口。
通过使用哈希负载均衡，可以根据请求的URI将请求分发到后端服务器。相同URI的请求将始终被分发到相同的后端服务器，这有助于在缓存中提高命中率，并实现会话粘性。
注意事项：
- 使用哈希负载均衡时，必须小心选择哈希键。选择不合适的哈希键可能导致负载不均衡，因为某些URI可能会更频繁地访问。
- 如果后端服务器的数量发生变化（增加或减少），哈希负载均衡可能会导致请求分布不均匀。在这种情况下，需要考虑重新平衡或调整哈希键的选择。
- 哈希负载均衡可能会导致请求集中于少数后端服务器，而其他服务器的负载较轻。这可能会对系统的性能和可扩展性产生影响，因此需要根据实际情况进行评估和调整。
- 请确保CRC32哈希算法已经编译到你的Nginx版本中，否则可能需要重新编译或选择其他可用的哈希算法。
总结：哈希负载均衡是一种根据请求URI进行分发的方法，可以在特定情况下提供更好的性能和会话粘性。但在使用时需谨慎选择哈希键，并根据实际情况进行评估和调整。
## rewrite
当需要为不同设备（如PC端和移动端）定制不同的页面重定向时，可以使用Nginx的rewrite模块来实现。以下是一个简单易懂的PC端和移动端重写方案：
server {
listen 80;
server_name example.com;
# PC端重定向规则
location / {
if ($http_user_agent ~* (android|iphone|ipad)) {
# 移动端访问，重定向到移动端页面
rewrite ^(.*)$ /mobile$1 last;
}
# PC端访问，保持原样
}
# 移动端重定向规则
location /mobile {
# 处理移动端页面请求
}
}
1. listen 80;：监听80端口，接收HTTP请求。
2. server_name example.com;：配置服务器名，替换成实际的域名。
3. PC端重定向规则：
- location /：匹配所有请求。
- if ($http_user_agent ~* (android|iphone|ipad))：使用$http_user_agent变量检查用户代理，判断是否为移动设备。
- rewrite ^(.*)$ /mobile$1 last;：如果是移动设备访问，则重写URL，在请求路径前加上"/mobile"，并使用last标志表示终止当前location的处理。
4.移动端重定向规则：
- location /mobile：匹配以/mobile开头的请求，用于处理移动端页面请求。
代码配置中，当用户通过移动设备访问网站时，Nginx会根据用户代理信息判断其为移动设备，然后重写URL以将请求路由到/mobile路径下，从而展示移动端页面。对于PC端访问，则保持原样，不做任何重定向处理。
需要注意的是，使用rewrite时要谨慎考虑正则表达式的匹配和重写规则，避免出现意外的行为。此外，对于移动端重定向，也可以使用Nginx的map模块结合变量来实现更灵活的设备识别和重定向规则。
# 压缩和解压缩
http {
gzip on; # 开启gzip压缩功能
gzip_min_length 1000; # 设置最小压缩文件大小
gzip_types text/plain text/css application/javascript; # 设置需要进行gzip压缩的文件类型
gzip_proxied any; # 启用所有可能的gzip压缩代理
server {
listen 80;
server_name example.com;
location / {
# 处理请求
}
location /compressed {
gunzip on; # 允许对请求进行解压缩
# 处理解压缩后的请求
}
}
}
- gzip on;：开启gzip压缩功能。启用后，Nginx会自动对符合条件的响应内容进行gzip压缩。
- gzip_min_length 1000;：设置最小压缩文件大小。仅当响应内容长度大于或等于1000字节时，才会进行压缩。
- gzip_types text/plain text/css application/javascript;：设置需要进行gzip压缩的文件类型。这里配置了常见的文本文件和JavaScript文件类型。
- gzip_proxied any;：启用所有可能的gzip压缩代理。这样可以确保在与反向代理或负载均衡等情况下仍能正确压缩响应内容。
- location /compressed：匹配以/compressed开头的请求路径。
- gunzip on;：允许对请求进行解压缩。在该location中，Nginx会自动解压请求内容。
在代码中，当收到客户端发起的请求时，Nginx会判断响应内容是否符合gzip压缩条件，并进行相应处理。如果响应内容长度达到设定的最小压缩文件大小，并且内容类型匹配gzip_types指定的文件类型，Nginx会对响应内容进行gzip压缩。对于带有/compressed路径的请求，Nginx会自动解压请求内容。
需要注意的是，gzip压缩会消耗一定的CPU资源，而解压缩也会增加服务器的负担。因此，在配置gzip时需要权衡压缩和解压缩的效益与资源消耗，并根据实际情况进行调整。
以上就是个人整理的nginx实战经验，欢迎评论留言。
