重點講講redis方式的 session 共享方式,此方式也是博主推薦方式。
網站業務規模和訪問量的逐步發展,原本由單臺服務器、單個域名的迷你網站架構已經無法滿足發展需要。
此時我們可能會購買更多服務器,并且啟用多個二級子域名以頻道化的方式,根據業務功能將網站分布部署在獨立的服務器上;或通過負載均衡技術 (如:DNS 輪詢、Radware、F5、LVS 等)讓多個頻道共享一組服務器。
OK,頭腦中我們已經構思了這樣的解決方案,不過進入深入開發后新的技術問題又隨之而來:
我們把網站程序分布部署到多臺服務器上,而且獨立為幾個二級域名,由于 Session 受實現原理的局限(php 中 Session 默認以文件的形 式保 存在本地服務器的硬盤),使得我們的網站用戶不得不經常在幾個頻道間來回輸入用戶名、密碼登入,導致用戶體驗大打折扣;另外,原本程序可以直接從用戶 Session 變量中讀取的資料(如:昵稱、積分、登入時間等),因為無法跨服務器同步更新 Session 變量,迫使開發人員必須實時讀寫數據庫,從而增 加了數據庫的負擔。
于是,解決網站跨服務器之間的 Session 共享方案需求變得迫切起來,最終催生了多種解決方案,下面列舉 4 種較為可行的方案進行對比探討:
1、基于 redis 的 Session 共享
redis 是基于內存的一款數據庫,近年來非常火爆,使用人越來越多,基于他的各種類型的操作處理,與 memcache 對比,redis 優勢更大。
php 僅需簡單配置 php.ini 增加 redis 庫即可正常使用。save_handler 參數更改為 redis,在配置上 redis 地址即可。
2. 基于 NFS 的 Session 共享
NFS 是 Net FileSystem 的簡稱,最早由 Sun 公司為解決 Unix 網絡主機間的目錄共享而研發。
這個方案實現最為簡單,無需做過多的二次開發,僅需將共享目錄服務器 mount 到各頻道服務器的本地 session 目錄即可,缺點是 NFS 依托 于復 雜的安全機制和文件系統,因此并發效率不高,尤其對于 session 這類高并發讀寫的小文件, 會由于共享目錄服務器的 io-wait 過高,最終拖累前端 WEB 應用程序的執行效率。
3. 基于數據庫的 Session 共享
首選當然是大名鼎鼎的 MySQL 數據庫,并且建議使用內存表 Heap,提高 session 操作的讀寫效率。這個方案的實用性比較強,相信大家普 遍在 使用,它的缺點在于 session 的并發讀寫能力取決于 Mysql 數據庫的性能,同時需要自己實現 session 淘汰邏輯,以便定時從數據表中更新、刪除 session 記錄,當并發過高時容易出現表鎖,雖然我們可以選擇行級鎖的表引擎,但不得不否認使用數據庫存儲 Session 還是有些殺雞用牛刀的架勢。
4. 基于 Cookie 的 Session 共享
這個方案我們可能比較陌生,但它在大型網站中還是比較普遍被使用。原理是將全站用戶的 Session 信息加密、序列化后以 Cookie 的方式, 統一 種植在根域名下(如:.host.com),利用瀏覽器訪問該根域名下的所有二級域名站點時,會傳遞與之域名對應的所有 Cookie 內容的特性,從而實現 用戶的 Cookie 化 Session 在多服務間的共享訪問。
這個方案的優點無需額外的服務器資源;缺點是由于受 http 協議頭信心長度的限制,僅能夠存儲小部分的用戶信息,同時 Cookie 化的 Session 內容需要進行安全加解密(如:采用 DES、RSA 等進行明文加解密;再由 MD5、SHA-1 等算法進行防偽認證),另外它也會占用一定的帶 寬資源,因為瀏覽器會在請求當前域名下任何資源時將本地 Cookie 附加在 http 頭中傳遞到服務器。
5. 基于 Memcache 的 Session 共享
Memcache 由于是一款基于 Libevent 多路異步 I/O 技術的內存共享系統,簡單的 Key + Value 數據存儲模式使得代碼邏輯小巧高效,因此在并發處理能力上占據了絕對優勢,目前本人所經歷的項目達到 2000/秒 平均查詢,并且服務器 CPU 消耗依然不到 10%。
另外值得一提的是 Memcache 的內存 hash 表所特有的 Expires 數據過期淘汰機制,正好和 Session 的過期機制不謀而合,降低了 過期 Session 數據刪除的代碼復雜度,對比“基于數據庫的存儲方案”,僅這塊邏輯就給數據表產生巨大的查詢壓力。
基于 redis 的存儲是這幾個方案中推薦選用的!
其它方案依然有其使用的場合,具體選用哪套需要開發人員的根據當前的服務器資源、網站并發壓力等綜合評估。