程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> PHP綜合 >> php session的鎖和並發

php session的鎖和並發

編輯:PHP綜合

本文分享PHP的session在使用過程中的鎖和並發的問題,與之相關的現象有請求阻塞、session數據丟失、session數據讀不到。

我登錄不了了
某天,我准備登錄我們一個後台系統,前去解決一個bug,在賬戶密碼驗證碼都准確輸入的情況下,我登錄不上,經過多次實驗發現主要有兩個錯誤信息:

  • csrf驗證失敗
  • 驗證碼錯誤【我對碼神起誓我用半角輸入了我看到的驗證碼,且順序一致,無多加字符】

我們的系統
我們的系統是基於phalcon 2.0.8 開發的,如你所見,我們在表單域加入了防止csrf攻擊的域。也啟用了驗證碼。

<input type="hidden" 
  name="{{ security.getTokenKey() }}"
  value="{{ security.getToken() }}"/>
<img src="/login/getCaptcha" id="img-captcha"/> 

我首先對這兩個組件進行查閱,發現他們都是將數據存於session:

# phalcon/security.zep
# Security::getToken()
let session = <SessionInterface> dependencyInjector->getShared("session"); 
session->set(this->_tokenValueSessionID, token); 
$this->session->set('admin_get_captcha_action', $captcha);

然後我又查閱了我們session的實現,發現是將數據存儲於redis的。

找啊找
什麼問題導致我登錄不上呢?既然是數據驗證上出現問題,就從數據著手吧,我登陸我們測試環境的redis機器,執行 redis-cli monitor,然後走一遍登錄流程,發現輸出如下(意思意思):

  • GET sessionId 
  • GET sessionId 
  • SETEX sessionId 3600 csrf=xxxx 
  • SETEX sessionId 3600 captcha=abcd 

我們可以看到:

1、這裡存在兩次請求,一次是表單加載,一次是生成驗證碼的。
2、存在“並發”的情況,這兩個請求應該是表單加載渲染後才請求驗證碼的,也就是session順序應該是get->set->get->set,看起來怎麼是並發請求了。
3、後面那個SETEX沒有csrf的內容,也就是覆蓋掉前面的數據了
整個世界都不好了,不過也稍微明白是什麼問題了。什麼問題呢,說來話長,要從PHP的session數據的存取說起。

php的session數據的存取
session的數據是經過編碼成字符串存儲在存儲器【file、db、redis、memcache等】的,在我們使用session的時候,是什麼時候去儲存器取數據的?又是什麼時候將數據寫入存儲器的?

這個問題的答案可能和一些朋友想的不一樣,一個請求裡面,PHP只會讀取一次存儲器,在session_start的時候,然後也只會寫入一次存儲器,在請求結束的時候,或調用session_write_close的時候,將數據刷回存儲器,關閉session。

那麼問題來了:

1、如果一個會話,同時出現兩個讀寫session請求,沒有保證獲取1-寫入1-獲取2-寫入2,同時沒有cas版本管理機制的情況下,這些並發請求就會彼此讀取不到對方的寫入,最後寫入的會把前面請求寫入的session覆蓋掉。
2、如果請求是串行的,像登錄頁面的表單和驗證碼,也有可能前面的請求已經輸出內容了,但是session還沒寫入,後面的請求就已經發起了。
鎖與不鎖
解決這種資源的並發一般會通過鎖或版本管理來處理。但是版本管理我看不到好的方法。就聊聊鎖吧。

其實鎖是不大適合,有弊端的。

php的session,默認是用文件存儲的,在打開session的時候,會對文件加獨占鎖,這樣,其它請求就無法獲取鎖了,只能等待直到前面的鎖解了。

這樣保證了 讀取-寫入,讀取-寫入的順序。

其它存儲器,例如mysql,可以借助select for update進行行鎖。redis可以通過一個自增鍵,返回1的獲取到鎖等來實現。

這個實現的話,對數據流來說很理想,但是,對於目前這種頁面大量應用ajax的情況,所有請求排隊處理,將大大加大頁面展現的耗時,甚至出現請求超時等不可用故障。

沒有解決的解決
不建議過多使用session,其一次讀取一次寫入的機制所引發的問題,會造成坑的存在。
在模版渲染前,或請求輸出前調用session_write_close

# 立刻回寫session,避免session覆蓋
$eventManager = $this->view->getEventsManager();
if (!$eventManager) { 
  $eventManager = new Manager();
  $this->view->setEventsManager($eventManager);
}
$eventManager->attach("view:afterRender",function(){
  session_write_close();
});
return $this->view; 
if($login) { 
  # 立刻回寫session,避免session讀取不到
  $eventManager = $this->dispatcher->getEventsManager();
  if (!$eventManager) {
    $eventManager = new Manager();
    $this->dispatcher->setEventsManager($eventManager);
  }
  $eventManager->attach('dispatch:afterDispatchLoop',function(){
    session_write_close();
  });
  return $this->response->setHeader('Location', '/');
}

以上就是關於php session的鎖和並發,希望對大家的學習有所幫助。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved