分布式伺服器中的Session（會話）管理

Session是使用者使用網站服務過程中一個十分重要的資料對象，它是用戶端與伺服器進行互動的基礎資料，如果在互動過程中出現錯誤，可能會導緻十分嚴重的後果，是以會話管理在大型分布式網站中是十分重要的一個子產品。

那麼如何才能實作高可用的會話管理呢？

Session Replication（會話複制）

如果是整個應用單台伺服器的話，會話複制貌似用處不是很大，因為單台伺服器挂了，會話再留着也沒什麼卵用了，但是多台伺服器的話，就因為其中一台伺服器當機，導緻使用者需要重新連接配接會話，那這個體驗就大大減分了。

這時候會話複制就派上了大用場，當一個用戶端連接配接到一台伺服器的時候，這時候會話資料同時也産生了，為了避免上述出現的場景，那麼在沒有當機前，就做一下會話複制的工作，即将此會話資料複制到每一台伺服器上，每一台伺服器都存留一份副本，這時候如果其中一台當機了，可以切換到另外一台伺服器繼續工作，實作了高可用的目的。

但是會話複制也有它的缺陷，就是當使用者使用高峰期的時候，伺服器之間需要複制大量的session資料，這時候伺服器就有些吃不消，甚至會出現記憶體不夠的情況。

Session Tricky（會話粘滞）

會話粘滞的思想跟源位址哈希法有點類似，它的思想就是用戶端發過來的請求都發送到一台伺服器上，比如利用Session對象的HashCode，然後根據HashCode再去決定要把這個會話放在哪台伺服器上，這一步可以用

serverPosition=hashCode%serverSize

來解決。這樣具有相同

serverPosition

的會話就全部放在一台伺服器上。

但這種方法也有一個緻命的問題，那就是如果一台伺服器挂了，那這台伺服器上的會話集合就全挂了，用這種方法去實作高可用，那風險還是大大滴。

利用Cookie儲存Session

以上兩種方法出現的Session丢失，說到底是因為Session隻儲存在了記憶體中，記憶體一出錯，大家一起玩兒完。我們可以這麼考慮，如果Session能夠像其他資料一樣能夠持久化到硬碟上，那這個問題不就解決了麼，這樣做無非就是讀取速度沒直接從記憶體中找那麼爽罷了。

有了這個想法以後，我們可以想到Cookie不就是這樣的想法麼，這玩意兒不就保留了一些網站的緩存資料麼，那好，既然有現成的車，那我們就搭一趟了，我們可以把Session資料臨時儲存在Cookie中，如果出現當機，下次再讀取的時候，依然還是存在的。

但是這種方法也有它的缺點，基本也就是Cookie本身的缺點：Cookie本身大小受限制，Cookie的安全性一直也是個老話題，還有就是帶寬消耗和性能影響。

終極利器——Session伺服器

上面幾種方法無論是誰，要是真想達到高可用，貌似還是差那麼點，那麼單獨搞一個Session伺服器，以上這些問題就迎刃而解了。

首先、Session伺服器與其他伺服器隔離，所有與Session相關的操作（複制，粘滞）隻在Session伺服器上折騰，不會影響其他伺服器的資源使用。

第二、Session伺服器可以做分布式會話緩存（如memcache，ActiveMQ），如果需要持久化可以利用類似Redis這樣的産品，使其符合Session的使用要求。