session

session簡介

上次咱們說了cookie(http://www.javashuo.com/article/p-tlmdohfp-ko.html)，因爲HTTP的無狀態性，這個cookie至關於大樓保安給進入大樓的人的一張小紙條，一段信息數據，下次進入的時候出示小紙條就能夠了。那麼，保安怎麼去校驗這張紙條呢？怎麼判斷這張紙條是有效的，而不是僞造的，也沒有過時呢？這就要用到session了。

這裏的session，咱們用來表示一次HTTP鏈接和會話，通過校驗以後，留存在服務器端的一些數據，特別是關於用戶的數據。就比如你進入大樓時，在訪客登記表(這裏涉及到session的存儲方式:文件，數據庫，緩存)上登記的信息。登記完了以後，保安大叔給你一段cookie，後續你進入，出示小紙條，保安大叔就去登記表上查，看有沒有小紙條上記錄的信息。那經過什麼去查呢，session_id。這個session_id是在大叔發送小紙條時，經過系統生成的，通常是惟一的，帶有有效期的，它保留在服務器端，也寫入cookie。用session_id一查，看是否有記錄，是否還在有效期。固然還有用token來替代session_id的，本質是同樣的。

session鎖問題

假如咱們遇到一種這樣的狀況，A用小紙條請求進入大樓，保安大叔[1](PHP進程[1])一看，身份沒問題，只是有效期快到了，我給你改一個新的有效期(參考身份證)。這個時候，A的雙胞胎兄弟B用一張如出一轍的小紙條請求進入大樓，另外一個保安大叔[2](PHP進程[2])一查，確實有記錄，身份也沒問題，可是這個記錄正在被保安大叔[1]修改，那如今要不要放行呢？

這就涉及到session讀寫鎖的問題了。

當A請求時，PHP啓動了session_start()表示會話開啓（第一次沒有小紙條）/重用現有會話（有小紙條）。此時，PHP就加上一個讀寫鎖，阻塞（等待），（注意: 這部分鎖住的時間不會計算在PHP的「max_execution_time」配置項的時間內，「max_execution_time」詳見set_time_limit()。），對應的session被鎖定（若是是session文件，在Linux主機上是依靠flock()方法實現的），對session的操做都會先保存在內存中，直到腳本經過session_write_close()或者腳本結束纔會寫入session中，從而釋放鎖。在這鎖未釋放的期間，其餘PHP進程請求的對session的操做，都會等待。

若是不加鎖，A請求作修改，B也同時作修改，最後的結果是總有一我的的修改不生效，被另外一我的的修改覆蓋掉了，致使數據不一致問題。

若是加鎖，也會致使一個問題，對B的校驗必須等待A的釋放或者完成以後才能進行，影響了響應的速度。因此，

涉及到的ajax接口不須要用session的就不session_start()；

不須要寫入session的就在session_start()後直接加入session_write_close()；

須要寫入session的，寫入session後直接加入session_write_close()。

總而言之，能不鎖就不鎖，要鎖的話儘可能壓縮鎖的時間。