一、压缩功能

实验目的：通过启用 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.pswp.cn/news/918183.shtml
繁体地址，请注明出处：http://hk.pswp.cn/news/918183.shtml
英文地址，请注明出处：http://en.pswp.cn/news/918183.shtml

如若内容造成侵权/违法违规/事实不符，请联系英文站点网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

ComfyUI——舒服地让大模型为我所用

ComfyUI——舒服地让大模型为我所用

主页&#xff1a;ComfyUI | 用AI生成视频、图像、音频 https://github.com/comfyanonymous/ComfyUI 安装环境 我的环境是mac&#xff0c;芯片为M4pro。首先从github中下载工程&#xff0c;clone失败就直接下载zip压缩包。在model文件夹中&#xff0c;可以看到很多大名鼎鼎的…
阅读更多...
【Visual Studio】使用VS调试(Debug)

【Visual Studio】使用VS调试(Debug)

确保在Debug模式下而不是Release 打断点(break point) 直接在有代码的行前单击&#xff0c;会出现红色的点(再次单击会取消)&#xff1b;或者光标停留在某行&#xff0c;按F9 这意味着程序当执行到这一行时会终止 在打完断点后点击”本地Windows调试器“或者按F5 往下翻会有代码…
阅读更多...
B2.0:对硬件学习的一些个人心得感悟

B2.0:对硬件学习的一些个人心得感悟

对于硬件学习&#xff0c;所有人都会迷茫的找不到学习的路径和方向&#xff0c;都是自我摸索或者老师带领或者其他情况&#xff0c;而我倒是没有机会接触到现实的老师带我领进这个门&#xff0c;自然走的弯路比较多&#xff0c;所以引申出这篇文章&#xff0c;来聊聊硬件学习的…
阅读更多...
Cursor设置

Cursor设置

一&#xff1a;设置 Port: 7890TUN Mode&#xff1a;开启二&#xff1a;Editor Settings值为http://127.0.0.1:7890三&#xff1a;Cursor 测试一下
阅读更多...
Windows下使用PyInstaller打包PyQt项目

Windows下使用PyInstaller打包PyQt项目

在 Windows 环境下&#xff0c;使用 PyQt 开发的项目可以通过多种工具打包成 可执行文件&#xff08;.exe&#xff09;&#xff0c;以下是几种常见的方法及详细步骤&#xff1a;1. 使用 PyInstallerPyInstaller 是最常用的 Python 打包工具&#xff0c;支持 PyQt5/PyQt6/PySide…
阅读更多...
AI大语言模型在生活场景中的应用日益广泛，主要包括四大类需求：文本处理、信息获取、决策支持和创意生成。

AI大语言模型在生活场景中的应用日益广泛，主要包括四大类需求：文本处理、信息获取、决策支持和创意生成。

一、AI大语言模型生活应用全景图&#xff08;Mermaid流程图&#xff09;graph TDA[生活小事需求] --> B{需求分类}B --> C[文本处理类]B --> D[信息获取类]B --> E[决策支持类]B --> F[创意生成类]C --> C1[邮件写作]C --> C2[内容润色]C --> C3[文档总…
阅读更多...
物奇路由器Wi-Fi芯片荣膺2025中国创新IC-强芯领航奖，并亮相第五届RISC-V中国峰会

物奇路由器Wi-Fi芯片荣膺2025中国创新IC-强芯领航奖，并亮相第五届RISC-V中国峰会

近日&#xff0c;第五届中国集成电路设计创新大会在苏州举办&#xff0c;物奇携多款高性能网络通信与终端人工智能芯片亮相展会&#xff0c;其中首颗路由器Wi-Fi6芯片WQ9301凭借独特的架构创新和领先的性能优势&#xff0c;在国产IC强芯评选中脱颖而出&#xff0c;荣膺2025中国…
阅读更多...
【已解决】npm install报错

【已解决】npm install报错

~/autodl-tmp/App/magic_conch_frontend# npm install报错内容&#xff1a;WARN EBADENGINE Unsupported engine { npm WARN EBADENGINE package: vitejs/plugin-vue5.1.4, npm WARN EBADENGINE required: { node: ^18.0.0 || >20.0.0 }, npm WARN EBADENGINE current: { no…
阅读更多...
IPC总结

IPC总结

IPC 是 Inter-Process Communication&#xff08;进程间通信&#xff09;的缩写&#xff0c;指的是操作系统中不同进程之间传递数据、交换信息或同步行为的机制。由于进程在内存中拥有独立的地址空间&#xff0c;无法直接访问彼此的内存&#xff0c;因此需要通过操作系统提供的…
阅读更多...
java之父-新特性

java之父-新特性

目录 一.函数式接口Functional Interface 1. Supplier接口 --供给型接口 2. Consumer接口 --消费型接口 3.Function接口 --转换型接口 4. Predicate接口--断言型接口 5. Comparator接口--比较器接口 一.函数式接口Functional Interface 只有一个抽象方法的接口&#xff…
阅读更多...
GPT-5的多模态能力如何？

GPT-5的多模态能力如何？

GPT-5的多模态能力如何&#xff1f;概述问题1-非整点闹钟问题2-数数问题一问题3-数数问题二小结概述 2025年&#xff0c;8月8日凌晨&#xff0c;OpenAI 发布了 GPT-5&#xff0c;让我们看看其多模态能力如何&#xff0c;用之前大模型无法解决的题目测试&#xff0c;数数问题时…
阅读更多...
多模态RAG赛题实战--Datawhale AI夏令营

多模态RAG赛题实战--Datawhale AI夏令营

参考自科大讯飞AI大赛&#xff08;多模态RAG方向&#xff09; - Datawhale 赛题意义&#xff1a; 我们正处在一个信息爆炸的时代&#xff0c;但这些信息并非以整洁的纯文本形式存在。它们被封装在各种各样的载体中&#xff1a;公司的年度财报、市场研究报告、产品手册、学术论…
阅读更多...
SQL Server 创建 PostgreSQL 数据库 链接服务器指南

SQL Server 创建 PostgreSQL 数据库 链接服务器指南

SQL Server 创建 PostgreSQL 数据库 链接服务器指南SQL Server 创建 PostgreSQL 数据库 链接服务器指南一、准备工作二、创建链接服务器三、测试连接四、常见问题解决五、注意事项SQL Server 创建 PostgreSQL 数据库 链接服务器指南 一、准备工作 安装 PostgreSQL ODBC 驱动&a…
阅读更多...
李宏毅深度学习教程 第16-18章 终身学习+网络压缩+可解释性人工智能

李宏毅深度学习教程 第16-18章 终身学习+网络压缩+可解释性人工智能

【2025版】44、第十四节 机器终身学习 一 为什么今日的人工智能A_哔哩哔哩_bilibili 【2025版】42、第十三节 神经网络压缩 一 类神经网络剪枝PruA_哔哩哔哩_bilibili 【2025版】30、第九节 机器学习的可解释性 上 – 为什么神经网络可以正_哔哩哔哩_bilibili 目录 1. 终生…
阅读更多...
LiveQing视频RTMP推流视频点播服务功能-云端录像支持按时间段下载录像时间段下载视频mp4

LiveQing视频RTMP推流视频点播服务功能-云端录像支持按时间段下载录像时间段下载视频mp4

LiveQing视频RTMP推流视频点播服务功能-云端录像支持按时间段下载录像时间段下载视频mp41、云端录像2、配置云端录像3、查看云端录像3、列表模式4、时间段下载5、时间段下载接口6、RTMP推流视频直播和点播流媒体服务1、云端录像 LiveQing 支持服务器集中录像&#xff0c;将rtm…
阅读更多...
Spark在什么情况下CBO才会判断失误，如何避免

Spark在什么情况下CBO才会判断失误，如何避免

在 Spark 中&#xff0c;CBO&#xff08;基于成本的优化器&#xff0c;Cost-Based Optimizer&#xff09;通过分析表的统计信息&#xff08;如行数、列基数、数据分布等&#xff09;计算不同执行计划的“成本”&#xff0c;并选择成本最低的计划。但在以下场景中&#xff0c;CB…
阅读更多...
【第12话：感知算法基础4】图像分割：深度学习图像分割模型介绍入门及常用模型详解

【第12话：感知算法基础4】图像分割：深度学习图像分割模型介绍入门及常用模型详解

深度学习图像分割模型介绍入门及常用模型详解 图像分割是计算机视觉的核心任务&#xff0c;旨在将图像划分为语义区域。随着深度学习的发展&#xff0c;分割模型在精度和效率上取得重大突破。以下按技术演进顺序详解主流模型&#xff1a;1. FCN&#xff08;全卷积网络&#xff…
阅读更多...
AI 大模型企业级应用落地挑战与解决方案

AI 大模型企业级应用落地挑战与解决方案

引言&#xff1a;AI 大模型的企业价值与落地困境近年来&#xff0c;以 GPT-4、Claude 3、文心一言为代表的大语言模型&#xff08;LLM&#xff09;展现出惊人的自然语言理解与生成能力&#xff0c;吸引了众多企业的关注。据 Gartner 预测&#xff0c;到 2025 年&#xff0c;40%…
阅读更多...
微服务如何保证系统高可用？

微服务如何保证系统高可用？

今天我们来探讨一个综合性但至关重要的话题&#xff1a;给你一个微服务应用&#xff0c;你该如何系统性地保证其高可用性&#xff1f;在互联网技术岗的面试中&#xff0c;高并发、高可用和大数据通常被视为衡量候选人经验的三大黄金标准。但说实话&#xff0c;是否拥有真正的高…
阅读更多...
推理路径的动态调控：让大模型学会“恰到好处”的思考

推理路径的动态调控：让大模型学会“恰到好处”的思考

当前大型语言模型&#xff08;LLM&#xff09;通过思维链&#xff08;CoT&#xff09;提升复杂任务推理能力&#xff0c;但研究表明其推理路径存在严重冗余——例如反复验证或无效思维跳跃&#xff0c;导致计算资源浪费和“幻觉”增加。论文&#xff1a;Test-time Prompt Inter…
阅读更多...
最新文章

Copyright @ 2022~2023