PHP session 獨占鎖是否有超時設置?

最近在開發(fā)過程中遇到一個不明白的問題, 查了很久沒有思路, 想請教各位大佬.
公司這邊使用PHP的session的存儲介質是memcached, 架構是php-fpm和nginx.
場景描述:
當用戶一個請求執(zhí)行很慢且使用了session_start()并且沒有釋放session資源的情況下, 如果此時該用戶下一個請求又發(fā)送過來, 由于session獨占鎖的原因, 該用戶的第二次請求將會等到第一次請求將session釋放后才能執(zhí)行或者腳本等待導致超時被fpm的master進程kill掉.
那么問題來了, 我發(fā)現(xiàn)在上述這種情況下, 用戶的第二個請求并不會一直等待上一個請求釋放session, 而是經過幾秒后, 代碼里$_SESSION['name']會返回null.
詭異bug
這種情況就很容易讓我想到日常瀏覽網頁會出現(xiàn)一個詭異bug: 假設我的某個操作會執(zhí)行較久, 而在該請求完成前我又發(fā)起多個請求, 如果網站需要通過session驗證我的身份, 那么后面的幾次請求很可能被判斷為我未登陸 (原因 : 前一個請求未完成, session被占用, 后面的請求獲取session中信息的時候,session返回為null) 而拒絕請求.這不是很嚴重的一件事情嗎? 但是日常中好像并沒有遇到誰家的網站出現(xiàn)過這種問題.
請教大家
我想請教大家, 這個獨占鎖是否真的會導致后面的請求獲取不到session(返回為null值)?
我如何判斷是用戶真的沒登陸還是由于用戶上一個請求占用著session資源導致的返回null?
事實上并不像網上說的那樣腳本會一直等待之前的請求釋放session, 而是經過某段時間就返回null, 那么有哪些參數(shù)可以控制這個獨占鎖超時, 如果超時就返回null?(是否將這個超時時間設置無限大就可以避免剛才提到的日常瀏覽網頁的詭異bug?)

回答

編輯回答

妖妖

如果你正在使用PHP的memcached擴展，你可以將memcached.sess_locking設置為“off”，來避免session鎖。
文件的話參考手冊：

<?php
// 如果確定不修改會話中的數(shù)據(jù)，
// 我們可以在會話文件讀取完畢之后立即關閉它
// 來避免由于給會話文件加鎖導致其他頁面阻塞
session_start([
    'read_and_close'  => true,
]);

memcached擴展的鎖實現(xiàn)：

2017年1月21日 20:10

編輯回答

陌上花

很有意思的問題。

我查了下資料，先簡單整理一下吧，有時間我再詳細分下，結果會在這個答案上更新。

PHP 的 session 核心操作是 Storage，默認是 file，還有大家熟知的 memcached、redis，甚至 mysql或者其他任意的存儲結構，只要符合 php 對 Session Storage 的要求即可，具體設置是 session_set_save_handler() 配置即可。

然后題主使用的是默認的，即 file 存儲結構。

有了這個前提，我們再看session_start()主要都做了些什么。
1.如果沒有 session_id，則在save_path下創(chuàng)建一個 session 文件，并返回給你一個新的 session_id
2.如果有 session_id，則從 session 文件中獲取到對應的 session 信息，并填充到 $_SESSION 中

這樣問題就來了，并發(fā)問題會導致臟寫、讀的問題，所以 PHP 對 session 信息加了排它鎖，以保證 session 信息的正確性。但這樣會阻塞請求，導致性能下降。

在 PHP5 可以使用session_write_close()手動釋放鎖。
在 PHP7 可以直接在初始化的時候設置自動釋放鎖 session_start(['read_and_close' => true,]);。

因此，可以在會話數(shù)據(jù)沒有變動的時候，避免不必要的文件鎖。

關于題主的超時，F(xiàn)ile Storage 底層是 flock 實現(xiàn)的鎖機制。
flock 實現(xiàn)排他鎖
php 封裝的 flock

現(xiàn)在 redis 和 memcached 都已經支持 session 鎖了。

2017年9月7日 12:46