nginx负载均衡

秋427

975人浏览 · 2025-11-03 15:28:31

秋427 · 2025-11-03 15:28:31 发布

文章目录

负载均衡是什么？
- 为什么要接入负载均衡？
- 选型ngx,haproxy,lvs
- 4层负载均衡，7层负载均衡
- - 4 层负载均衡（传输层，基于 TCP/UDP）
  - 7 层负载均衡（应用层，基于 HTTP/HTTPS 等）
- 反向代理-负载均衡
Nginx负载均衡
- 负载均衡模块
示例：简单测试nginx负载均衡
准备环境
- web01配置
- web02配置
- lb01配置
blog站点接入负载均衡
- 准备环境
- web01
- web02
- lb01
- nginx如何配置反向代理
lb+lnmp处理流程（⭐⭐⭐）
nginx常用模块（功能）
- nginx-rewrite模块（跳转/变量）
负载均衡轮询算法（⭐⭐⭐）
- 一致性哈希
cookie是什么？
session（会话）是什么？
cookie与session
- cookie示例
会话保持/共享方案
phpmyadmin是什么？
- 部署phpMyAdmin
web01和web02接入phpmyadmin，lb01设置负载均衡故障
- 如何解决？
- 设置一致性哈希或ip哈希
- 将登录信息存储到redis

负载均衡是什么？

负载均衡（Load Balancing）是一种分布式系统技术，核心作用是将来自客户端的大量请求（如网页访问、API 调用等）均匀地分配到多台后端服务器上，避免单台服务器因负载过高而崩溃，从而提高系统的整体性能、可用性和扩展性。

常用的负载均衡算法（分配请求的规则）

轮询（Round Robin）：依次将请求分配给每台服务器（默认策略，如你配置的lb_group默认行为）。
权重（Weight）：性能强的服务器分配更高权重（如server 10.0.0.7 weight=2，接收 2 倍请求）。
IP 哈希（IP Hash）：同一客户端 IP 始终转发到同一服务器（解决会话保持问题，如登录状态不丢失）。

为什么要接入负载均衡？

1.解决 “单服务器性能瓶颈”，提升系统处理能力

单台服务器的 CPU、内存、带宽等资源是有限的（比如单台服务器每秒最多处理 1000 个请求）。当用户量增长（如从 100 人到 10 万人），请求量超过服务器极限时，会出现：

响应速度暴跌（页面加载慢、API 超时）；
服务器过载崩溃（直接返回 503 错误）。

2.避免 “单点故障”，保障服务不中断

单服务器架构中，服务器一旦出现硬件故障（如硬盘损坏、电源故障）或软件崩溃（如进程挂掉），整个服务会直接中断，用户无法访问。这对业务（如电商、支付系统）是致命的。

负载均衡的作用：

持续监控后端服务器的健康状态（如通过定期发送 “心跳检测” 请求）；
一旦发现某台服务器故障，自动将请求转发到其他正常服务器，实现 “故障自动切换”；
业务层面无感知，用户几乎察觉不到服务器故障（比如你访问某网站时，后台某台服务器挂了，但你依然能正常浏览，就是负载均衡在起作用）。

3.简化 “系统扩容”，应对流量波动

业务增长过程中，流量会不断波动（如日常流量 1000QPS，促销活动时突然涨到 10000QPS）。此时需要快速增加服务器来分担压力，但单服务器架构扩容时：

需修改客户端配置（如改 IP 地址），成本高且易出错；
新增服务器无法快速加入 “工作队列”，响应滞后。

4.优化 “资源利用率”，降低成本

单服务器架构中，服务器资源（CPU、内存）可能 “忙闲不均”：

某台服务器因处理复杂请求（如大数据查询）负载过高；
另一台服务器因处理简单请求（如静态图片）长期闲置。

选型ngx,haproxy,lvs

对比维度	Nginx	HAProxy	LVS
工作层次	主要在7 层（应用层），支持部分 4 层能力	支持4 层（传输层）+7 层（应用层）	仅4 层（传输层）（内核级转发）
核心定位	高性能 Web 服务器 + 反向代理 + 负载均衡	专业负载均衡软件（侧重高并发与精细化控制）	高性能 4 层流量分发（侧重极致性能与大并发）
支持协议	HTTP、HTTPS、TCP（Stream 模块）	TCP、UDP（4 层）；HTTP、HTTPS（7 层）	TCP、UDP
性能表现	万级并发（依赖硬件，一般场景足够）	十万级并发（7 层性能优于 Nginx）	百万级并发（内核级转发，性能天花板）
配置复杂度	中等（配置灵活，Web 场景易上手）	中等（7 层规则精细，需理解协议逻辑）	高（需内核参数调优，依赖 keepalived 实现高可用）
功能扩展	静态资源缓存、SSL 卸载、Rewrite 规则、WAF（第三方模块）	7 层健康检查、会话保持、HTTP 重写、ACL 访问控制	仅流量分发，无应用层功能（需结合其他工具）
典型适用场景	中小规模 Web 服务、静态资源加速、API 网关	高并发 Web 服务、7 层精细化路由（如按 URL/Header 分发）、金融级高可用场景	大规模 TCP/UDP 流量（如游戏、视频流、数据库代理）、需要极致性能的 4 层负载

4层负载均衡，7层负载均衡

4 层负载均衡（传输层，基于 TCP/UDP）

架构流程：

客户端访问 3306 端口（MySQL 默认端口），流量经 “读取负载均衡” 设备后，分发到多台数据库服务器（均开放 3306 端口），实现数据库读取请求的负载分担。
核心特点：

工作在 OSI 第 4 层（传输层），基于

IP + 端口

转发流量，不解析应用层协议（如 MySQL 协议的具体内容）。
典型工具 / 场景：

工具如 LVS、HAProxy（4 层模式）；场景适合数据库读写分离、游戏服务器等

TCP/UDP 类服务

的流量分发。

7 层负载均衡（应用层，基于 HTTP/HTTPS 等）

架构流程：

客户端通过域名http://blog.oldboy.cn

访问 80/443 端口（HTTP/HTTPS 默认端口），流量经负载均衡设备后，分发到多台运行 Nginx 的 Web 服务器，实现 Web 请求的负载分担。
核心特点：

工作在 OSI 第 7 层（应用层），基于

应用协议内容

（如 HTTP 的 URL、Cookie）分发流量，可实现 SSL 卸载、静态资源缓存、URL 路由等精细化控制。
典型工具 / 场景：

工具如 Nginx、HAProxy（7 层模式）；场景适合 Web 站点、API 服务等

HTTP/HTTPS 类应用

的流量分发与业务逻辑控制。

对比维度	4 层负载均衡（传输层）	7 层负载均衡（应用层）
工作层次	OSI 第 4 层（传输层），基于 TCP/UDP 协议的IP + 端口转发	OSI 第 7 层（应用层），基于应用协议内容（如 HTTP URL、Cookie）分发
协议支持	TCP、UDP 等传输层协议	HTTP、HTTPS、DNS、FTP 等应用层协议
核心功能	流量转发、端口映射、基本健康检查	内容路由（如按 URL 路径、域名分发）、SSL 卸载、请求压缩、会话保持、WAF（Web 应用防火墙）
性能表现	性能高（仅处理传输层数据，开销小）	性能稍低（需解析应用层数据，开销大）
配置复杂度	简单（只需配置 IP 和端口）	复杂（需理解应用协议逻辑，如 HTTP 头、请求体）
典型设备 / 软件	F5 BIG-IP、Nginx Stream 模块、HAProxy（四层模式）	Nginx HTTP 模块、HAProxy（七层模式）、AWS ALB、Cloudflare
适用场景	对性能要求高的场景（如游戏、视频流、TCP 服务）；需转发非 HTTP 流量时	Web 应用（如电商、门户）；需基于内容分发、SSL 卸载、精细化控制时

反向代理-负载均衡

反向代理（基于 Nginx/HAProxy）

流程说明：
1. 客户端（10.0.0.1）发起请求 oldboylinux.cn/oldboy.jpg。
2. 反向代理服务器（如10.0.0.5，由 Nginx/HAProxy 实现）接收请求，再转发给后端 Web 服务器（10.0.0.7）。
3. Web 服务器处理请求后，将资源 oldboy.jpg 返回给反向代理。
4. 反向代理将结果返回给客户端，同时客户端通过 DNS 解析到反向代理的域名。
核心特点：

工作在应用层（7 层），可实现静态资源缓存、SSL 卸载、URL 路由、请求过滤等精细化应用层控制，同时隐藏后端 Web 服务器架构，是 Web 服务的 “统一入口”。

二、负载均衡（基于 LVS）

流程说明：
1. 客户端（10.0.0.1）发起请求 oldboylinux.cn/oldboy.jpg。
2. 负载均衡设备（LVS）将请求基于 IP + 端口分发到后端 Web 服务器集群（多台 web 节点）。
3. 某台 Web 服务器处理请求后，直接返回资源 oldboy.jpg 给客户端（或经负载均衡转发，取决于具体模式）。
核心特点：

工作在传输层（4 层），仅负责流量分发，性能极高（支持百万级并发），适合大规模 TCP/UDP 流量场景（如游戏、数据库代理），但无应用层功能，需结合反向代理等工具实现 7 层逻辑。

反向代理

反向代理是一种服务器架构模式：客户端不直接访问后端服务器，而是向 “反向代理服务器” 发起请求，由反向代理服务器转发请求到后端的一个或多个服务器，再将响应返回给客户端。

负载均衡

负载均衡是一种流量分发技术：将客户端请求（或网络流量）均匀分配到多个后端服务器，避免单台服务器过载，提升系统的可用性、性能和扩展性。

反向代理与负载均衡的关系

反向代理可以实现负载均衡，但负载均衡不局限于反向代理：

维度	反向代理	负载均衡
核心目标	隐藏后端、集中化处理应用层逻辑	流量分发、提升系统可用性 / 性能
实现层次	多在应用层（7 层）（如 HTTP 代理）	可在*传输层（4 层）或*应用层（7 层）
典型关联场景	Nginx 作为反向代理，同时通过`upstream`配置负载均衡规则
独立存在性	可单独使用（如仅做 SSL 卸载、缓存）	需结合后端服务器集群使用

举例理解

假设你有 3 台 Web 服务器（web1、web2、web3）：

反向代理场景：用 Nginx 作为反向代理，仅转发请求到web1（此时不涉及负载均衡，仅做代理）。
负载均衡场景（通过反向代理实现）：用 Nginx 配置upstream，将请求轮询分发到web1、web2、web3，此时 Nginx 既是反向代理，也是负载均衡器。

简言之，反向代理是 “代理模式”，负载均衡是 “流量分发技术”；两者常结合使用，反向代理服务器可作为负载均衡器的载体，实现更灵活的流量管理与应用层控制。

Nginx负载均衡

Nginx 是目前最流行的软件负载均衡器之一，凭借轻量、高性能、配置灵活的特点，被广泛用于 HTTP 层（7 层）和 TCP 层（4 层）的负载均衡场景。以下从核心配置、负载策略、健康检查、高级功能等方面，详细解析 Nginx 负载均衡的实现原理和实践方法。

一、核心组件：upstream 模块

Nginx 负载均衡的核心是 upstream 模块，用于定义后端服务器集群（服务器组），并通过 proxy_pass（HTTP 代理）或 fastcgi_pass 等指令将请求转发到该集群。

基本结构

# 定义后端服务器集群（名称自定义，如 web_cluster）
upstream web_cluster {
    server 10.0.0.7:80;  # 后端服务器1
    server 10.0.0.8:80;  # 后端服务器2
    # 可添加更多服务器...
}

# 虚拟主机配置：接收客户端请求并转发到集群
server {
    listen 80;
    server_name example.com;  # 客户端访问的域名

    location / {
        proxy_pass http://web_cluster;  # 转发到 upstream 定义的集群
        # 必须添加的头信息传递（确保后端获取客户端真实信息）
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

upstream web_cluster：定义一个名为 web_cluster 的服务器组，包含后端服务器的 IP: 端口。
proxy_pass http://web_cluster：将 location / 匹配的所有请求，转发到 web_cluster 集群中的服务器

负载均衡策略（请求分配规则）

Nginx 内置多种负载策略，默认使用轮询，可根据业务需求手动指定。

轮询（Round Robin）—— 默认策略

原理：按顺序依次将请求分配给后端服务器（1→2→1→2…）。

适用场景：所有后端服务器性能相近、无状态服务（如静态资源、API 接口）。

upstream web_cluster {
    server 10.0.0.7:80;  # 第1个请求分配给7
    server 10.0.0.8:80;  # 第2个请求分配给8
}

权重（Weight）—— 按性能分配

原理：为服务器设置权重（weight），权重越高，接收的请求越多（权重默认值为 1）。

适用场景：后端服务器性能差异较大（如高配服务器承担更多请求）。

upstream web_cluster {
    server 10.0.0.7:80 weight=3;  # 承担3/4的请求（3:(3+1)）
    server 10.0.0.8:80 weight=1;  # 承担1/4的请求
}

IP 哈希（IP Hash）—— 会话保持

原理：根据客户端 IP 地址的哈希值分配服务器，同一 IP 始终转发到同一台服务器。

适用场景：有状态服务（如登录会话、购物车数据），避免因服务器切换导致的状态丢失（如重复登录）。

upstream web_cluster {
    ip_hash;  # 开启IP哈希策略
    server 10.0.0.7:80;
    server 10.0.0.8:80;
}

注意：若后端服务器下线，需手动标记为 down（否则哈希映射会错乱）：

upstream web_cluster {
    ip_hash;
    server 10.0.0.7:80 down;  # 临时下线，不参与分配
    server 10.0.0.8:80;
}

负载均衡模块

指令	说明
`weight`	用于设置后端服务器的请求分配权重。权重越高，分配到的请求比例越大。例如`server 10.0.0.1 weight=3; server 10.0.0.2 weight=1;`，则每 4 个请求中，10.0.0.1 会处理 3 个，10.0.0.2 处理 1 个。适合后端服务器性能有差异的场景（性能好的节点权重设高）。
`max_fails`	定义 Nginx 判定 “后端节点不可用” 的失败请求次数。默认是 1 次，即节点 1 次请求失败就会被判定为不可用。实际中可设置为 3 次左右，避免因网络抖动（临时波动）导致的误判。
`fail_timeout`	配合`max_fails`使用，指 “节点被判定为不可用后，多久再次尝试连接它”。默认 10 秒，即节点失败后，10 秒内不会向它发请求，10 秒后会再次测试该节点是否恢复。
`backup`	标记该节点为备用节点。只有当所有非备用节点都故障时，才会将请求转发到这个备用节点，用于容灾兜底（比如把性能稍弱的节点作为备用，平时不参与负载，紧急时启用）。

在分布式系统中，雪崩（通常指 “缓存雪崩”） 是指因缓存层故障或大量缓存失效，导致海量请求瞬间冲击后端数据库（或核心服务），引发数据库过载宕机，进而导致整个系统连锁崩溃的现象。它是分布式架构中最常见的 “致命问题” 之一，需要重点防范。

当缓存雪崩发生时，大量请求会跳过缓存，直接冲击数据库：

大量用户请求 → 缓存失效/不可用 → 全部请求打向数据库 → 数据库崩溃 → 系统整体不可用

示例：简单测试nginx负载均衡

准备环境

节点	ip
lb01 nginx	10.0.0.5/172.16.1.5
web01 nginx	10.0.0.7/172.16.1.7
web02 nginx	10.0.0.8/172.16.1.8

前提：三台服务器都需要有nginx

nginx -v
#需要版本相同
nginx version: nginx/1.26.1

cat /etc/yum.repos.d/ngx.repo 
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

yum install -y nginx

web01配置

[root@web01 ~]# cat /etc/nginx/conf.d/lb.songhong.com.conf 
server{
  listen 80;
  server_name lb.songhong.com;
  #error_log
  #access_log
  root /app/code/lb/;
  location / {
   index index.html;
  }
}
[root@web01 ~]# cat /app/code/lb/index.html 
web01 11111
chown -R nginx:nginx /app/code/lb/
systemctl reload nginx

web02配置

[root@web02 ~]# cat /etc/nginx/conf.d/lb.songhong.com.conf 
server{
  listen 80;
  server_name lb.songhong.com;
  #error_log
  #access_log
  root /app/code/lb/;
  location / {
   index index.html;
  }
}
echo 'web02 22222' >/app/code/lb/index.html
[root@web02 ~]# cat /app/code/lb/index.html 
web02 22222
chown -R nginx:nginx /app/code/lb/
systemctl reload nginx

lb01配置

[root@lb01 ~]# cat /etc/nginx/conf.d/lb.songhong.com.conf 
--------------------------------
upstream  lb_group {
  server 10.0.0.7:80;
  server 10.0.0.8:80;
}
server {
  listen 80;
  server_name lb.songhong.com;
  error_log /var/log/nginx/lb-error.log notice;
  access_log /var/log/nginx/lb-access.log main;
  location / {
    #传球  转发
    proxy_pass  http://lb_group;
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-Ip  $remote_addr;
  }
}
--------------------------------
systemctl reload nginx
#也可以通过curl命令直观查看负载均衡效果
[root@lb01 ~]# curl -H Host:lb.songhong.com http://10.0.0.5
web01 11111
[root@lb01 ~]# curl -H Host:lb.songhong.com http://10.0.0.5
web02 22222

windows hosts解析

10.0.0.5 lb.songhong.com

浏览器访问lb.songhong.com，刷新

抓包查看,过滤http

角色说明

10.0.0.1：客户端（用户），发起 HTTP 请求。
10.0.0.5：Nginx 反向代理 / 负载均衡服务器，接收客户端请求并转发到后端集群。
10.0.0.7、10.0.0.8：后端 Web 服务器集群，实际处理业务请求并返回响应。

步骤	发送方	接收方	操作	结果 / 说明
1	客户端（10.0.0.1）	反向代理（10.0.0.5）	发起请求（GET /）	代理接收客户端访问请求
2	反向代理（10.0.0.5）	后端服务器（10.0.0.7）	转发请求（轮询第一次）	后端处理后返回 200 响应，代理将响应回传给客户端
3	客户端（10.0.0.1）	反向代理（10.0.0.5）	再次发起请求（GET /）	代理接收客户端第二次请求
4	反向代理（10.0.0.5）	后端服务器（10.0.0.8）	转发请求（轮询第二次）	后端处理后返回 200 响应，代理将响应回传给客户端

blog站点接入负载均衡

准备环境

节点	ip
lb01	10.0.0.5/172.16.1.5
web01	10.0.0.7/172.16.1.7
web02	10.0.0.8/172.16.1.8
db01	10.0.0.51/172.16.1.51
nfs01	10.0.0.31/172.16.1.31

前提准备

lb01 nginx

web01 nginx+php

web02 nginx+php

db01 mariadb

nfs01 nfs

web01

[root@web01 ~]# nginx -v
nginx version: nginx/1.26.1
[root@web01 ~]# php-fpm -v
PHP 8.0.30 (fpm-fcgi) (built: Aug 29 2025 09:33:23)
[root@web01 ~]# cat /etc/nginx/conf.d/blog.songhong.com.conf 
server{
  listen 80;
  server_name blog.songhong.com;
  root /app/code/blog/;
  error_log /var/log/nginx/blog-error.log notice;
  access_log /var/log/nginx/blog-access.log main;

  location / {
  index index.php;
  }

  location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include fastcgi_params;
  }
}

[root@web01 ~]# ls /app/code/blog/
index.php             wp-config.php         wp-login.php
license.txt           wp-config-sample.php  wp-mail.php
readme.html           wp-content            wp-settings.php
wp-activate.php       wp-cron.php           wp-signup.php
wp-admin              wp-includes           wp-trackback.php
wp-blog-header.php    wp-links-opml.php     xmlrpc.php
wp-comments-post.php  wp-load.php

web02

[root@web02 ~]# nginx -v
nginx version: nginx/1.26.1
[root@web02 ~]# php-fpm -v
PHP 8.0.30 (fpm-fcgi) (built: Aug 29 2025 09:33:23)
[root@web02 ~]# cat /etc/nginx/conf.d/blog.songhong.com.conf 
server{
  listen 80;
  server_name blog.songhong.com;
  root /app/code/blog/;
  error_log /var/log/nginx/blog-error.log notice;
  access_log /var/log/nginx/blog-access.log main;

  location / {
  index index.php;
  }

  location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include fastcgi_params;
  }
}
[root@web02 ~]# ls /app/code/blog/
index.php             wp-config.php         wp-login.php
license.txt           wp-config-sample.php  wp-mail.php
readme.html           wp-content            wp-settings.php
wp-activate.php       wp-cron.php           wp-signup.php
wp-admin              wp-includes           wp-trackback.php
wp-blog-header.php    wp-links-opml.php     xmlrpc.php
wp-comments-post.php  wp-load.php

lb01

[root@lb01 ~]# nginx -v
nginx version: nginx/1.26.1

[root@lb01 ~]# cat /etc/nginx/conf.d/blog.songhong.com.conf 
upstream  blog_group {
  server 10.0.0.7:80;
  server 10.0.0.8:80;
}
server {
  listen 80;
  server_name blog.songhong.com;
  error_log /var/log/nginx/blog-error.log notice;
  access_log /var/log/nginx/blog-access.log main;
  location / {
    #传球  转发
    proxy_pass  http://blog_group;
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-Ip  $remote_addr;
  }
}

最终效果

抓包查看

客户端会从10.0.0.1到10.0.0.5负载均衡，在轮询到10.0.0.7或者10.0.0.8

nginx如何配置反向代理

lb+lnmp处理流程（⭐⭐⭐）

一、处理静态资源流程

静态资源（如图片、CSS、纯 HTML 文件）由 Nginx 直接处理并返回，流程如下：

用户→负载均衡（lb）
- DNS 解析：将域名解析到 lb 的 IP 地址。
- TCP 三次握手：用户与 lb 的 80 端口建立可靠连接。
- 发送 HTTP 请求：以 GET 方法发送请求，包含 URI、Host 头（域名信息）、用户代理（UA）等。
- Nginx 匹配：lb 的 Nginx 在http{}块中通过server_name匹配请求的 Host 信息，匹配成功则处理对应站点，失败则走默认规则或按配置顺序处理。
- 转发请求：通过location /的proxy_pass指令，将请求转发到后端分组或具体 IP；转发时携带Host头（记录域名）、XFF头和XRI头（记录客户端 IP）。
lb→Web 服务器
- TCP 三次握手：lb 与 Web 服务器的 80 端口建立连接。
- 发送 HTTP 请求：携带 Host、UA、XFF、XRI 等信息。
- Nginx 匹配：Web 服务器的 Nginx 再次通过server_name匹配请求，成功后直接从静态站点目录 + URI中读取资源并返回。
响应返回

资源从 Web→lb→用户，用户最终拿到 HTTP 响应，完成静态资源的访问。

二、处理动态资源流程

动态资源（如 PHP 文件）需由 PHP-FPM 解析执行，流程与静态资源的差异主要在 Web 服务器的处理环节：

用户→lb & lb→Web 服务器

这两个环节的流程与 “处理静态资源” 完全一致（DNS 解析、三次握手、HTTP 请求发送、Nginx 的server_name匹配、proxy_pass转发及头信息携带）。
Web 服务器→PHP-FPM（动态处理核心）
- 转发请求：Web 服务器的 Nginx 将请求转发到9000 端口（PHP-FPM 默认监听端口），并携带 PHP 页面的绝对路径（站点目录 + URI）。
- PHP 解析：PHP-FPM 解析并运行对应的 PHP 文件，处理业务逻辑（如数据库交互、业务计算等）。
- 结果返回：PHP 将处理结果返回给 Nginx。
响应返回

处理结果从 Nginx→lb→用户，用户拿到最终的 HTTP 响应（如动态生成的页面内容）。

nginx常用模块（功能）

nginx查找已安装的模块

nginx -V |& grep 模块名

模块名称	功能说明	常用指令 / 关键配置
core 核心模块	Nginx 配置的 “骨架”，所有基础指令都属于该模块	`listen`（监听端口）、`location`（请求路径匹配）、`root`（静态资源根目录）、`server_name`（域名匹配）等
access 模块	基于 IP 的访问控制	`allow`（允许访问）、`deny`（拒绝访问），例如限制特定 IP 网段访问后台接口
log 模块	管理访问日志，记录请求明细	`access_log`（指定日志文件）、`log_format`（定义日志格式），用于排查问题、统计访问量
proxy 模块	反向代理 / 请求转发核心模块	`proxy_pass`（转发请求到后端服务）、`proxy_set_header`（修改请求头）；优化指令`proxy_buffer`（缓冲区）、`proxy_cache`（代理缓存）
upstream 模块	配合 proxy 实现负载均衡，定义后端服务器组	`upstream`（创建服务器组）、`server`（添加后端节点），支持轮询、加权、ip_hash 等负载策略
auth_basic_module	基于 HTTP 的基本认证模块，保护敏感资源	`auth_basic`（开启认证）、`auth_basic_user_file`（指定用户名密码文件），常用于后台管理页认证
autoindex 模块	目录索引功能，自动列出目录下文件	`autoindex`（开启目录索引），适合自建文件共享站、Yum 仓库等场景，让用户浏览下载文件
fastcgi_module	Nginx 与 PHP 交互的桥梁（LNMP 架构核心）	`fastcgi_pass`（指定 PHP-FPM 地址，如`127.0.0.1:9000`）、`fastcgi_param`（设置 PHP 环境变量，如脚本路径）
geoip_module	基于 IP 的地理位置识别模块	根据客户端 IP 判断归属地，用于地域访问限制（如屏蔽境外 IP）、用户地域统计等
gzip_module	资源压缩模块，减少带宽消耗，提升页面加载速度	`gzip`（开启压缩），对 HTML、CSS、JS 等资源进行压缩，降低传输体积
limit_conn/limit_req 模块	限流模块：限制并发连接数（limit_conn）、限制请求频率（limit_req）	防止流量攻击或后端过载，例如限制某 IP “每秒最多 10 个请求”“同时最多 5 个连接”
stub_status_module	Nginx 状态监控模块	`stub_status`（开启状态页），可查看连接数、请求数等运行指标，用于性能监控
ssl_module	HTTPS 支持模块，实现 SSL/TLS 加密通信	配置 SSL 证书、协议版本、加密套件等，是部署 HTTPS 网站的必备模块
rewrite_module	URL 重写与跳转模块，实现 301/302 跳转、URL 美化等	`return`（直接跳转）、`rewrite`（规则匹配跳转）、`if`/`set`（条件判断与变量设置），例如旧域名跳转到新域名
http_v2_module	HTTP/2.0 协议支持模块（需先配置 HTTPS）	支持多路复用、头部压缩等新特性，提升高并发场景下的性能
ngx_stream_xxx 模块	4 层协议（TCP/UDP）处理模块，用于底层协议的转发或负载均衡	可对数据库、非 HTTP 服务的端口流量进行负载分发，拓展了 Nginx 在 “非 Web 场景” 的能力

nginx-rewrite模块（跳转/变量）

指令	说明	应用场景
`rewrite`	基于正则实现 URL 跳转，规则灵活	对 URL 进行 “加工处理”，如路径替换、带参数的 URL 重写等（例如将`/old`重写为`/new?id=1`）。
`return`	基于变量实现简单跳转，支持 HTTP 状态码	301/302 重定向、HTTP/HTTPS 强制跳转、新旧域名切换（例如将`http://old.com`跳转为`https://new.com`）。
`if`	基于 Nginx 变量做单分支条件判断	简单逻辑判断（如根据请求头、客户端 IP 做分流）；复杂逻辑建议交给 Lua 模块（如 OpenResty）。
`set`	创建或修改变量	定义自定义变量，用于后续逻辑复用（例如记录请求标记、处理中间结果）。

网站只支持GET/POST/HEAD请求方法，其他方法都拒绝405

[root@web01 ~]# cat /etc/nginx/conf.d/90.songhong.com.conf 
server{
   listen 80;
   server_name 90.songhong.com;
   root /app/code/90/;
   #除了GET|POST,其他返回405
   if ( $request_method !~ "GET|POST"  ) {
   return 405;
   }
   location / {
   index index.html;
   
   }

}

[root@web01 ~]# curl -I -v  -H Host:90.songhong.com http://10.0.0.7

-I HEAD方法

*   Trying 10.0.0.7:80...
* Connected to 10.0.0.7 (10.0.0.7) port 80 (#0)
> HEAD / HTTP/1.1
> Host:90.songhong.com
> User-Agent: curl/7.71.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Not Allowed
HTTP/1.1 405 Not Allowed

网站维护中显示503

[root@web01 ~]# cat /etc/nginx/conf.d/90.songhong.com.conf 
server{
   listen 80;
   server_name 90.songhong.com;
   root /app/code/90/;
   #创建变量file,指定文件路径
   set $file "/etc/nginx/lidao.txt";
   #检查是否有这个文件，有这个文件就返回503
   if ( -f $file  ){
   return 503;
   }
   if ( $request_method !~ "GET|POST"  ) {
   return 405;
   }
   location / {
   index index.html;
   
   }

}
touch /etc/nginx/lidao.txt
systemctl reload nginx

浏览器访问90.songhong.com

负载均衡轮询算法（⭐⭐⭐）

算法类别	算法名称	原理	适用场景	优缺点
静态算法	轮询（Round Robin）	按顺序依次将请求分配给后端服务器，循环往复。	后端服务器性能一致、无状态服务（如静态资源服务）。	实现简单，但无法应对服务器性能差异（若某服务器性能差，会成为瓶颈）。
静态算法	加权轮询（Weighted Round Robin）	为不同服务器分配权重（性能越好权重越高），按权重比例分配请求。	后端服务器性能存在差异（如高配服务器权重高，处理更多请求）。	兼顾了性能差异，但仍属于静态分配，无法实时感知服务器负载变化。
静态算法	源 IP 哈希（IP Hash）	根据客户端源 IP 的哈希值分配请求，确保同一 IP 的请求始终落到同一台服务器。	需要会话保持的场景（如电商购物车、用户登录态）。	保证了会话一致性，但无法均衡 “不同 IP 的请求量差异”（若某 IP 请求极多，对应服务器压力大）。
动态算法	最少连接（Least Connections） nginx原生不支持响应时间算法	选择当前活跃连接数最少的服务器分配请求。	长连接场景（如数据库连接、WebSocket），或后端服务器处理请求耗时差异大的场景。	能动态适应服务器负载，但依赖连接数统计，对短连接场景（如 HTTP 请求）效果有限。
动态算法	响应时间（Response Time）	选择平均响应时间最短的服务器分配请求（需实时监控服务器响应时间）。	对响应速度敏感的服务（如 API 接口、Web 应用）。	能精准匹配 “响应快的服务器”，但需要额外的监控模块支持，复杂度较高。
哈希类算法	URL 哈希（URL Hash）	根据请求的 URL 哈希值分配请求，确保同一 URL 的请求落到同一服务器。	缓存场景（如 CDN、静态资源缓存），或需要 “同一资源请求命中同一服务器缓存” 的场景。	保证了缓存命中率，但服务器增减时会导致大量缓存失效。
哈希类算法	一致性哈希（Consistent Hashing）	将服务器和请求都映射到一个哈希环上，请求按顺时针方向找最近的服务器。服务器增减时，仅影响哈希环上的一小段范围。	分布式缓存（如 Redis Cluster）、有状态服务的分片（如用户数据分片存储）。	服务器扩缩容时影响范围小，适合大规模分布式场景；但实现较复杂，需维护哈希环。

基本结构

# 定义后端服务器集群（名称自定义，如 web_cluster）
upstream web_cluster {
    server 10.0.0.7:80;  # 后端服务器1
    server 10.0.0.8:80;  # 后端服务器2
    # 可添加更多服务器...
}

# 虚拟主机配置：接收客户端请求并转发到集群
server {
    listen 80;
    server_name example.com;  # 客户端访问的域名

    location / {
        proxy_pass http://web_cluster;  # 转发到 upstream 定义的集群
        # 必须添加的头信息传递（确保后端获取客户端真实信息）
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

静态算法

轮询（默认策略，无需额外配置）
原理：按顺序依次将请求分配给后端服务器，循环往复。

# 定义后端服务器组（默认轮询）
upstream  lb_group {
  server 10.0.0.7:80; #web01
  server 10.0.0.8:80; #web02
}

效果：请求会按顺序依次分配给 10.0.0.7→10.0.0.8→10.0.0.7→10.0.0.8... 循环。

加权轮询（指定权重）
原理：为不同服务器分配权重（性能越好权重越高），按权重比例分配请求。

注意：配置高的服务器分配权重越多

upstream  lb_group { 
  server 10.0.0.7:80 weight=2;  # 权重2（处理2份请求）
  server 10.0.0.8:80 weight=1;  # 权重1（处理1份请求）
}

效果：每 3个请求中，10.0.0.7 处理 2 个，10.0.0.8 处理 1 个,按权重分配请求

源ip哈希（会话保持）
原理：根据客户端源 IP 的哈希值分配请求，确保同一 IP 的请求始终落到同一台服务器。

upstream  lb_group {
  ip_hash;  # 启用源IP哈希算法
  server 10.0.0.7:80 weight=1;
  server 10.0.0.8:80 weight=1;
}

效果：同一客户端 IP 的请求会固定分配到同一台服务器（如用户 A 的所有请求始终到 10.0.0.8），确保会话数据不丢失。

动态算法

最少连接（Least Connections）
原理：选择当前活跃连接数最少的服务器分配请求。

upstream  lb_group {
  least_conn; # 启用最少连接算法
  server 10.0.0.7:80 weight=1;
  server 10.0.0.8:80 weight=1;
}

效果：每次请求会分配给当前活跃连接数最少的服务器（如 10.0.0.12 当前连接数最少，则优先分配给它）。

响应时间（nginx原生默认没有）

原理：选择平均响应时间最短的服务器分配请求（需实时监控服务器响应时间）。

upstream  lb_group {
  least_time; # 启用最少连接算法
  server 10.0.0.7:80 weight=1;
  server 10.0.0.8:80 weight=1;
}

哈希类算法

URL哈希

原理：根据请求的URL 哈希值分配请求，确保同一 URL 的请求落到同一服务器。

upstream  lb_group {
  hash $request_uri; # 按请求URL的哈希值分配
  server 10.0.0.7:80 weight=1;
  server 10.0.0.8:80 weight=1;
}

效果：http://example.com/image.jpg 的所有请求会固定分配到同一服务器（如 10.0.0.11），利用服务器本地缓存提升响应速度。

一致性哈希

原理：将服务器和请求都映射到一个哈希环上，请求按顺时针方向找最近的服务器。服务器增减时，仅影响哈希环上的一小段范围。
适用场景：分布式缓存（如 Redis Cluster）、有状态服务的分片（如用户数据分片存储）。

upstream  lb_group {
  hash $remote_addr consistent;
  server 10.0.0.7:80 weight=1;
  server 10.0.0.8:80 weight=1;
}

.一致性哈希环：基础数据分配（4 个节点，4 条数据）

核心逻辑：将整个哈希空间（如 0~2³²-1）想象成一个环形结构，每个节点（node1、node2等）和数据（绿色点）通过哈希计算映射到环上。数据会顺时针找到最近的节点，并由该节点承载。
作用：展示了一致性哈希的 “数据 - 节点” 映射关系，4 条数据分别被 4 个节点均匀承载，实现初始的负载均衡。

新增节点：只影响相邻数据

特性：当新增一个节点（橙色node）时，只有其相邻的一小部分数据会从原节点迁移到新节点，其他节点的数据完全不受影响。
价值：节点扩容时，数据迁移量极小，避免了传统哈希 “节点增减导致全量数据迁移” 的问题，保障了系统的稳定性。

删除节点：只影响相邻数据

特性：当删除一个节点（红色虚线node3）时，其承载的数据会迁移到顺时针相邻的节点，其他节点的数据保持不变。
价值：节点缩容时，数据迁移同样是局部的，不会引发大规模服务波动。

节点少导致的负载不均

问题：当物理节点数量较少时，哈希环上的节点分布会很 “稀疏”，导致数据（绿色点）集中映射到少数节点上，引发负载不均衡（部分节点压力过大，部分节点闲置）。

虚拟节点：解决负载不均

优化方案：为每个物理节点创建多个 “虚拟节点”（如node1-1、node1-2），并将虚拟节点分散到哈希环上。数据会先映射到虚拟节点，再关联到物理节点。
价值：通过虚拟节点的 “分散布局”，让数据在物理节点上的分布更均匀，彻底解决了 “节点少导致的负载不均” 问题。

cookie是什么？

Cookie 是浏览器或设备本地存储的小型文本数据块，主要用于在客户端（用户设备）和服务器之间传递、记录用户状态（如登录信息、偏好设置），让 Web 服务能 “记住” 用户。

Cookie 的核心属性

存储位置：保存在用户的浏览器 / 设备本地（如电脑的浏览器缓存目录、手机的应用存储区），而非服务器。
数据大小：单个 Cookie 通常限制在 4KB 以内，且浏览器对单个域名的 Cookie 数量有上限（一般 20~50 条）。
创建方：主要由服务器生成（通过 HTTP 响应头 Set-Cookie 发送给客户端），客户端（如前端 JS）也可通过代码创建 / 修改（但受安全限制）。
生命周期：
- 会话 Cookie（默认）：浏览器关闭后自动删除，仅在当前会话有效（如临时登录态）。
- 持久 Cookie：通过 Expires 或 Max-Age 设置过期时间（如 7 天），到期前会一直保存在本地（如 “记住登录 7 天”）。

session（会话）是什么？

Session（会话）—— 它是服务器端用于存储用户会话信息的机制，核心作用是在多次请求中 “记住” 用户状态（如登录信息、操作记录），是 Web 开发中跟踪用户行为的重要工具。

Session 的核心特性

存储位置：

保存在服务器端（如内存、数据库、Redis 缓存等），用户无法直接访问，安全性远高于 Cookie。
数据形态：

通常以 “键值对” 形式存储（如 user_id: 123、cart: [商品A, 商品B]），容量几乎不受限（仅受服务器资源限制）。
生命周期：
- 默认是 “会话级”：用户关闭浏览器后，Session 不会立即删除，但服务器会设置超时时间（如 30 分钟无操作则自动销毁）。
- 可手动控制：服务器可主动删除 Session（如用户退出登录时）。

cookie与session

Cookie 和 Session 是 Web 开发中用于跟踪用户状态的两种核心机制，二者在存储位置、安全性、生命周期等方面存在显著差异，以下是详细对比：

定义与工作原理

维度	Cookie	Session
存储位置	客户端（浏览器本地文件）	服务器端（内存、数据库或缓存）
工作流程	服务器生成 Cookie → 响应头传给浏览器 → 浏览器下次请求时自动携带 Cookie → 服务器读取识别用户	服务器生成 Session ID → 以 Cookie 或 URL 重写的方式传给客户端 → 客户端每次请求携带 Session ID → 服务器通过 ID 找到对应会话

核心区别

安全性

Cookie：存储在客户端，易被用户查看、篡改甚至伪造，不适合存储敏感信息（如密码、用户余额）。
Session：存储在服务器端，用户无法直接访问，安全性更高，适合存储敏感的会话数据（如登录态、购物车）。

生命周期

Cookie：可通过Expires或Max-Age设置过期时间，支持长期有效（如 “记住登录状态” 可维持 7 天）。
Session：默认依赖会话（浏览器关闭则失效），也可手动设置超时时间（如 30 分钟无操作则过期），属于临时存储。

存储容量与数量

Cookie：单条 Cookie 大小通常限制在 4KB 以内，且浏览器对单个域名的 Cookie 数量有上限（如 20~50 条）。
Session：存储容量取决于服务器资源（内存、数据库性能），理论上无严格大小限制，但过多会消耗服务器资源。

依赖性

Cookie：Session 的实现通常依赖 Cookie 传递Session ID（若用户禁用 Cookie，需通过 URL 重写传递 ID，体验较差）。
Session：本身不依赖 Cookie，但 Web 场景下多通过 Cookie 关联用户。

三、协作与应用场景

协作关系：服务器生成 Session 后，会将Session ID写入 Cookie（键通常为PHPSESSID、JSESSIONID等），客户端后续请求时携带该 Cookie，服务器通过 ID 找到对应 Session。
Cookie 适用场景：
- 存储非敏感的持久化数据（如用户偏好、主题设置）。
- 实现 “记住我” 功能（长期有效）。
- 跟踪用户行为（如广告投放统计）。
Session 适用场景：
- 存储敏感的临时会话数据（如登录态、订单流程）。
- 需服务器端验证的业务（如权限控制）。

cookie示例

在wordpress后台页面按F12,进入调试页面，在应用中找到cookie

http://blog.songhong.com/wp-admin/

这个就是cookie缓存的用户的登录信息

删除登录信息之后，刷新页面

会话保持/共享方案

方案	说明 & 应用场景
直接使用 cookie	把会话信息（如登录态、用户配置）直接存储在客户端 Cookie中，服务器不维护会话状态。典型案例：WordPress 通过加密 Cookie 存储用户登录信息，多服务器场景下只要客户端携带 Cookie，就能保持会话一致。
ip_hash 或一致性 hash	通过负载均衡算法（IP 哈希 / 一致性哈希），让同一用户的请求固定落到某一台后端服务器，该服务器本地维护会话。适用场景：有状态服务（如传统单体应用的负载均衡），确保用户后续请求都能命中存储会话的服务器。
使用会话保持服务	将会话信息集中存储到 Redis 等中间件，所有后端服务器都从 Redis 读取 / 写入会话数据。适用场景：分布式多服务器架构（如微服务），实现会话全局共享，避免单服务器存储的局限性。
使用 Oauth 认证	不存储传统会话，而是通过生成令牌（如 access_token）实现授权。客户端携带令牌请求资源，服务器验证令牌有效性即可。适用场景：第三方授权（如微信登录、API 接口服务），无需维护会话状态，更适合跨系统、跨平台的授权场景。

phpmyadmin是什么？

phpMyAdmin 是一款开源的 Web 端 MySQL/MariaDB 数据库管理工具，通过浏览器即可可视化操作数据库（无需命令行），广泛用于数据库的日常管理（如创建表、执行 SQL、备份数据等），尤其适合不熟悉 MySQL 命令行的用户。

一、核心功能

数据库 / 表的基础操作
- 可视化创建、删除、重命名数据库或数据表；
- 管理表结构（添加 / 修改 / 删除字段、设置主键 / 索引 / 外键等）；
- 对表数据进行增删改查（支持批量操作、筛选、排序）。
SQL 语句相关
- 提供 SQL 编辑器，支持直接输入并执行 SQL 语句（如查询、插入、更新、删除等）；
- 自动生成常用 SQL（如创建表的语句可通过界面配置后直接导出）；
- 显示 SQL 执行结果、错误信息，支持事务回滚（部分场景）。
用户与权限管理
- 管理 MySQL 用户（创建、删除用户，修改密码）；
- 分配用户权限（如对某数据库的查询、修改、管理权限等）。
数据导入与导出
- 支持导入 SQL 脚本、CSV、Excel 等格式文件到数据库；
- 导出数据库 / 表为 SQL、CSV、JSON、Excel 等格式（用于备份或迁移）。
其他实用功能
- 查看数据库状态（如连接数、缓存使用情况）；
- 优化表、修复表（解决数据碎片或损坏问题）；
- 支持多语言（包括中文），界面友好。

部署phpMyAdmin

前提需要部署nginx

上传服务器文件

通过网盘分享的文件：phpMyAdmin-5.2.3-all-languages.zip
链接: https://pan.baidu.com/s/1MlXNSWjRyhr0CefOT8bzXg?pwd=5tyz 提取码: 5tyz
–来自百度网盘超级会员v2的分享

wget https://files.phpmyadmin.net/phpMyAdmin/5.2.3/phpMyAdmin-5.2.3-all-languages.zip



#配置nginx站点文件
[root@web01 ~]# cat /etc/nginx/conf.d/db.songhong.com.conf 
server{
  listen 80;
  server_name db.songhong.com;
  root /app/code/db/;
  error_log /var/log/nginx/db-error.log notice;
  access_log /var/log/nginx/db-access.log main;

  location / {
  index index.php;
  }

  location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include fastcgi_params;
  }
}

[root@web01 ~]# ls phpMyAdmin-5.2.3-all-languages.zip 
phpMyAdmin-5.2.3-all-languages.zip

mkdir -p /app/code/db
unzip phpMyAdmin-5.2.3-all-languages.zip
mv phpMyAdmin-5.2.3-all-languages/* /app/code/db

[root@web01 ~]# cd /app/code/db/
[root@web01 /app/code/db]# cp config.sample.inc.php config.inc.php 

[root@web01 /app/code/db]# vim config.inc.php
#将这个本地ip修改为数据库的内网ip
$cfg['Servers'][$i]['host'] = 'localhost';
#改为数据库db01节点的内网ip
$cfg['Servers'][$i]['host'] = '172.16.1.51';
[root@web01 /app/code/db]# grep -n  host config.inc.php 
30:$cfg['Servers'][$i]['host'] = '172.16.1.51';
39:// $cfg['Servers'][$i]['controlhost'] = '';

nginx -t
systemctl reload nginx

windows hosts解析

10.0.0.7 db.songhong.com

浏览器访问db.songhong.com,会发现报错

#需要修改/var/lib/php/session的权限所有者
[root@web02 ~]# ll -d /var/lib/php/session/
drwxrwx--- 2 root apache 6  8月 29 17:40 /var/lib/php/session/

chown -R nginx:nginx /var/lib/php/session/

刷新页面

需要在数据库节点db01添加一位用户

[root@db01 ~]# mysql -uroot -p123
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 15
Server version: 10.3.39-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> grant all on *.* to 'admin'@'172.16.1.%' identified by '123';
Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.000 sec)

#授予所有权限

输入新创建的用户和密码，admin:123

web01和web02接入phpmyadmin，lb01设置负载均衡故障

前提条件

web01 部署nginx+php,phpmyadmin
web02 部署nginx+php,phpmyadmin
db01 部署mariadb数据库
lb01 部署nginx负载均衡

lb01节点设置负载均衡

[root@lb01 ~]# cat /etc/nginx/conf.d/db.songhong.com.conf 
upstream  db_group {
  server 10.0.0.7:80;
  server 10.0.0.8:80;
}
server {
  listen 80;
  server_name db.songhong.com;
  error_log /var/log/nginx/db-error.log notice;
  access_log /var/log/nginx/db-access.log main;
  location / {
    #传球  转发
    proxy_pass  http://db_group;
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-Ip  $remote_addr;
  }
}

windows,hosts文件解析,使用负载均衡服务器的ip
10.0.0.5 db.songhong.com

重新登录页面，会发现报错

假设你的网站用了负载均衡（比如之前配置的lb.songhong.com），用户的请求可能被分到 web01，也可能分到 web02：

用户先在 web01 登录，web01 生成 sess_4n70818dcgqdsgi585io4uchc6 并存在本地，用户 Cookie 里记录对应的 Session ID；
下次请求被负载均衡分到 web02，web02 的 /var/lib/php/session/ 里没有 sess_4n70818dcgqdsgi585io4uchc6 这个文件（因为 web02 从没见过这个用户），就会认为用户 “未登录”，要求重新登录。

这就是分布式系统中常见的 “Session 不一致导致的登录态丢失” 问题。

#会在/var/lib/php/session/这个目录创建登录信息
[root@web01 ~]# ls /var/lib/php/session/
sess_4n70818dcgqdsgi585io4uchc6
sess_b79m76tb51vv9fidnakubnk3eh
sess_en4fup5h08249m23br5atqdbkl
sess_iltk67fqqpjcg3ikgd1c14dnm7
sess_kqoink1nj0cuhn7utvq3nrp4l5
#两个不一致
[root@web02 ~]# ls /var/lib/php/session/
sess_dt8d642j4cs2j3b3dpb5dscjo9
sess_j9d3ho7e2d5723bvdb38bmbpc9

如何解决？

设置一致性哈希或ip哈希

[root@lb01 ~]# cat /etc/nginx/conf.d/db.songhong.com.conf 
upstream  db_group {
  hash $remote_addr consistent; #设置一致性哈希
  server 10.0.0.7:80;
  server 10.0.0.8:80;
}
server {
  listen 80;
  server_name db.songhong.com;
  error_log /var/log/nginx/db-error.log notice;
  access_log /var/log/nginx/db-access.log main;
  location / {
    #传球  转发
    proxy_pass  http://db_group;
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-Ip  $remote_addr;
  }
}

systemctl reload nginx

重新登录，可以登录成功

将登录信息存储到redis

部署redis

在db01安装redis，默认端口6379

yum install -y redis


systemctl enable --now redis

#redis默认端口6379
[root@db01 ~]# ss -lntup | grep redis
tcp     LISTEN   0        128            127.0.0.1:6379          0.0.0.0:*       users:(("redis-server",pid=2353,fd=6))                                         
tcp     LISTEN   0        128                [::1]:6379             [::]:*       users:(("redis-server",pid=2353,fd=7))

#将本地连接设置为远程连接
[root@db01 ~]# egrep -n '^bind|^protect' /etc/redis.conf 
87:bind 127.0.0.1 -::1  #表示本地连接
111:protected-mode yes #表示必须用密码连接，改为no
修改为
[root@db01 ~]# egrep -n '^bind|^protect' /etc/redis.conf 
87:bind 127.0.0.1 -::1 172.16.1.51
111:protected-mode no

[root@db01 ~]# systemctl restart redis
[root@db01 ~]# ss -lntup | grep redis
tcp     LISTEN   0        128          172.16.1.51:6379          0.0.0.0:*       users:(("redis-server",pid=2429,fd=8))                                         
tcp     LISTEN   0        128            127.0.0.1:6379          0.0.0.0:*       users:(("redis-server",pid=2429,fd=6))                                         
tcp     LISTEN   0        128                [::1]:6379             [::]:*       users:(("redis-server",pid=2429,fd=7))

php接入redis

同一台服务器上运行 WordPress 和 phpMyAdmin，两者都依赖 PHP-FPM 解析 PHP 文件，但默认情况下 PHP-FPM 的配置文件（如www.conf）会监听同一个端口（9000），如果共用配置，会导致 “端口被占用” 的冲突。解决办法是为 phpMyAdmin 创建独立的 PHP-FPM 池配置文件，单独指定端口（如 9001），避免和 WordPress 的 9000 端口冲突。

#需要单独修改www.conf,如果共用一个配置文件，会导致端口冲突，9000是wordpress使用，phpmyadmin需要单独一个配置文件
[root@web01 ~]# cd /etc/php-fpm.d/
[root@web01 /etc/php-fpm.d]# ls
www.conf
[root@web01 /etc/php-fpm.d]# cp www.conf phpmyadmin.conf

[root@web01 /etc/php-fpm.d]# egrep -v '^ *$|;' phpmyadmin.conf 
---------------------------------------
[www]
user = nginx
group = nginx
listen = 127.0.0.1:9000
listen.acl_users = apache,nginx
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
slowlog = /var/log/php-fpm/www-slow.log
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path]    = /var/lib/php/session
php_value[soap.wsdl_cache_dir]  = /var/lib/php/wsdlcache
-----------------------------------------
egrep -v '^ *$|;' www.conf >phpmyadmin.conf

[root@web01 /etc/php-fpm.d]# egrep '^\[|^listen =|handler|save_path\]' www.conf 
[www]
listen = 127.0.0.1:9000
php_value[session.save_handler] = files
php_value[session.save_path]    = /var/lib/php/session
#改为下面
[root@web01 /etc/php-fpm.d]# egrep '^\[|^listen =|handler|save_path\]' phpmyadmin.conf 
[phpmyadmin]
listen = 127.0.0.1:9001
php_value[session.save_handler] = redis
php_value[session.save_path]    = tcp://172.16.1.51:6379

[root@web01 /etc/php-fpm.d]# php-fpm -t
[29-Oct-2025 20:36:05] NOTICE: configuration file /etc/php-fpm.conf test is successful

[root@web01 /etc/php-fpm.d]# systemctl restart php-fpm.service
#修改nginx子配置文件db.songhong.com.conf的9000端口
[root@web01 /etc/php-fpm.d]# cat /etc/nginx/conf.d/db.songhong.com.conf | grep fastcgi_pass
  fastcgi_pass 127.0.0.1:9001;
  
  systemctl reload nginx php-fpm

最终的两个配置文件内容

cat >/etc/php-fpm.d/phpmyadmin.conf<<EOF 
[phpmyadmin]
user = nginx
group = nginx
listen = 127.0.0.1:9001
listen.acl_users = apache,nginx
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
slowlog = /var/log/php-fpm/www-slow.log
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = redis
php_value[session.save_path]    = tcp://172.16.1.51:6379
php_value[soap.wsdl_cache_dir]  = /var/lib/php/wsdlcache
EOF



cat /etc/nginx/conf.d/db.songhong.com.conf 
server{
  listen 80;
  server_name db.songhong.com;
  root /app/code/db/;
  error_log /var/log/nginx/db-error.log notice;
  access_log /var/log/nginx/db-access.log main;

  location / {
  index index.php;
  }

  location ~ \.php$ {
  fastcgi_pass 127.0.0.1:9001;
  fastcgi_index index.php;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  include fastcgi_params;
  }
}

安装php的redis插件

安装php的redis插件需要用pecl
pecl install redis
但kylin系统默认没有pecl

直接使用文件编译安装pecl

通过网盘分享的文件：go-pear.php
链接: https://pan.baidu.com/s/10NjCHzHtj13Ip6WJvbbovA?pwd=y8mh 提取码: y8mh
–来自百度网盘超级会员v2的分享

将go-pear.php上传到web服务器

[root@web02 ~]# ls go-pear.php 
go-pear.php
#使用php执行这个文件
[root@web02 ~]# php go-pear.php 
PHP Warning:  Private methods cannot be final as they are never overridden by other classes in /root/go-pear.php on line 339

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

 1. Installation base ($prefix)                   : /usr
 2. Temporary directory for processing            : /tmp/pear/install
 3. Temporary directory for downloads             : /tmp/pear/install
 4. Binaries directory                            : /usr/bin
 5. PHP code directory ($php_dir)                 : /usr/share/pear
 6. Documentation directory                       : /usr/docs
 7. Data directory                                : /usr/data
 8. User-modifiable configuration files directory : /usr/cfg
 9. Public Web Files directory                    : /usr/www
10. System manual pages directory                 : /usr/man
11. Tests directory                               : /usr/tests
12. Name of configuration file                    : /etc/pear.conf

1-12, 'all' or Enter to continue: 
Beginning install...
Configuration written to /etc/pear.conf...
Initialized registry...
Preparing to install...
installing phar:///root/go-pear.php/PEAR/go-pear-tarballs/Archive_Tar-1.5.0.tar...
installing phar:///root/go-pear.php/PEAR/go-pear-tarballs/Console_Getopt-1.4.3.tar...
installing phar:///root/go-pear.php/PEAR/go-pear-tarballs/PEAR-1.10.16.tar...
installing phar:///root/go-pear.php/PEAR/go-pear-tarballs/Structures_Graph-1.2.0.tar...
installing phar:///root/go-pear.php/PEAR/go-pear-tarballs/XML_Util-1.4.5.tar...
warning: pear/PEAR dependency package "pear/Archive_Tar" downloaded version 1.5.0 is not the recommended version 1.4.4
warning: pear/PEAR dependency package "pear/Structures_Graph" downloaded version 1.2.0 is not the recommended version 1.1.1
install ok: channel://pear.php.net/Archive_Tar-1.5.0
install ok: channel://pear.php.net/Console_Getopt-1.4.3
install ok: channel://pear.php.net/Structures_Graph-1.2.0
install ok: channel://pear.php.net/XML_Util-1.4.5
install ok: channel://pear.php.net/PEAR-1.10.16
PEAR: Optional feature webinstaller available (PEAR's web-based installer)
PEAR: Optional feature gtkinstaller available (PEAR's PHP-GTK-based installer)
PEAR: Optional feature gtk2installer available (PEAR's PHP-GTK2-based installer)
PEAR: To install optional features use "pear install pear/PEAR#featurename"

The 'pear' command is now at your service at /usr/bin/pear

** The 'pear' command is not currently in your PATH, so you need to
** use '/usr/bin/pear' until you have added
** '/usr/bin' to your PATH environment variable.

Run it without parameters to see the available actions, try 'pear list'
to see what packages are installed, or 'pear help' for help.

For more information about PEAR, see:

  http://pear.php.net/faq.php
  http://pear.php.net/manual/

Thanks for using go-pear!
直接回车即可


[root@web02 ~]# pecl 
Commands:
build                  Build an Extension From C Source
bundle                 Unpacks a Pecl Package

pecl install redis  #会直接编译安装

[root@web02 ~]# pecl install redis
WARNING: channel "pecl.php.net" has updated its protocols, use "pecl channel-update pecl.php.net" to update
downloading redis-6.2.0.tgz ...
Starting to download redis-6.2.0.tgz (379,865 bytes)
.............................................................................done: 379,865 bytes
43 source files, building
running: phpize
Configuring for:
PHP Api Version:         20200930
Zend Module Api No:      20200930
Zend Extension Api No:   420200930
enable igbinary serializer support? [no] :  回车
enable lzf compression support? [no] : 回车
enable zstd compression support? [no] : 回车
enable msgpack serializer support? [no] : 回车
enable lz4 compression? [no] : 回车
use system liblz4? [yes] :回车


[root@web02 ~]# ls /usr/lib64/php/modules/ | grep red
redis.so

[root@web02 ~]# php -m | grep redis
[root@web02 ~]# echo 'extension=redis.so' >>/etc/php.ini 
[root@web02 ~]# systemctl restart php-fpm.service 
[root@web02 ~]# php -m | grep redis
redis

编译安装redis模块

#1.确认phpize路径（编译扩展的必备工具）
#编译安装的 PHP，phpize通常在 PHP 安装目录的bin文件夹下
find /usr/local/ -name phpize

#2.下载redis扩展源码
## 下载源码包（以6.2.0版本为例，可到https://pecl.php.net/package/redis查看最新版）
wget https://pecl.php.net/get/redis-6.2.0.tgz

#3.解压
tar -zxvf redis-6.2.0.tgz

#4.进入编译目录使用phpize生成编译配置
cd redis-6.2.0/
phpize 
#5.执行后会生成configure文件，此时配置编译参数（指定PHP的配置文件路径）
./configure --with-php-config=/usr/bin/php-config

#6.编译
make -j2

#7.安装
make install

#8.配置php.ini加载 Redis 扩展
[root@web02 ~]# ls /usr/lib64/php/modules/ | grep red
redis.so

[root@web02 ~]# php-fpm -t
[root@web02 ~]# echo 'extension=redis.so' >>/etc/php.ini 
[root@web02 ~]# systemctl restart php-fpm.service 
[root@web02 ~]# php -m | grep redis
redis

两台服务器都配置php的redis模块

负载均衡服务器lb01

[root@lb01 ~]# cat /etc/nginx/conf.d/db.songhong.com.conf 
upstream  db_group {
  #hash $remote_addr consistent;
  server 10.0.0.7:80;
  server 10.0.0.8:80;
}
server {
  listen 80;
  server_name db.songhong.com;
  error_log /var/log/nginx/db-error.log notice;
  access_log /var/log/nginx/db-access.log main;
  location / {
    #传球  转发
    proxy_pass  http://db_group;
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-Ip  $remote_addr;
  }
}

浏览器访问db.songhong.com

登录信息存放在db01的redis上

[root@db01 ~]# redis-cli 
127.0.0.1:6379> 
127.0.0.1:6379>
127.0.0.1:6379> keys *
1) "PHPREDIS_SESSION:2fr76ffm0rvjjmndeht4e8v118"
2) "PHPREDIS_SESSION:fk9fgabjmllslhtsbvq84p6j4i"
#del 名 删除登录信息
127.0.0.1:6379> del  PHPREDIS_SESSION:fk9fgabjmllslhtsbvq84p6j4i
(integer) 1
127.0.0.1:6379> keys *
1) "PHPREDIS_SESSION:2fr76ffm0rvjjmndeht4e8v118"

刷新页面