Nginx 平滑重啟與腳本化管理實戰指南

前言

在 Nginx 部署新配置或模組後，重啟服務是必經步驟。單純使用 kill 強制終止進程雖然快捷，但存在風險：若配置有誤，服務將無法啟動，導致停機。本文將介紹更優雅的「平滑重啟」技巧，並提供一個自動化腳本，解決配置測試與資源衝突的痛點。

一、傳統 kill 重啟的缺陷

許多管理員習慣用 kill -9 `cat /path/to/nginx.pid` 粗暴終止主進程。這在高併發場景下極不推薦：

• 舊進程瞬間消失，正在處理的請求直接中斷，用戶體驗極差。
• 若配置語法錯誤，新主進程啟動失敗，服務將徹底掛掉，需人工介入修復。
• 機器負載高時，進程可能無法瞬間殺乾淨，需重複執行。

二、平滑重啟：信號量 HUP 的魔力

Nginx 支持熱重載機制，向 Master 進程發送 HUP 信號即可觸發：

kill -HUP `cat /data/nginx/logs/nginx.pid`

流程解析：

1. Master 進程讀取新配置，啟動新的 Worker 進程組。
2. 舊 Worker 進程停止接受新連接，繼續處理當前請求直到完成。
3. 舊進程優雅退出，新進程全面接管服務，實現零停機切換。

隱患：若配置有誤或端口衝突，Nginx 僅在錯誤日誌中記錄，控制台無任何提示，導致「以為重啟成功實際配置未生效」的假象。

三、進階腳本：預檢配置 + 智能重啟

為規避上述風險，編寫 nginx.sh 整合配置測試與進程管理：

#!/bin/sh
BASE_DIR='/usr/local/'

# 1. 語法檢查，輸出結果到臨時文件
${BASE_DIR}nginx/sbin/nginx -t -c ${BASE_DIR}nginx/conf/nginx.conf &> ${BASE_DIR}nginx/logs/nginx.start
info=`cat ${BASE_DIR}nginx/logs/nginx.start`

# 2. 判斷語法是否通過
if [ `echo $info | grep -c "syntax is ok"` -eq 1 ]; then
    # 3. 檢查 Master 進程是否存在
    if [ `ps aux | grep "nginx" | grep -c "master"` == 1 ]; then
        # 平滑重啟
        kill -HUP `cat ${BASE_DIR}nginx/logs/nginx.pid`
        echo "ok"
    else
        # 進程不存在，強制殺殘留進程後重新啟動
        killall -9 nginx
        sleep 1
        ${BASE_DIR}nginx/sbin/nginx
    fi
else
    # 4. 配置錯誤，輸出詳細錯誤信息
    echo "######## error: ########"
    cat ${BASE_DIR}nginx/logs/nginx.start
fi

四、腳本關鍵點解析

1. 配置預檢（-t 參數）

啟動前先跑 nginx -t，捕獲 syntax is ok 關鍵字，確保配置合法才執行後續操作，從根源杜絕「配置錯誤導致服務不可用」。

2. 進程狀態感知

通過 ps aux | grep master 判斷服務運行狀態：

• 存在 Master → 發送 HUP 信號平滑重載。
• 不存在 → 清理殘留進程（killall -9）後冷啟動。

3. 錯誤可視化

語法檢查失敗時，直接輸出完整錯誤日誌，讓運維一眼定位問題（如端口被佔用、目錄缺失、指令拼寫錯誤等）。

五、局限性與建議

該腳本解決了「配置錯誤無感知」問題，但無法處理運行時資源衝突（如 80 端口被其他進程佔用、日誌目錄權限不足）。生產環境建議配合 systemd 或 supervisor 進行進程守護，並建立監控告警機制。

六、總結

從粗暴 kill -9 到 kill -HUP 平滑重啟，再到自動化腳本預檢，體現了運維思維的進化：**預檢優於事後修復，平滑優於強制中斷**。將此腳本納入部署流程，能顯著降低變更風險，保障服務高可用。