首先介紹一下負載均衡和session，並且以Nginx和session為例：

1.負載均衡

目的是通過反向代理伺服器（Nginx）使得後端的伺服器負載保持均衡，儘量避免某一個後端伺服器過負載，從而影響服務。
Nginx提供的負載均衡策略：
(1)加權輪詢（靜態加權）
(2)當前最小連線數
(3)ip_hash
(4)url_hash（第三方模組）
其中：ip_hash也有不好的地方就是，假如其中的一臺伺服器down掉的話，對映到這臺的伺服器的使用者就無法獲得服務了，並且很難做到負載均衡。

2.Session保持

可以發現一個問題：
通過輪詢的方式，不能保證同一個使用者的或者同一個ip的使用者能夠固定的訪問的某個後端伺服器上；但是ip_hash很難做到像輪詢那樣的負載均衡。

先說一下session和cookie為何物：
session 是一個抽象概念，開發者為了實現中斷和繼續等操作，將 user agent 和 server 之間一對一的互動，抽象為“會話”，進而衍生出“會話狀態”，也就是 session 的概念。而 cookie 是一個實際存在的東西，http 協議中定義在 header 中的欄位。
而我們今天常說的 “session”，是為了繞開 cookie 的各種限制，通常藉助 cookie 本身和後端儲存實現的，一種更高階的會話狀態實現。具體到實現，session 因為 session id 的存在，通常要藉助 cookie 實現，但這並非必要，只能說是通用性較好的一種實現方案。並且session真的是什麼物件都可以儲存的。

負載均衡進行請求分發的時候保證每個客戶端固定的訪問到後端的同一臺應用伺服器。例如：從登入＝》拍得東西＝》新增地址＝》付款，這是一個一系列的過程，也可以理解成一次操作過程，所有這一系列的操作過程都應當由一臺伺服器完成，而不能被負載均衡器分配到不同的伺服器上。
會話保持都會有時間的限制（對映到固定某一臺的伺服器除外，如：ip_hash）；這樣可以減少需要同步session的情況，但是不能杜絕。所以session同步/共享還是要做的。

3.Session同步/共享

在做了web集群后，首先考慮session同步問題，因為通過負載均衡後，同一個IP訪問同一個頁面會被分配到不同的伺服器上，如果session不同步的話，一個登入使用者，一會是登入狀態，一會又不是登入狀態。所以本文就根據這種情況給出三種不同的方法來解決這個問題：

1.粘性session

通過會話標識是應用層的資訊，那麼負載均衡裝置要將同一個會話請求都儲存到同一個web伺服器上。
缺點：
(1)就要進行應用層的解析，這個開銷比在傳輸層大。
(2)此時，負載均衡器變成了一個有狀態的節點，要將會話儲存到具體web伺服器的對映，和無狀態的節點相比，記憶體更大，容災更麻煩。

2.伺服器之間做同步：

如果做過資料庫讀寫分離的都該知道，讀寫分離的時候，其實讀的是從庫，寫的是主庫，但是主庫的資訊會更新到從庫，不考慮讀寫時間，我們可以認為從庫和主庫的資料是一致的，這個一致性主要靠同步來實現的。
在處理session的時候，我們同樣可以採用這樣的策略，在負載均衡裝置上，無需動任何手腳，只進行無狀態分發，反正分發到哪個伺服器上，我之前的session都有，木事。
缺點：
(1)同步session造成了網路頻寬的開銷，只要session資料有變化，就需要將資料同步到其他伺服器上，機器越多，同步帶來的網路開銷就越大。
(2)每臺web伺服器都要儲存所有的session資訊，如果整個叢集的session資料很多，每臺應用伺服器就會儲存非常多的session資料，嚴重佔用記憶體。

3.利用redis共享session

既然嫌棄同步麻煩，那就把所有的session資料都拿出來，放到單獨的地方，可以是單獨資料庫，或其他分散式儲存系統，前面負載均衡器還是無狀態轉發，應用伺服器每次讀寫session,都到相同的地方來取。
他可以把web伺服器中的記憶體組合起來，成為一個大記憶體，不管是哪個伺服器產生的sessoin都可以放到這個”大記憶體”中，所有其他伺服器的都可以使用。
優點：
以這種方式來同步session，不會加大資料庫的負擔，並且安全性比用cookie大大的提高，把session放到記憶體裡面，比從檔案中讀取要快很多。
缺點：
(1)讀寫session資料引入了網路操作，這相對於本機的資料讀取來說，問題就在於存在延時不穩定性，但是考慮到應用伺服器跟session儲存裝置的通訊均發生在內容，so,take it easy!
(2)如果集中進行session儲存，就要考慮到當session伺服器發生問題的時候，會影響我們整個鏈條的使用。

4.利用cookie同步session ：

就是把使用者訪問頁面產生的session放到cookie裡面，就是以cookie為中轉站。你訪問web伺服器A，產生了session把它放到cookie裡面了，你訪問被分配到web伺服器B，這個時候，web伺服器B先判斷伺服器有沒有這個session，如果沒有，在去看看客戶端的cookie裡面有沒有這個session，如果也沒有，說明session真的不存，如果cookie裡面有，就把cookie裡面的sessoin同步到web伺服器B，這樣就可以實現session的同步了。
缺點：
cookies長度限制：因為cookie可以攜帶的資料長度是有限制的；
安全性：可以加密，但是還是可以偽造；
頻寬消耗；
效能：每次http的請求跟響應都帶有session資料，影響併發效能；因為對web伺服器來說，在同樣的情況下，響應的結果輸出越少，支援的併發請求越多。