問題
爲了滿足足夠大的應用，滿足更多的客戶，於是我們架設了N臺Web服務器（N>=2），在多臺Web服務器的情況下，我們會涉及到一個問題：用戶登陸一臺服務器以後，如果在跨越到另一臺服務器的時候能夠繼續使用客戶的Session？
1、寫客戶端Cookie的方式
把原來存儲在服務器磁盤上的session數據存儲到客戶端的cookie中去。(一般是把session數據按照自己定義的加密規則（如：採用DES、RSA等進行明文加解密；再由MD5、SHA-1等算法進行防僞認證），加密後後存在cookie中。)
優勢
服務器的壓力減小了，因爲session數據不存在服務器磁盤上，無需額外的服務器資源。根本就不會出現session讀取不到的問題。
劣勢
- 網絡請求佔用很多。每次請求時，客戶端都要通過cookie發送session數據給服務器。要佔用很多帶寬了，成本增高(服務器購買帶寬是一個很大費用)。
- 瀏覽器對cookie的大小個數都存在限制。每個瀏覽器限制是不同的（大概4kb左右）。
- 安全問題，雖然通過了加密，等你不能保證不會被人解密
總結：
這方案不適合高訪問量的情況下，因爲高訪問量的情況下，每次請求瀏覽器都要發送session數據給服務器。一般一個cookie大小2k的樣子。
2、sticky模式(粘性會話模式)
用一種算法(簡單理解爲規則)，什麼機制下session是保存在哪臺服務器下，那麼讀取的時候就按照這種規則去讀取，就能定位到原來的服務器。叫做分發請求，分發到特定的服務器上去，其原理是存session和讀session數據保證都在一臺服務器操作，就不會需要涉及到共享，具體實現方式是通過約定一種分發機制來實現(如Nginx下的ip_hash、Apache下的stickysession等)。
也叫做sticky模式(粘性會話模式)，同一個用戶的訪問請求都被派送到同一個服務器上。
優勢
本地維護Session，不需要做session數據共享了。
劣勢
一臺服務器宕機後，當前Session斷掉。
總結：
本來負載均衡有一個目的就是：當其中一臺機子不可用的時候，會自動分發到可用的機子上去(自動判斷現在要請求的機子是否可用),但此方法一臺服務器出現問題,該服務器下的用戶都不能用了
3、利用數據庫共享Session數據
首選當然是大名鼎鼎的Mysql數據庫，並且建議使用內存表Heap，提高session操作的讀寫效率。
優勢
保存在數據庫中，這種方式的擴展性很強，可以隨意增加WEB而不受影響。放在數據庫裏面安全方面好。
劣勢
- session的併發讀寫能力取決於Mysql數據庫的性能
- 當訪問量大時，每個用戶都要頻繁的訪問session，造成mysql服務器壓力過大
- 由於http是短連接，每次過程是：建立連接(握手)->數據通信->通信結束後結束連接。如果頻繁的這樣子連接後再斷開(每次都會去數據庫查詢session)，性能會非常差。
4、利用NFS共享Session數據
NFS是Net FileSystem的簡稱，最早由Sun公司爲解決Unix網絡主機間的目錄共享而研發。
通過nfs的方式，各個服務器操作session數據的時候，是讀取本地磁盤目錄，但實際上是一個共享網絡文件。各個服務器實際上操作的都是同一個目錄的文件。
優勢
這個方案實現最爲簡單，無需做過多的二次開發，僅需將共享目錄服務器mount到各頻道服務器的本地session目錄即可。
劣勢
缺點是NFS依託於複雜的安全機制和文件系統，因此併發效率不高，尤其對於session這類高併發讀寫的小文件，會由於共享目錄服務器的io-wait過高，最終拖累前端WEB應用程序的執行效率。
5、基於內存（Redis、Memcache）的Session共享
相比較與其他方式，該方式是目前最好的session共享方案
可以將session數據保存在memcached，redis之類內存數據庫中，memcached是基於內存存儲數據的，性能很高，用戶併發量很大的時候尤其合適。
建議使用redis，支持的數據格式比較多、能夠查看在線用戶、數據不容易丟失，支持持久化等
優勢
- 主要是利用內存的數據讀取速度是很快的，與磁盤讀取的速度不是一個數量級的。
- 使用內存存儲：方便統計在線人數，內存的速度比磁盤訪問快、內存數據庫系統能夠控制內存中的過期數據自動失效(剛好符合session過期需要)。