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