PHP沉思錄-第五篇-Session有效期問題-左輕侯-《程序員》2008年10月號

建立時間：2008-11-09 01:12:09   最後修改時間：2008-11-09 01:12:09  

本文發表在《程序員》雜誌第10期 

PHP沉思錄之五：Session有效期問題 
左輕侯 
2008.9.07 
　　 
Session處理是全部的Web應用都必須面對的問題。PHP中對session有效期的處理，和其餘的解決方案有着很大的不一樣，這是和PHP的工做機制相關的。 
在傳統的client/server應用中，對於session失效的狀況，能夠交給網絡協議本身來處理。不管是client端主動關閉鏈接，仍是由於網絡異常而致使的鏈接中斷，server端都可以獲得通知，觸發鏈接中斷的事件。只要編程響應這一事件，執行指定的操做便可。但對於web應用來講，狀況卻徹底不同。HTTP協議自己是無狀態的，也就是說，每當client/server完成一次請求/響應的過程後，鏈接就會被斷開。在斷開鏈接之後，server並不知道client是否繼續「在線」，還會繼續發送下一次請求。換句話說，不管client端的用戶已經關閉了瀏覽器窗口，仍是用戶僅僅在閱讀當前網頁並準備在下一秒鐘繼續瀏覽，或者用戶由於Windows崩潰/停電/硬盤壞掉/網線被拔/地球爆炸而完全沒法再發送下一個請求，server都一無所知。（在HTTP 1.1中，瀏覽器能夠經過keep-alive參數，來通知server不要在響應請求後主動斷開鏈接，從而實現物理上的長鏈接。可是，這只是爲了提升網絡傳輸的性能而採起的措施，HTTP在邏輯上仍然是無狀態的。）所以，只能經過某種模擬的方式來判斷當前session是否有效。若是某個session在超過一段時間後沒有對server端發出請求，server都會判斷用戶已經「離線」，當前session失效，並觸發鏈接中斷的事件。要作到這一點，server須要運行一個後臺線程，定時掃描全部的session信息，判斷session是否已經超時。 
PHP處理session的原理也不例外，可是在具體的實現方式上，卻不同凡響。這是由於，因爲PHP的工做機制，它並無一個後臺線程，來定時地掃描session信息並判斷其是否失效。它的解決之道是，當一個有效請求發生時，PHP會根據某個機率，來決定是否調用一個GC（Garbage Collector）。GC的工做，就是掃描全部的session信息，用當前時間減去session的最後修改時間（modified date），同配置參數（configuration option）session.gc_maxlifetime的值進行比較，若是生存時間已經超過gc_maxlifetime，就把該session刪除。這是很容易理解的，由於若是每次請求都要調用GC代碼，那麼PHP的效率就會低得使人吃不消了。這個機率取決於配置參數session.gc_probability/session.gc_divisor的值（能夠經過php.ini或者ini_set()函數來修改）。默認狀況下，session.gc_probability = 1，session.gc_divisor=100，也就是說有1%的可能性會啓動GC。 
這三個參數，session.gc_maxlifetime/session.gc_probability/session.gc_divisor均可以經過php.ini或者ini_set()函數來修改。但要記得，若是使用ini_set()函數的話，必須在每個頁面的開始處都調用ini_set()。 
　　這又致使了另一個問題，gc_maxlifetime只能保證session生存的最短期，並不可以保存在超過這一時間以後session信息當即會獲得刪除。由於GC是按機率啓動的，可能在某一個長時間內都沒有被啓動，那麼大量的session在超過gc_maxlifetime之後仍然會有效。固然，發生這種狀況的機率很小，可是若是你的應用對session的失效期要求很精確的話，這會致使很嚴重的問題。解決這個問題的一個方法是，把session.gc_probability/session.gc_divisor的機率提升，若是提到100%，就會完全解決這個問題，但顯然會對性能形成嚴重的影響。另外一個方法是放棄PHP的GC，本身在代碼中判斷當前session的生存時間，若是超出了 gc_maxlifetime，就清空當前session。 
PHP中的session有效期默認是1440秒（24分鐘），也就是說，客戶端超過24分鐘沒有刷新，當前session就會失效。要修改這個默認值，正確的解決辦法是修改配置參數session.gc_maxlifetime。
我曾經在網上搜索過這個問題的解決方式，找到的結果千奇百怪。有的說要設置「session_life_time」，據我知所，PHP中沒有這個參數。有的說要調用session_set_cookie_params，或者設置session.cookie_lifetime，這僅僅用於設置client端cookie的生存時間，換言之，只當client端cookie的生存時間小於server端的session生存期時，修改這個值纔有效，而且最長不能超過server端的session生存期，緣由很簡單，當server端的session已經失效時，client端cookie的生存時間再長也是沒有意義的。還有的說要調用 session_cache_expire，這個參數用於通知瀏覽器和proxy，當前頁面的內容應該被緩存多長時間，和session的生存期並無直接關係。 
聽起來，這種解決方案很完美。可是，當你在實際中嘗試修改session.gc_maxlifetime的值的時候，你極可能會發現，這個參數基本不起做用，session有效期仍然保持24分鐘的默認值。甚至可能出現，在開發環境下工做正常，在服務器上卻無效！ 
爲了完全解決這個問題，須要對PHP的工做細節進行進一步的分析。 
　　在默認狀況下，PHP 中的session信息會以文本文件的形式，被保存在系統的臨時文件目錄中。這個路徑由配置參數session.save_path指定。在Linux下，這一路徑一般爲 mp，在 Windows下一般爲C:WindowsTemp。當服務器上有多個PHP應用時，它們會把本身的session文件都保存在同一個目錄中（由於它們使用同一個session.save_path參數）。一樣地，這些PHP應用也會按必定機率啓動GC，掃描全部的session文件。 
　　問題在於，GC在工做時，並不會區分不一樣站點的session。舉例言之，站點A的gc_maxlifetime設置爲2小時，站點B的 gc_maxlifetime設置爲默認的24分鐘。當站點B的GC啓動時，它會掃描公用的臨時文件目錄，把全部超過24分鐘的session文件所有刪除掉，而無論它們來自於站點A或B。這樣，站點A的gc_maxlifetime設置就形同虛設了。 
找到問題所在，解決起來就很簡單了。在頁面的開始處調用session_save_path()函數，它可以修改session.save_path參數，把保存session的目錄指向一個專用的目錄，例如 mpmyapp。這樣，gc_maxlifetime參數就工做正常了。 
使用公用的session.save_path還會致使安全性問題，由於這意味着，同一臺服務器上的其它PHP程序也能夠讀取你的站點的session文件，這可能被用於黑客攻擊。另外一個問題是效率：在一個繁忙的站點中，可能存在成千上萬個session文件，而把許多不一樣網站的session文件都放在同一個目錄下，不管是對單個文件的讀寫，仍是遍歷全部文件進行GC，都無疑會致使性能的下降。所以，若是你的PHP應用和別的PHP應用運行在同一臺服務器上的話，強烈建議你使用本身的session.save_path。 
嚴格地來講，這算是PHP的一個bug。當PHP在進行GC時，它應該區別來自不一樣站點的session文件，並應用不一樣的gc_maxlifetime值。目前，最新的PHP 5.2.X仍然存在這個問題。 
上文說到，在一個繁忙的站點中，可能存在成千上萬個session文件，即便區分了不一樣站點的session.save_path目錄，單個站點的session文件數目仍然可能致使效率問題。爲了解決這一問題，可行的幾種方法有： 

 若是PHP運行在Linux系統下，使用ReiserFS文件系統取代默認的ext2/ext3文件系統。ReiserFS對於大量小文件的存取性能，比ext2/ext3有極大的提升。 
 將session.save_path指向一個內存路徑。這意味着，session文件的讀寫只在內存中進行，而不執行磁盤操做。 
 session.save_path接受一個額外的N參數，用於指定目錄的級數。例如，「5;/tmp」 將致使建立相似這樣的session文件：/tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。具體的說明，請參見：http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path 
 終極的解決方案，是放棄PHP的session處理機制，本身編碼接管全部的session處理操做，經過session_set_save_handler()函數來實現。經過本身接管session處理，能夠將全部的session保存在專門的數據庫（每每使用內存表）中，從而完全解決session文件帶來的問題，而且能夠方便地實現session的共享和複製。這也是大型的PHP應用通常會使用的方式。關於session_set_save_handler()函數的使用，網上和相關圖書都有詳細的說明，這裏再也不贅述。值得一提的是，即便在這種方式下，啓動GC的機率仍然取決於session.gc_probability/session.gc_divisor。