Session 的瓶頸與解決方法

在 Session 的使用 這篇最後面提到了當 PHP server 超過一台時會有問題，這有蠻多的解法，不同的解法偏重在解決不同的問題。

第一種解法是修改 PHP Session 存放目錄，指到 NFS 路徑上，這樣就不會有在 web1 登入後 web2 讀不到的問題。這個在 交大資工 的 PHP server 就是這樣做，這樣做很明顯的優點是「簡單」，缺點就是 NFS 效率與穩定性的問題，不過對於小量的網站來說其實還不錯，因為第一次擴充時的瓶頸通常都是先出現在前端的 PHP server 上，NFS 的效率反而不是重點。

第二種解法則是透過 memcached 來放，這種方法通常都是因為 NFS 效率影響太大，或是覺得 NFS 的穩定性不夠，把 NFS 換成 memcached 希望能解決掉這個問題。這個作法需要利用 session_set_handle() 設定自己寫 (或是網路上抓來的) 程式碼將 Session 資料丟到 memcached 裡。另外一個方案是 Mohawk Software Session Handler Functions，沒有實際用過，不過看起來也是這一類的方案。

第三種解法是透過密碼學的方式將資料放在使用者端。如果資料不敏感 (像是只有使用者的 username)，就透過 HMAC 簽，然後在使用者的瀏覽器上設 Cookie 紀錄，其他的頁面就可以利用 HMAC 檢查是不是自己簽的。如果資料比較敏感，不方便給使用者看到，那麼先透過 Cipher 加密後再用 HMAC 簽，然後再塞到使用者端瀏覽器的 Cookie。這種方式的好處是 Server 端是處於 Stateless 的狀態，這種方式等於完全不需要在 Server 端存資訊。但缺點就是 HMAC 與 Cipher 用的 key 如果外洩就糟糕了。

第四種解法是透過硬體或是某些特定的 Reverse Proxy 解決 Load Balance 時 Session 所產生的問題，簡單來說就是某個 Cookie 一樣就會導到後端一樣的機器 (在這個例子裡是 PHPSESSID)，於是後端就可以用最原始的 /tmp 來放 Session 資料。

這四種解法都有優缺點，並沒有哪個絕對比較好或是比較差，好壞要看使用的環境而定。