当前位置： 首页 > news >正文

Nginx 性能优化与动态内容处理

news 2025/8/10 8:27:33

一、压缩功能

实验目的：通过启用 Nginx 的 Gzip 压缩功能，对传输的文件（如 HTML、日志等）进行压缩，减少网络传输数据量，提升用户访问速度（尤其适用于带宽有限的场景），同时通过参数优化平衡压缩效率与服务器 CPU 消耗。

压缩功能的核心价值

在 Web 服务中，客户端（如浏览器）与服务器之间传输的文件（HTML、CSS、JS、日志等）通常体积较大，会占用较多带宽并延长加载时间。Gzip 压缩的原理是：

  • 服务器在发送文件前，先对其进行压缩（类似 ZIP 压缩）；

  • 客户端接收到压缩文件后，自动解压并渲染内容。

这种机制的核心优势：

  • 减少传输数据量：文本类文件（如 HTML、日志）压缩率可达 50%-70%，大幅降低带宽消耗；

  • 提升加载速度：相同带宽下，压缩后的文件传输时间更短，用户体验更流畅；

  • 节省服务器带宽成本：尤其对高流量网站，可显著降低带宽费用。

vim /usr/local/nginx/conf/nginx.conf        # 编写主配置文件
########
http {
...gzip  on;                               # 开启 Gzip 压缩功能gzip_comp_level 4;                      # 设置 Gzip 压缩级别（1-9）# 4/5 为平衡压缩率和 CPU 消耗的常用值# 级别越高，压缩率越高（文件越小）# 但消耗 CPU 资源越多gzip_disable "MSIE [1-6]\.";            # 对 IE 6 及以下版本浏览器禁用 Gzip 压缩# 原因：旧版 IE 对 Gzip 压缩的支持存在缺陷# 可能导致内容解析错误gzip_min_length 4k;                     # 设置触发 Gzip 压缩的最小文件大小（4KB）gzip_http_version 1.1;                  # 仅压缩大小 ≥4KB 的文件# gzip_buffers number size;             # 设置压缩时使用的缓冲区# number 为缓冲区数量，size 为单个缓冲区大小# 默认由 Nginx 自动计算# 一般无需手动配置，故注释保留# gzip_type mime-type text/html;        # 指定需要压缩的 MIME 类型#（如 text/html、application/json 等）# 默认已包含 text/html 等常见类型gzip_vary on;                           # 开启 Vary 响应头，适配代理服务器# 告知代理服务器：同一资源可能有压缩/未压缩两种版本# 需根据客户端的 Accept-Encoding 头选择返回# 避免代理服务器错误地将压缩版本返回给不支持压缩的客户端gzip_static on;                         # 启用静态预压缩文件支持# 若存在与源文件同名的 .gz 预压缩文件# 直接返回预压缩文件，无需实时压缩，减少 CPU 消耗
...
}
########
​
echo small > /usr/local/nginx/html/small.html
cp /usr/local/nginx/logs/zyz.org.access /usr/local/nginx/html/big.html
​
ll /usr/local/nginx/html/ -h
#######
-rw-r--r-- 1 root root 23K Jul 26 14:31 big.html        # 超过 4k 将会被压缩
-rw-r--r-- 1 root root  14 Jul 24 10:09 index.html
-rw-r--r-- 1 root root   6 Jul 26 14:31 small.html      # 未超过 4k 不会被压缩
#######
​
nginx -t
systemctl restart nginx
curl --head --compressed 192.168.67.10/big.html
curl --head --compressed 192.168.67.10/small.html

用 curl --head --compressed 查看响应头，判断文件是否被压缩

测试：结果表示文件大小大于 4k 的文件显示已被压缩，格式为 gzip。文件大小小于 4k 的文件未被压缩。

为什么这样配置？核心优化逻辑

  • 平衡性能与资源：

    • 压缩级别选 4，避免高级别（如 9）过度消耗 CPU；

    • 设置最小压缩阈值（4KB），避免小文件浪费资源。

  • 兼容性优先：

    • 禁用旧版 IE 压缩，避免解析错误；

    • 限制 HTTP/1.1 协议，减少协议兼容问题。

  • 提升效率：

    • 启用 gzip_static 利用预压缩文件，降低实时压缩的 CPU 负载；

    • 开启 gzip_vary 确保代理服务器正确处理压缩内容。

适用场景与扩展

  • Gzip 压缩对文本类文件（HTML、CSS、JS、日志、JSON 等）效果显著（压缩率高），对二进制文件（图片、视频等，已自带压缩算法）效果差甚至反增体积，因此实际配置中可通过 gzip_type 精确指定需压缩的文件类型（如 gzip_type text/html text/css application/json;）。

  • 适合场景：所有需要优化加载速度、节省带宽的 Web 服务，尤其是静态资源较多的网站（如博客、文档站）。

  • 通过配置 Gzip 压缩，Nginx 能在可控的 CPU 消耗下，大幅减少传输数据量，显著提升用户访问速度，是 Web 服务性能优化的基础且高效的手段。

二、反向代理缓存功能

实验目的：在反向代理架构中，通过配置 Nginx 缓存功能，将后端服务器返回的重复请求资源（如静态页面）存储在代理服务器本地，当后续有相同请求时直接从缓存返回，无需再次访问后端，从而缩短响应时间、减少后端服务器负载，优化整体服务性能。

缓存的核心原理

Nginx 反向代理缓存的本质是 “本地存储 + 按需复用”：

  1. 客户端首次请求资源（如 www.haha.org/index.html）时，代理服务器转发请求到后端服务器（RS1），获取响应后，将资源副本存储在本地缓存目录；

  2. 当相同客户端（或其他客户端）再次请求该资源时，代理服务器直接从本地缓存读取并返回，跳过 “转发到后端” 的步骤；

  3. 缓存会按规则自动过期（如超过设定时间未访问）或更新（后端资源变化时），确保数据有效性。

核心价值：减少后端服务器的重复处理工作（尤其对静态、低频更新的资源），同时通过 “本地读取” 大幅提升响应速度。

关键参数解析：

# 主配置文件添加
vim /usr/local/nginx/conf/nginx.conf        
##########
http {...proxy_cache_path /usr/local/nginx/cache levels=1:2:2 keys_zone=proxycache:20m inactive=120s max_size=1g;...
}
##########

  • /usr/local/nginx/cache：缓存文件的实际存储路径（代理服务器本地目录，需确保 Nginx 有权限读写）。

  • levels=1:2:2：缓存目录的层级结构（避免单目录文件过多导致的性能问题）。

    • 含义：将缓存键（资源唯一标识）的哈希值按 “1 位：2 位：2 位” 拆分，创建多级目录（如哈希值前 5 位为 a1b2c，则目录为 cache/a/1b/2c/...）；

    • 作用：分散文件存储，提升缓存文件的读写效率（单目录文件过多会导致查找缓慢）。

  • keys_zone=proxycache:20m：定义内存中的缓存元数据区域。

    • proxycache：区域名称（后续在 location 中引用）；

    • 20m：区域大小（20MB），用于存储缓存键、有效期等元数据（不存储实际资源内容）；

    • 作用：快速判断资源是否在缓存中，避免每次都去磁盘查找，提升缓存命中效率。

  • inactive=120s：非活动缓存的过期时间（120 秒）。

    • 含义：若某缓存资源 120 秒内无任何请求访问，自动从磁盘删除；

    • 作用：清理长期闲置的缓存，释放磁盘空间，避免无效缓存堆积。

  • max_size=1g：缓存的最大磁盘占用（1GB）。

    • 含义：当缓存总大小超过 1GB 时，Nginx 会自动删除最久未使用的缓存（LRU 算法）；

    • 作用：防止缓存无限制增长，避免占用过多磁盘资源影响服务器其他功能。

# 子配置文件添加
vim /usr/local/nginx/conf.d/haha.conf 
##########
server {listen  80;server_name www.haha.org;
​location / {                            # 静态请求缓存配置proxy_pass http://192.168.67.10;    # 转发到后端静态服务器（RS1）proxy_cache proxycache;             # 启用缓存，关联主配置中定义的内存区域proxy_cache_key string;             # 定义缓存键proxy_cache_valid 200 302 10m;      # 对 200（成功）、302（重定向）响应，缓存10分钟proxy_cache_valid 404 1m;           # 对 404（未找到）响应，缓存1分钟}
​location ~ \.(php|jsp|js)$ {proxy_pass http://192.168.67.20;}
##########
​
systemctl restart nginx

测试：

通过 ab 工具分别在 “无缓存” 和 “有缓存” 状态下测试访问速度：

  • 无缓存：首次请求需转发到后端 RS1，响应时间约 281ms；

  • 有缓存：重复请求直接从代理服务器本地缓存返回，响应时间降至约 151ms。

结论：缓存生效，显著提升了重复请求的响应速度，同时减少了后端服务器的请求量（无需重复处理相同请求）。

为什么这样配置？核心优化逻辑

  • 分层存储提升效率：内存（keys_zone）存元数据、磁盘存实际资源，兼顾 “快速判断” 和 “大容量存储”；

  • 目录结构避免瓶颈：levels 多级目录防止单目录文件过多，确保缓存读写高效；

  • 过期策略平衡资源：inactive 清理闲置缓存、max_size 限制总大小，避免资源浪费；

  • 按需缓存精准控制：静态资源缓存（有效期长）、动态资源不缓存（避免过时），适配不同资源特性。

适用场景

  • 缓存功能特别适合：

    • 静态资源服务（HTML、图片、CSS 等，内容稳定、更新频率低）；

    • 高并发、重复请求多的场景（如热门页面、活动页面）；

    • 后端服务器性能有限的场景（通过缓存分担压力）。

三、实现 FastCGI

FastCGI 是一种用于 Web 服务器与动态内容处理程序（如 PHP、Python 脚本解释器）之间的通信协议，核心目的是解决传统 CGI 协议的性能瓶颈，提升动态网页的处理效率和并发能力。

传统 CGI 协议的问题在于：每次处理请求都需创建新进程 / 线程，处理完后立即销毁。这会导致频繁的进程创建 / 销毁开销（CPU、内存资源浪费），无法应对高并发场景。

FastCGI 的改进在于：

  1. 常驻进程模型： 启动时预先创建一批独立的工作进程（Worker Process），由 FastCGI 进程管理器（Process Manager） 统一管理。这些进程启动后不会销毁，而是持续等待并处理新请求。

  2. 协议通信流程：

    • ① Web 服务器（如 Nginx、Apache）接收客户端 HTTP 请求，解析出动态内容请求（如 .php 文件）。

    • ② Web 服务器通过 FastCGI 协议（基于 TCP 或 Unix 套接字），将请求数据（如 URL、参数、HTTP 头）发送给 FastCGI 进程管理器。

    • ③ 进程管理器从空闲的工作进程中分配一个，处理请求（如执行 PHP 脚本、访问数据库）。

    • ④ 工作进程处理完成后，将结果（如 HTML 内容）通过 FastCGI 协议返回给 Web 服务器。

    • ⑤ 工作进程处理完后不销毁，回到 “空闲” 状态，等待下一次分配。

FastCGI 主要用于 Web 服务器与动态脚本解释器之间的高效协作，解决传统 CGI 的性能问题，具体价值包括：

  1. 降低资源开销： 避免了 CGI 中 “一次请求创建一个进程” 的低效模式，通过常驻进程减少进程创建 / 销毁的 CPU 和内存消耗。

  2. 支持高并发： 进程管理器可根据负载动态调整工作进程数量（如 PHP-FPM 的 pm.max_children 配置），同时处理多个请求，提升系统并发能力。

  3. 语言无关性： 兼容多种动态语言（PHP、Python、Perl 等），只需对应语言的 FastCGI 处理程序（如 PHP 的 PHP-FPM、Python 的 flup）。

  4. 分离 Web 服务器与处理程序： Web 服务器专注于静态资源处理（如 HTML、CSS、图片）和请求转发，动态内容交给独立的 FastCGI 进程处理，职责分离更灵活（甚至可部署在不同服务器）。

yum install -y bzip2 systemd-devel libxml2-devel sqlite-devel libpng-devel libcurl-devel oniguruma-devel        # 注：oniguruma-devel 需要先更新 oniguruma 再安装 oniguruma-devel
​
./configure \--prefix=/usr/local/php \                     # PHP 安装路径--with-config-file-path=/usr/local/php/etc \  # php.ini 配置文件路径--enable-fpm \                                # 核心：启用 PHP-FPM（FastCGI 进程管理器）--with-fpm-user=nginx \                       # PHP-FPM 工作进程用户（与 Nginx 一致，避免权限问题）--with-fpm-group=nginx \                      # PHP-FPM 工作进程组--with-curl \                                 # 启用 curl 扩展（支持 HTTP 请求）--with-iconv \                                # 启用字符编码转换--with-mhash \                                # 启用加密哈希算法--with-zlib \                                 # 启用 zlib 压缩--with-openssl \                              # 启用 SSL 支持--enable-mysqlnd \                            # 启用 MySQL 原生驱动--with-mysqli \                               # 启用 mysqli 扩展（MySQL 交互）--with-pdo-mysql \                            # 启用 PDO MySQL 扩展--disable-debug \                             # 禁用调试模式（生产环境优化）--enable-sockets \                            # 启用 sockets 扩展（网络通信）--enable-soap \                               # 启用 SOAP 服务支持--enable-xml \                                # 启用 XML 扩展--enable-ftp \                                # 启用 FTP 支持--enable-gd \                                 # 启用 GD 库（图片处理）--enable-exif \                               # 启用 EXIF 图片元数据处理--enable-mbstring \                           # 启用多字节字符串支持--enable-bcmath \                             # 启用数学计算扩展--with-fpm-systemd                            # 支持 systemd 管理 PHP-FPM 服务
​
​
cd /usr/local/php/etc
cp php-fpm.conf.default php-fpm.conf            # 复制默认配置为正式配置文件
​
vim php-fpm.conf
##########
pid = run/php-fpm.pid       # 取消注释，指定 PHP-FPM 进程 ID 文件路径（便于 systemd 管理）
##########
​
cd php-fpm.d/
cp www.conf.default www.conf        # 复制默认工作池配置
​
vim www.conf
##########
listen = 0.0.0.0:9000               # PHP-FPM 监听 9000 端口（Nginx 会通过此端口转发请求）# 生产环境中通常使用 127.0.0.1:9000（仅本地访问）更安全，此处用 0.0.0.0:9000 便于测试
##########
​
cd /root/php-8.3.9/
cp php.ini-production /usr/local/php/etc/php.ini    # 复制生产环境配置模板
​
vim /usr/local/php/etc/php.ini
###########
[Date]
; Defines the default timezone used by the date functions
; https://php.net/date.timezone
date.timezone = Asia/Shanghai                       # 配置 PHP 时区为上海（避免时间相关函数报错）
###########
​
cd /root/php-8.3.9/
cp sapi/fpm/php-fpm.service /lib/systemd/system/    # 复制服务文件到 systemd 目录
vim /lib/systemd/system/php-fpm.service
#########
# ProtectSystem=full            # 注释此行（避免系统权限限制 PHP-FPM 访问所需文件）
#########
​
systemctl daemon-reload
systemctl start php-fpm.service
systemctl enable --now php-fpm.service
​
netstat -antlupe | grep php

vim /usr/local/nginx/html/index.php 
##########
<?phpphpinfo();
?>
##########
​
vim /usr/local/nginx/conf.d/haha.conf 
##########
server {listen  80;server_name www.haha.org;
​root /usr/local/nginx/html; location ~ \.php$ {fastcgi_pass 127.0.0.1:9000;    # 转发请求到 PHP-FPM 的监听地址（9000 端口）fastcgi_index index.php;        # 默认 PHP 首页include fastcgi.conf;           # 引入 Nginx 预定义的 FastCGI 变量配置# 如：$document_root 传递网站根目录# $request_uri 传递请求路径# 确保 PHP 能正确解析请求}
}
##########
​
systemctl restart nginx

测试：

浏览器访问 http://www.haha.org/index.php，若显示 PHP 信息页（包含配置、扩展等信息），说明 Nginx 与 PHP-FPM 通过 FastCGI 协议正常协作。

添加环境变量

将 Nginx（/usr/local/nginx/sbin）和 PHP（/usr/local/php/bin、/usr/local/php/sbin）的可执行文件路径加入系统 PATH，可直接在命令行使用 nginx、php、php-fpm 命令（无需输入完整路径），提升操作效率。

vim ~/.bash_profile
########
export PATH=$PATH:/usr/local/nginx/sbin:/usr/local/php/bin:/usr/local/php/sbin
########
​
source  ~/bash_profile

核心价值与优势

  1. 高性能：FastCGI 常驻进程模型避免了传统 CGI 的进程创建 / 销毁开销，PHP-FPM 可通过配置（如 pm.max_children）调整工作进程数量，支持高并发请求；

  2. 职责分离：Nginx 专注处理静态资源（HTML、CSS、图片）和请求转发，PHP-FPM 专注执行 PHP 脚本，分工明确提升整体效率；

  3. 扩展性强：通过 PHP 扩展支持多种功能（数据库、图片处理等），满足复杂动态页面需求；

  4. 易管理：PHP-FPM 提供进程监控、性能统计功能，结合 systemd 可便捷管理服务生命周期。

四、memcache 缓存

实验目的：通过配置 PHP 的 Memcache 扩展与 Memcached 服务，实现动态内容（如数据库查询结果、频繁访问的页面数据）的内存缓存。利用 Memcache 高速读写的特性，减少重复计算或数据库访问，提升页面响应速度，降低 Web 服务器和后端服务的负载。

Memcache 缓存的核心价值

Memcache 是一种分布式内存缓存系统，核心作用是将频繁访问的数据（如用户信息、商品列表、API 响应）存储在内存中，而非每次从数据库或磁盘读取。其优势在于：

  • 速度快：内存读写速度远高于磁盘（数据库通常依赖磁盘），可将毫秒级响应降至微秒级；

  • 降低后端压力：减少对数据库或业务逻辑的重复请求（如同一商品信息被 thousands 次访问，只需查询一次数据库，后续从缓存读取）；

  • 支持高并发：内存并发读写能力强，适合高流量场景（如电商秒杀、热门资讯）。

本实验通过 PHP 连接 Memcached 服务，实现动态内容的缓存，再结合 Nginx 作为 Web 服务器，构建 “前端 - 缓存 - 后端” 的高效架构。

添加 memcache 模块

tar zxf memcache-8.2.tgz        # 解压 Memcache 扩展源码包
cd memcache-8.2/                # 进入源码目录
yum install autoconf -y         # 安装 autoconf（用于生成 PHP 扩展的编译配置脚本）
phpize                          # 生成 PHP 扩展编译所需的配置文件（基于当前 PHP 环境）
./configure && make && make install     # 检查系统环境，生成 Makefile（适配当前 PHP 版本和系统）
​
​
vim /usr/local/php/etc/php.ini
##########
;extension=zip
extension=memcache              # 启用 Memcache 扩展（告诉 PHP 加载该模块）# extension=memcache 是让 PHP 启用 Memcache 扩展的关键配置，只有加载该扩展，PHP 脚本才能通过 memcache 类与 Memcached 服务通信（如存储、读取缓存数据）。
;zend_extension=opcache
##########
​
systemctl restart php-fpm
php -m | grep mem

Memcached 是独立的缓存服务进程，负责管理内存中的缓存数据，提供 TCP 接口供客户端（如 PHP）读写数据，默认监听 11211 端口。

yum install -y memcached.x86_64
​
vim /etc/sysconfig/memcached 
#########
OPTIONS="-l 0.0.0.0,::1"            # 允许所有网络接口访问（默认可能仅监听 127.0.0.1）
#########
​
systemctl start memcached.service 
systemctl enable --now memcached.service 
netstat -antlup | grep memcached
​
cd /mnt/memcache-8.2/                               # 回到 Memcache 扩展源码目录（包含示例脚本）
cp example.php memcache.php /usr/local/nginx/html/  # 将示例脚本复制到 Nginx 网站根目录（便于通过浏览器访问）

  • example.php：模拟缓存使用场景（如存储 / 读取数据，展示缓存命中效果）；

  • memcache.php：Memcached 管理界面（展示缓存命中率、存储数据量、服务器状态等）。

vim /usr/local/nginx/html/memcache.php 
########
define('ADMIN_USERNAME','zyz');     // Admin Username       # 定义用户名
define('ADMIN_PASSWORD','zyz');     // Admin Password       # 定义密码
#$MEMCACHE_SERVERS[] = 'mymemcache-server1:11211'; // add more as an array  # 注释此行
$MEMCACHE_SERVERS[] = '127.0.0.1:11211'; // add more as an array            # 添加本地 Memcached 服务器
########
​
ab -n 1000 -c 100 www.haha.org/example.php          # 压测，查看 memcache 缓存效果

example.php 会模拟 “从缓存读取数据，若未命中则从‘后端’（模拟数据库）获取并写入缓存” 的过程。高并发压测可触发缓存机制：首次请求缓存未命中（从后端获取），后续请求从缓存读取，验证缓存是否有效降低后端负载。

通过管理界面查看缓存状态

浏览器访问 www.haha.org/memcache.php，输入配置的用户名（zyz）和密码（zyz），查看缓存统计信息：

  • 命中率（Hit Rate）：压测后命中率显著提升（如从 50% 升至 100%），说明大部分请求从缓存读取，而非后端；

  • 存储数据量：显示缓存中存储的键值对数量，验证数据是否被正确缓存；

  • 服务器状态：确认 Memcached 服务正常运行，内存使用情况等。

核心配置与缓存原理解析

  1. PHP 扩展与 Memcached 服务的关系：

    • Memcache 扩展是 PHP 的 “客户端”，提供 memcache_connect()、memcache_set()、memcache_get() 等函数，用于与 Memcached 服务通信；

    • Memcached 服务是 “服务器端”，负责管理内存中的缓存数据，接收客户端的读写请求。

  2. 缓存工作流程（以 example.php 为例）：

    • ① 客户端请求 example.php，Nginx 转发给 PHP-FPM；

    • ② PHP 脚本尝试从 Memcached 读取数据（memcache_get()）；

    • ③ 若缓存命中（数据存在），直接返回缓存数据；

    • ④ 若缓存未命中，从 “后端”（如数据库）获取数据，写入 Memcached（memcache_set()），再返回数据；

    • ⑤ 后续请求重复步骤②-③，优先使用缓存。

  3. 命中率的意义： 命中率 = 缓存命中次数 / 总请求次数。命中率越高，说明缓存越有效（如 90% 命中率表示 90% 的请求无需访问后端），大幅降低后端服务（如数据库）的压力。

适用场景与优势

Memcache 缓存适合以下场景：

  • 频繁访问的静态化动态内容：如商品详情页（数据不常变，但访问量大）；

  • 数据库查询结果缓存：如用户信息列表、热门文章；

  • 会话存储：存储用户登录状态（替代文件存储，提升并发能力）。

相比直接访问后端，其优势在于：

  • 响应速度提升 10-100 倍（内存 vs 磁盘）；

  • 后端服务负载降低 50% 以上（减少重复请求）；

  • 支持分布式扩展（多台 Memcached 服务器协同工作，应对更大缓存需求）。

五、memcache 前置

实验目的：通过配置 Nginx 直接与 Memcached 交互（即 “Memcache 前置”），实现 “Nginx 优先查询缓存，未命中再转发给 PHP” 的架构。相比传统 “PHP 查缓存” 的模式，可减少 PHP 处理的请求量，解决 PHP 成为性能瓶颈的问题，提升整体架构的并发能力和响应速度。

Memcache 前置的核心价值（对比传统架构）

传统架构中，客户端请求的处理流程是：

  • 客户端 → Nginx → PHP → Memcached（查缓存）→ 数据库（未命中时）

问题：无论缓存是否命中，请求都必须经过 PHP，导致 PHP 成为瓶颈（尤其高并发时，PHP 进程可能被占满，无法处理新请求）。

Memcache 前置架构的流程是：

  • 客户端 → Nginx → Memcached（查缓存，命中则直接返回）→ 未命中 → PHP → 处理后存入 Memcached → 返回

优势：Nginx 直接与 Memcached 交互，缓存命中时无需经过 PHP，仅未命中时才调用 PHP，大幅减少 PHP 的请求量，降低其负载，提升整体吞吐量。

下图：没设置 memcache 前置时，压测访问后端 php 页面，每次都会经过 php，会造成一定数据的丢失。

memcache 前置的配置如下：

准备 Memcache 前置所需的 Nginx 模块

Nginx 本身不支持直接与 Memcached 交互，需依赖两个第三方模块：

  • memc-nginx-module：提供 Nginx 访问 Memcached 的核心功能（如读写缓存数据）；

  • srcache-nginx-module：实现 “先查缓存，未命中再转发到后端” 的逻辑（缓存获取与存储的调度）。

cd /mnt/
tar xzf memc-nginx-module-0.20.tar.gz           # memc 模块负责与 Memcached 通信
tar xzf srcache-nginx-module-0.33.tar.gz        # srcache 模块负责控制缓存的 “查询 - 转发 - 存储” 流程
​
cd /mnt/nginx-1.26.1/                           # 重新编译 Nginx（集成新模块）
​
make clean./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --add-module=/mnt/echo-nginx-module-0.63 --add-module=/mnt/memc-nginx-module-0.20 --add-module=/mnt/srcache-nginx-module-0.33
​
make                # make 仅编译生成新的 nginx 二进制文件（在 objs/ 目录），不覆盖现有配置。
​
cd objs/                                # 进入编译生成的目标文件目录
systemctl stop nginx                    # 停止运行中的 Nginx（需替换二进制文件）
cp nginx /usr/local/nginx/sbin/nginx    # 替换旧的 Nginx 执行文件
cd /usr/local/nginx/sbin
systemctl start nginx                   # 启动新的 Nginx
nginx -V                                # 查看模块是否添加成功

新编译的 nginx 已集成 memc 和 srcache 模块，替换后 Nginx 可支持直接与 Memcached 交互的指令（如 memc_pass、srcache_fetch）。

配置 Memcache 前置规则（核心配置）

编辑 /usr/local/nginx/conf.d/haha.conf，实现 Nginx 直接查缓存的逻辑：

vim /usr/local/nginx/conf.d/haha.conf 
############
upstream memcache {             # 定义 Memcached 服务器组（供 Nginx 直接连接）server 127.0.0.1:11211;     # 指向本地 Memcached 服务（11211 端口）keepalive 512;              # 保持 512 个长连接，减少连接建立/关闭的开销
}
​
server {listen  80;server_name www.haha.org;
​root /usr/local/nginx/html;
​location /memc {                    # 内部缓存操作接口（禁止外部直接访问）internal;                       # 仅允许 Nginx 内部访问，禁止外部直接访问该路径memc_connect_timeout 100ms;     # 连接超时（100ms）memc_send_timeout 100ms;        # 发送数据超时（100ms）memc_read_timeout 100ms;        # 读取数据超时（100ms）set $memc_key $query_string;    # 缓存键（key）设为 URL 查询参数（由调用者传递）set $memc_exptime 300;          # 缓存过期时间（300 秒，5 分钟）memc_pass memcache;             # 转发缓存操作到上面定义的 memcache 服务器组}location ~ \.php$ {                 # 处理 PHP 请求：优先查缓存，未命中再调用 PHPset $key $uri$args;             # 定义缓存键：URL 路径（$uri）+ 查询参数（$args），确保唯一标识请求srcache_fetch GET /memc $key;   # 第一步：查缓存。用 GET 方法调用 /memc 接口，以 $key 为键查缓存srcache_store PUT /memc $key;   # 第三步：存缓存。PHP 处理后，用 PUT 方法调用 /memc 接口，以 $key 为键存缓存fastcgi_pass 127.0.0.1:9000;    # 第二步：未命中缓存时，转发给 PHP 处理fastcgi_index index.php;        # 默认首页include fastcgi.conf;           # 引入 FastCGI 配置}
}
############
​
nginx -t
systemctl restart nginx
ab -n 1000 -c 100 www.haha.org/index.php

相比传统架构（无前置），压测无数据包丢失（PHP 被访问的次数减少，负载降低）；

通过 Memcached 管理界面（memcache.php）可观察到缓存命中率显著提升，说明多数请求由 Nginx 直接从缓存返回，未经过 PHP。

为什么这样配置？核心优化逻辑

  1. 减少 PHP 瓶颈：Nginx 直接查缓存，命中则无需调用 PHP，PHP 仅处理 “缓存未命中” 的请求，负载降低 50% 以上；

  2. 提升响应速度：Nginx 与 Memcached 的交互效率高于 PHP 与 Memcached（减少 PHP 进程调度开销），缓存命中时响应更快；

  3. 长连接优化：upstream memcache 中的 keepalive 减少 TCP 连接建立 / 关闭的开销，适合高并发场景；

  4. 安全隔离：internal 配置防止外部直接操作缓存，避免缓存被恶意篡改或删除；

  5. 超时控制：严格的超时设置（100ms）确保 Memcached 故障时不会阻塞 Nginx 进程（超时后直接转发给 PHP，保证服务可用性）。

适用场景

Memcache 前置特别适合：

  • 动态内容但更新不频繁的场景（如商品详情页、新闻文章）；

  • 高并发读场景（如秒杀活动、热门资讯）；

  • PHP 性能成为瓶颈的系统（通过减少 PHP 调用提升整体吞吐量）。

通过 Memcache 前置配置，Nginx 从 “单纯的转发者” 转变为 “智能缓存代理”，大幅减少 PHP 处理的请求量，显著提升架构的并发能力和响应速度，是高流量动态网站性能优化的关键手段。

http://www.lryc.cn/news/615168.html

相关文章：

  • TOMCAT笔记
  • 七、《Serverless架构：按毫秒计费的成本革命》--从新浪AI推理平台50%效能提升看无服务器本质
  • 前端如何安全存储 API 密钥 —— 两种实用方案
  • CosyVoice 语音合成模型性能优化实战：从 CPU 瓶颈到 GPU 加速的完整解决方案
  • electron多进程设计
  • K8s-pod控制器
  • Baumer高防护相机如何通过YoloV8深度学习模型实现输电线路塔电缆检测分割（C#代码UI界面版）
  • DAY 37 作业（补）
  • 99-基于Python的京东手机数据分析及预测系统
  • 【工具变量】全国省级农业保险保费收入与赔付支出数据更新（2001-2023年）
  • 爬虫攻防战：反爬与反反爬全解析
  • react-window
  • 【Datawhale AI夏令营】基于多模态RAG的企业财报问答系统
  • Arduino系列教程：点亮一个LED灯
  • 【工具】Python多环境管理
  • Red Hat Enterprise Linux 7.9安装Oracle 11.2.0.4单实例数据库-图文详解
  • Python训练营打卡Day27-类的定义和方法
  • 线程池多反应堆服务器webserver（c++）
  • 算法篇----模拟
  • Linux的软件防火墙iptables
  • QML 鼠标穿透
  • 从免费到盈利：Coze智能体1小时封装变现全流程指南——井云科技
  • 云服务器--阿里云OSS(2)【Springboot使用阿里云OSS】
  • 81 keil仿真调试记录
  • C++11中的移动语义
  • 优化器：SGD、Adam、RMSprop等优化算法对比与机器翻译应用
  • day 16 stm32 IIC
  • 【Java EE初阶 --- 网络原理】JVM
  • 堆----3.数据流的中位数
  • 【Redis】Redis-plus-plus的安装与使用