PHP Session 並發阻塞問題深度解析與解決方案

PHP Session 並發阻塞問題深度解析與解決方案

PHP 預設以檔案儲存 Session，session_start() 會對 Session 檔案加獨佔鎖。同一用戶並發多個請求（如 AJAX 多介面同時載入）時，後續請求會阻塞等待前一請求釋放鎖，導致頁面響應時間疊加。本文深度剖析機制、影響場景，並提供三種解決方案。

阻塞機制圖解

請求 A (耗時 2s)  ──► session_start() [鎖定] ──► 業務邏輯 ──► session_write_close() [釋放] ──► 輸出
請求 B (耗時 1s)  ──► session_start() [阻塞等待] ──► (等待 A 釋放) ──► 執行 ──► 釋放 ──► 輸出
請求 C (耗時 0.5s) ──► session_start() [阻塞等待] ──► (等待 B 釋放) ──► 執行 ──► 釋放 ──► 輸出

總響應時間 = 2 + 1 + 0.5 = 3.5s (串行)
預期並行時間 = max(2, 1, 0.5) = 2s

影響場景

• 單頁面多 AJAX 請求（儀表板、即時通知、分頁載入）。
• 長耗時 API（報表生成、匯出、第三方整合）與普通頁面並發。
• 使用 session_start() 的所有進入點（包含 API、WebSocket 握手）。

方案一：提早釋放鎖 —— session_write_close() (最簡單、零成本)

<?php
session_start();
// 讀取/寫入 Session 資料
$userId = $_SESSION['user_id'];
$_SESSION['last_visit'] = time();

// ✅ 關鍵：業務邏輯開始前釋放鎖
session_write_close();

// 後續耗時操作：資料庫查詢、API 呼叫、檔案處理...
sleep(2); // 模擬耗時操作

echo json_encode(['status' => 'ok', 'user_id' => $userId]);
// ⚠️ 注意：此處已無法再讀寫 $_SESSION
?>

優點：零架構變更、即時生效。
缺點：鎖釋放後無法更新 Session；若後續需寫入，需重新 session_start() (會重新加鎖)。

方案二：改用非阻塞 Session 儲存引擎 (根治)

設定範例 (Redis)：

; php.ini 或 .user.ini
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=yourpass&database=0"
; 或多節點
; session.save_path = "tcp://host1:6379,tcp://host2:6379?weight=1,2"

Redis/Memcached 以鎖機制 (Lua 腳本/GETSET) 實現細粒度鎖，並發效能遠超檔案鎖。

方案三：Session 唯讀/延遲寫入模式 (PHP 7.0+)

<?php
// 唯讀開啟：不加鎖、不更新 last-modified
session_start(['read_and_close' => true]); // PHP 7.0+
// 或
session_start(['lazy_write' => true]);     // PHP 7.0+，僅在 $_SESSION 異動時寫入

// 適用：純讀取用戶身份、權限等不頻繁變更的資料
?>

方案選擇決策樹

1. 能否接受「鎖釋放後不可寫 Session」？ → 是 → 方案一 (最快上線)。
2. 專案已用 Redis/Memcached 做快取？ → 是 → 方案二 (一勞永逸)。
3. 純讀取 Session 且 PHP ≥ 7.0？ → 是 → 方案三 (零程式碼修改，僅調整參數)。
4. 以上皆否 → 評估引入 Redis Session，長期收益最高。

監控與驗證

• 慢查詢日誌：記錄 session_start() 耗時，超過 100ms 即為疑似阻塞。
• 併發測試：ab -n 100 -c 10 -C "PHPSESSID=xxx" https://example.com/api 觀察響應時間分佈。
• Redis INFO：監控 keyspace_hits/misses、expired_keys 確認 Session TTL 運作正常。

Session 並發阻塞是 PHP 高併發效能的隱形殺手，「讀完即釋」或「換引擎」 是兩大核心解法，請根據專案架構成熟度選擇最適策略。