Nginx 性能優化與動態內容處理

一、壓縮功能

實驗目的：通過啟用 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