台灣的Web工程師

如何共有Session

我們在上方有談到Session層級，如果使用者忘了的話，再回去看一下。Session儲放的位置，是由伺服器來決定的，所以如果想要共有各台機器上的Session，可以想到有二種方式：

1. 變更伺服器存取Session的設定。

2. 自行設計共有Session機制。

我們先來討論第一種方式，下方說明幾種變更伺服器存取Session的方式：

Cluster（叢集）

Cluster（叢集）的意義，其實就是將多台相同功能的機器，連在一起，來服務或處理更大量的需求。其實我們目前已經將Server1增加到Server5了，只是差在沒有將它們「連在一起」。

通常叢集的功能，都是由伺服器的程式提供的，我們要做的是只透過一些設定，來讓它們「連在一起」；所以首先需要做的，是需要瞭解讀者目前所使用的伺服器程式，有沒有提供「叢集」功能，如果有的話，它同時會也提供設定的方法，所以我們只要照著設定的文件來做，就可以將這五台Server「連在一起」。當所有的設定都成功的時候，就已經達到「共有Session」的目的了，因為「叢集」功能的其中之一，就是「共有Session」。

利用3th Party提供的機制

Session的本身就是一堆資料，下圖是將Session物件序列化後的結果。

可以看到最左邊的欄位是Session的ID，它是唯一值，最右邊的欄位則是Session的資料。

瞭解Session的內容與功用後，接下來的需要的，就是要可以快速的存取Session；簡單地說我們需要能達成下列功能的第三方服務或套件：

1. 能儲存文字資料即可。

2. 能快速的存取資料。

目前已有Memcached、AWS dynamoDB之類的程式，都能達成這二項要求，而且在網路上也都可以找到相關資料，只要透過簡單的設定，即可達成「共有Session」機制；或者是有相關的Liabary可以使用，利用這些套件，再透過簡單的設定，也可以達到我們的目標。

自行設計共有Session機制

共有Session的第二種方式－自行設計。這部份的話，其實原理其實很簡單，首先我們已經瞭解「共有Session」的內容了，所以基本上就是先找到一個每台機器都可以存取的地方，例如：資料庫；接著只要瞭解Session的使用時機，就能自行設計了。

至於時機的話，以下列四個時機點為主：

1. Session建立的時機。

2. Session消滅的時機。

3. Session資料變更的時機。

4. 取出Session資料的時機

以筆者熟悉JAVA為何例，要監聽上方的前三個時機，必須實作（implements）二個程式，

1. javax.servlet.http.HttpSessionListener

2. javax.servlet.http.HttpSessionAttributeListener

實作這二個程式即可監聽前三種時機，再利用序列化與反序列化的方式，完成物件與文字的轉換，最後在web.xml中宣告listener，這樣即可完整處理前三種時機；不過第四種：

取出Session資料的時機

就無法處理了，目前想到最快速的方式，就是利用Filter，在每一次的Request中去取得Session資料。

除此之外，大家也可以參考各自的Server是否有提供Session的客製化處理，例如tomcat中，有一個manager可以客製化Session的處理，可參考網頁：

1. https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html

2. https://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/Manager.html

實作這些方法，即可不需要變更程式，即可「自行設計Session共有」，下方是AWS利用DynamoDB配合tomcat實作出來的Session共有處理：

http://docs.aws.amazon.com/java-sdk/latest/developer-guide/java-dg-tomcat-session-manager.html

假設我們選擇了利用Memcached的機制，來達成共有Session的目標，則我們目前的大構架會如下方的圖所示：

共享Session與程式的變更

瞭解了整個Load Balance與Session的關係後，回到程式設計的角度上來看：

• 共有Session的處理（視情況可能不需變更程式）。

• 只要注意程式沒有使用到Application層級的資料，或確定每一台Application層級的資料都是相同即可，程式不需要特地變更。