一、session的本質
http協議是無狀態的，即你連續訪問某個網頁100次和訪問1次對服務器來說是沒有區別對待的，因爲它記不住你。
那麼，在一些場合，確實需要服務器記住當前用戶怎麼辦？比如用戶登錄郵箱後，接下來要收郵件、寫郵件，總不能每次操作都讓用戶輸入用戶名和密碼吧，爲了解決這個問題，session的方案就被提了出來，事實上它並不是什麼新技術，而且也不能脫離http協議以及任何現有的web技術。
原理很簡單，假設你訪問網頁時就像逛澡堂，第一次進去你是沒有鑰匙的，這個時候你交了錢服務檯就分配一把鑰匙給你，你走到哪裏都要帶上，因爲這是你身份的唯一標識，接下來你用這把鑰匙可以去打開一個專有的儲物櫃存儲你的衣物，游完泳，你再用鑰匙去打開櫃子拿出衣物，最後離開游泳池時，把鑰匙歸還，你的這次游泳的過程就是一次session，或者叫做會話，在這個例子中，鑰匙就是session的key，而儲物櫃可以理解爲存儲用戶會話信息的介質。
那麼在web server中如何實現session呢？想必看了上面的例子你會很容易理解，主要是解決兩個問題，一個是鑰匙的問題，一個是存儲用戶信息的問題。對於第一個問題，即什麼東西可以讓你每次請求都會自動帶到服務器呢？如果你比較瞭解http協議，那麼答案一目瞭然，就是cookie，如果你想爲用戶建立一次會話，可以在用戶授權成功時給他一個cookie，叫做會話id，它當然是唯一的，比如php就會爲建立會話的用戶默認set一個名爲phpsessid，值看起來爲一個隨機字符串的cookie，如果下次發現用戶帶了這個cookie，服務器就知道，哎呀，剛剛這位顧客來了。
剩下的是解決第二個問題，即如何存儲用戶的信息，服務器知道會話id爲abc的用戶來了，那abc想存儲自己的私人信息，比如購物車信息，如何處理？這個時候可以用內存、也可以用文件，也可以用數據庫了，但有個要求是，數據需要用用戶的會話id即可取到，比如php就默認會把會話id爲abc的用戶會話數據存儲到/tmp/phpsess_abc的文件裏面，每次讀取都要反序列化程序可以理解的數據，寫的時候又需要序列化爲持久的數據格式。
較好理解的描述：
session被用於表示一個持續的連接狀態，在網站訪問中一般指代客戶端瀏覽器的進程從開啓到結束的過程。session其實就是網站分析的訪問（visits）度量，表示一個訪問的過程。
session的常見實現形式是會話cookie（session cookie），即未設置過期時間的cookie，這個cookie的默認生命週期爲瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。實現機制是當用戶發起一個請求的時候，服務器會檢查該請求中是否包含sessionid，如果未包含，則系統會創造一個名爲JSESSIONID的輸出 cookie返回給瀏覽器(只放入內存，並不存在硬盤中)，並將其以HashTable的形式寫到服務器的內存裏面；當已經包含sessionid是，服務端會檢查找到與該session相匹配的信息，如果存在則直接使用該sessionid，若不存在則重新生成新的
session。這裏需要注意的是session始終是有服務端創建的，並非瀏覽器自己生成的。 但是瀏覽器的cookie被禁止後session就需要用get方法的URL重寫的機制或使用POST方法提交隱藏表單的形式來實現。
二、如何實現session的共享？
首先我們應該明白，爲什麼要實現共享，如果你的網站是存放在一個機器上，那麼是不存在這個問題的，因爲會話數據就在這臺機器，但是如果你使用了負載均衡把請求分發到不同的機器呢？這個時候會話id在客戶端是沒有問題的，但是如果用戶的兩次請求到了兩臺不同的機器，而它的session數據可能存在其中一臺機器，這個時候就會出現取不到session數據的情況，於是session的共享就成了一個問題。
1. 基於NFS的Session共享
NFS是Net FileSystem的簡稱，最早由Sun公司爲解決Unix網絡主機間的目錄共享而研發。
這個方案實現最爲簡單，無需做過多的二次開發，僅需將共享目錄服務器mount到各頻道服務器的本地session目錄即可，缺點是NFS依託 於復 雜的安全機制和文件系統，因此併發效率不高，尤其對於session這類高併發讀寫的小文件， 會由於共享目錄服務器的io-wait過高，最終拖累前端WEB應用程序的執行效率。
2. 基於數據庫的Session共享
首選當然是大名鼎鼎的Mysql數據庫，並且建議使用內存表Heap，提高session操作的讀寫效率。這個方案的實用性比較強，相信大家普 遍在 使用，它的缺點在於session的併發讀寫能力取決於Mysql數據庫的性能，同時需要自己實現session淘汰邏輯，以便定時從數據表中更新、刪除 session記錄，當併發過高時容易出現表鎖，雖然我們可以選擇行級鎖的表引擎，但不得不否認使用數據庫存儲Session還是有些殺雞用牛刀的架勢。
3. 基於Cookie的Session共享
這個方案我們可能比較陌生，但它在大型網站中還是比較普遍被使用。原理是將全站用戶的Session信息加密、序列化後以Cookie的方式， 統一 種植在根域名下（如：.host.com），利用瀏覽器訪問該根域名下的所有二級域名站點時，會傳遞與之域名對應的所有Cookie內容的特性，從而實現 用戶的Cookie化Session 在多服務間的共享訪問。
這個方案的優點無需額外的服務器資源；缺點是由於受http協議頭信心長度的限制，僅能夠存儲小部分的用戶信息，同時Cookie化的 Session內容需要進行安全加解密（如：採用DES、RSA等進行明文加解密；再由MD5、SHA-1等算法進行防僞認證），另外它也會佔用一定的帶 寬資源，因爲瀏覽器會在請求當前域名下任何資源時將本地Cookie附加在http頭中傳遞到服務器。
4. 基於Memcache的Session共享
Memcache由於是一款基於Libevent多路異步I/O技術的內存共享系統，簡單的Key + Value數據存儲模式使得代碼邏輯小巧高效，因此在併發處理能力上佔據了絕對優勢，目前本人所經歷的項目達到2000/秒 平均查詢，並且服務器CPU消耗依然不到10%。
另外值得一提的是Memcache的內存hash表所特有的Expires數據過期淘汰機制，正好和Session的過期機制不謀而合，降低了 過期Session數據刪除的代碼複雜度，對比“基於數據庫的存儲方案”，僅這塊邏輯就給數據表產生巨大的查詢壓力。
基於Memcache 的存儲是這幾個方案中推薦選用的！
其它方案依然有其使用的場合，具體選用哪套需要開發人員的根據當前的服務器資源、網站併發壓力等綜合評估。
參考:
http://blog.sina.com.cn/s/blog_5f3d71430100jv7q.html
http://blog.csdn.net/zhuanshenweiliu/article/details/38844741
