????? HTTP 協議本身是“連接 - 請求 - 應答 - 關閉連接”的模式，是一種無狀態協議；然而隨著 web 動態化的需求，我們往往需要把兩次連續的請求關聯起來，從而使得客戶端和服務端的會話變得有狀態。Session 就是滿足這種需求的一種實現方式。
????? 它的基本原理是服務器端為每一個 session 管理一份會話信息數據。而客戶端和服務器端依靠一個全局唯一標示符 —— sessionID 來訪問會話信息數據。當用戶訪問 web 應用時，服務器端會先檢查客戶端的請求里是否包含 sessionID，如果沒有或者檢索不到，服務器端會自動創建一個新的 sessionID，同時開辟數據存儲空間， 并且在本次響應中將 sessionID 返回給客戶端保存。
????? 當服務器端需要開辟數據存儲空間時， 一般會在內存中創建相應的數據結構，但在訪問量非常大的系統中，session 會占用大量的內存空間，而且系統一旦宕掉或者掉電，所有的會話數據就會丟失，這種事故在電子商務網站中會造成嚴重的后果。當然也可以將 session 內容存儲在數據庫中，從而在某種程度上實現持久化，但是這樣會增加 I/O 開銷，影響系統的性能。
在 IBM Websphere Application Server 中提供了兩種不同的 session 持久化管理方案，如圖 1 所示，分別是
1.使用數據庫做 session 持久化管理? 所有的 session 信息被集中存放于數據庫中.
2.內存到內存的復制?? 所有 session 的信息會存放在各個應用服務器的內存中.
?
?
????? 使用數據庫存儲 session 數據時需要對存儲的信息作序列化操作，在某種程度上影響了響應的時間和效率，適用于 session 數據量大，并且對持久化要求比較高的應用場景。在內存到內存的復制方案里，session 管理者可以把最近經常使用的 session 保存在內存里面，極大地降低了獲取 session 數據的時間開銷，從而滿足了對效率和響應時間要求高的應用需求。從內存到內存的 session 復制，一般適用于 session 數據量不大的應用場景。本文將詳細介紹內存到內存復制的持久化管理方案。
內存到內存復制
????? 內存到內存的 session 復制指的是將 sessions 復制到另一個 WebSphere Application Server 上。在這個模式下，sessions 可以被復制到一個或者多個應用服務器上，從而防止 HTTP Session 單點失敗（single point of failure）的發生。
????? Session 復制的目的，是將 session 的信息進行備份保存，以便在服務器發生故障的情況下，session 狀態不會丟失，實現 session 的高可用性，從而保證即使有故障發生，也不會影響到客戶正在進行的業務，避免造成損失，進而提高客戶滿意度。
目前 WebSphere Application Server 提供了三種復制方式（如圖 2 所示）：
- 僅服務器模式： 所謂僅服務器，指的是該應用服務器只會存儲其他應用服務器的 session 備份，而不會把自己創建的 session 分發并復制到其他應用服務器上。
- 僅客戶機模式： 所謂僅客戶機，指的是該應用服務器只會把自身的 session 分發并復制到其他應用服務器上，但不會存儲其他應用服務器的 session 備份。
- 客戶機和服務器模式： 所謂客戶機和服務器，指的是該應用服務器既能作為服務器存儲其他應用服務器的 session 備份，也能作為客戶機把自身的 session 分發并復制到其他應用服務器上。
WebSphere Application Server 默認的是客戶機和服務器模式。用戶也可以根據需要選擇合適的復制模式。目前 WebSphere Application Server 支持兩種 session 復制拓撲結構，分別為：
- 客戶機 / 服務器 (Client/Server)
- 點對點 (Peer-to-Peer)
針對這兩種拓撲結構，我們將在余下的章節中作詳細的介紹。
?
復制域
????? 首先，內存到內存復制功能是通過應用服務器上的數據復制服務實例來實現的，我們要確保這些數據復制服務實例是屬于同一個復制域的，否則這些實例相互間就不能進行復制，從而影響內存到內存復制功能的實現。
如圖 3 所示 , 復制域 Domain1 包含三個成員 Server1，Server2 和 Server3，因此這三個 server 之間能相互進行復制。但是由于 Server4 并不屬于復制域 Domain1 里面的成員，因此 Server4 上的 session 不能復制到復制域 Domain1 的成員上，同時也不能備份 Domain1 上成員的 session 信息。
????? 其次，屬于同一個復制域的所有會話復制都必須具有相同的拓撲結構。如果同一個復制域中的一個會話管理實例使用的是客戶機 / 服務器拓撲結構，則其余所有的會話管理實例只能是“僅服務器”模式或者“僅客戶機”模式。相反，如果有一個會話管理實例使用的是點對點的拓撲結構，則其余 所有的會話管理實例只能被配置成“客戶機和服務器”模式。“僅服務器”模式或者“僅客戶機”模式不能與“客戶機和服務器”模式共存于同一個復制域里面。
在集群環境中，默認采用的是點對點的單備份復制，但是我們也可以在復制域里面修改復制的數量。如圖 4 所示，如果副本數選擇單個副本，那么 session 只會被備份到一個復制域成員上，如果選擇整個域，則 session 就會備份到所有其他復制域成員。當然，我們也可以根據實際需要來指定復制的副本數目。
?
?
內存到內存復制拓撲結構：點對點
????? 圖 5 是一個點對點復制的拓撲結構圖。在這個結構圖中，每一個復制域成員都把 session 的信息保存在自己的內存中。同時它也會把 session 的備份信息發送并保存到其他復制域成員上，同時，它也從其他的復制域成員上獲取 session 的信息。在這種情況下，每個復制域成員既可以作為一個客戶端，從其他的復制域成員上獲取 session 的信息；也可以作為服務端，把自身 session 的信息存儲到其他復制域成員上。也就是說，每個復制域成員的復制模式都是“客戶機和服務器”。
????? 在這種配置方式下，不同的服務端之間的關系是平等的，而且需要最少的服務器進程，因此它代表了最牢固的拓撲結構。尤其當各個節點具有相同的性能（CPU，內存等等）和處理相同數量的工作時，該拓撲結構可以達到最穩定的實施。
點對點復制的拓撲結構的優勢是不需要額外的進程和產品來避免單點失敗，從而減少了配置和維持額外進程或產品的時間和費用的成本。但這個拓 撲結構的局限性就是它需要占用一定的內存空間，因為每個服務端都需要備份這個復制域里所有 session 的信息。假如一個 session 需要 10KB 的空間來存儲信息，那么當 100 萬個用戶同時登陸到這個系統中時，每個應用服務器就需要花費 10GB 的內存空間來保存所有 session 的信息。它的另一個局限性是每一個 session 信息的修改都會被復制到其他所有的應用服務器上，這極大地影響了整個系統的性能。
在 Websphere Application Server V7 開始支持 session 熱故障恢復 (session hot failover) 功能。這個功能只適用于點到點復制模式。在集群環境中，session affinity 會把客戶的所有后續請求分發到同一臺應用服務器上。啟用這一特性之后，如果運行某個實例的服務端突然宕掉，那么 Websphere Application Server plug-in 就會把其后續請求轉發到集群環境中其他合適的服務端上。
????? 對于設置成點到點復制模式的集群來說，這個新特性可以觸發插件程序，從而讓保存這些 session 備份的復制域成員來直接接管宕掉的復制域成員的工作，這樣可以減少從另一個復制域成員那里再次獲取 session 備份的開銷。
內存到內存復制拓撲結構：客戶機 / 服務器
????? “客戶機 / 服務器”拓撲就是把集群中的復制域成員分別設置成“僅服務器”模式或者“僅客戶機”模式。這種拓撲可以把備份數據和本地數據分離開來，所有“僅客戶機”成 員共享“僅服務器”成員上 session 備份，減少了單個復制域成員的復制開銷。拿“僅客戶機”成員來說，它就不用再負責為別的成員進行 session 備份，可以有更多的資源來運行業務；而對于“僅服務器”成員來說，它只負責備份 session，不需要處理業務，其上不需要部署任何應用程序。
圖 6 描述的就是“客戶機 / 服務器”拓撲結構。
????? 這種拓撲結構的優勢是它明確區分了客戶機和服務器的角色。“僅服務器”成員將所有的 session 信息保存在內存中，而“僅客戶機”成員專門處理業務。這樣可以減少每個客戶機的內存開銷和性能影響。
所有“僅客戶機”成員可以共享“僅服務器”成員，當有“僅服務器”成員且數據有多余兩個以上的備份時，就可以實現故障恢復的目的。
在實際操作中，我們推薦使用多個備份服務器從而減少單點錯誤的發生。
?
兩種復制拓撲的比較
????? 在前面兩個章節中，我們分別介紹了點到點和客戶機 / 服務器兩種復制拓撲結構的原理及其優勢和局限性，在本章節中，我們將進一步比較這兩種復制拓撲。
對比條目 客戶機 / 服務器 點對點| 定義 |
通常來說，使用這種方式，是為了在 session 副職的情況下更好地保持 session affinity。在這種拓撲結構中，
|
缺省設置。每個復制域成員可以：
|
| 設置方法 | 每個復制域成員的復制方式，要么是“僅服務器”，要么是“僅客戶機”。 | 所有復制域成員的復制方式是“客戶機和服務器” |
| 復制域中各節點復制功能 | 每一個復制域成員，要么僅作為服務器，只為別的成員存儲 session 備份，要么僅作為客戶機，把自己的 session 發到服務器段進行備份。 | 每一個復制域成員既把自己的 session 發給其他所有成員進行備份，同時又為其他所有成員備份 session。 |
| 復制的方向性 | 成員到成員的 session 復制是單向的 | 成員到成員的 session 復制是雙向的 |
| 局限性 | 需要額外的服務器單獨作為復制服務器。需要先啟動所有復制服務器，在啟動復制客戶機，這樣才能保證客戶機上的所有 session 都被成功復制到服務器上。 | 某一時刻，每個復制域中必須至少有兩個活動的復制域成員，才能保證 session 的點對點復制正常進行。如果成員只有 1 個，沒法進行點對店的復制。 |
Session 問題診斷
????? 在實際應用中，管理員可以通過啟動 DebugSessionCrossover 來查看每個復制域成員上 session 的信息，可以查看到該成員上針對每個應用的 session 統計信息。啟動該功能的步驟如下：
點擊 服務器 > 應用程序服務器 > 《服務器名字》 > Web 容器設置 > Web 容器 > 定制屬性 > 新建
在相應的屬性里填寫如圖 7 所示的值，然后點擊確定。
圖 7. 啟動 DebugSessionCrossover 檢測
通過啟動該功能，管理員就可以通過訪問 URL：http://<hostname>:<portnumber> /<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug? 來查看具體 session 信息，如清單 1 所示：
| Session Tracking Internals J2EE NAME(AppName#WebModuleName):: tri-ear#tri-web.war cloneId : 15fm7sgs8 Number of sessions in memory: (for this webapp) : 9 Invalidation alarm poll interval (for this webapp) : 126 Max invalidation timeout (for this webapp) : 1800 Using Cookies : true Using URL Rewriting : false use SSLId : false URL Protocol Switch Rewriting : false Session Cookie Name : JSESSIONID Session Cookie Comment : SessionManagement Session Cookie Domain : Session Cookie Path : / Session Cookie MaxAge : -1 Session Cookie Secure : false Maximum in memory table size : 1000 current time : Thu Oct 28 15:26:29 GMT+08:00 2010 integrateWASSec :true Session locking : false Sessions Created:9 Active Count:0 Session Access Count:3707 Invalidated Sessions Count:0 Invalidated By SessionManager:0 SessionAffinity Breaks:0 Number of times invalidation alarm has run:38 Rejected Session creation requests(overflow off):0 Cache Discards:0 Attempts to access non-existent sessions:27 Number of binary reads from external store:27 Total time spent in reading from external store(ms):0 Total number of bytes read:-27 Number of binary writes to external store:939 Total time spent in writing to external store(ms):63 Total number of bytes wriiten out:-939 Session count 9 No of Replicated Sessions in the backup table(for this server) : 41 Total size of serializable objects in memory :42340 Total number objects in memory :9 Min size session object size:4687 Max size session object size :4826 |
?
????? 在清單 1 里，我們可以看到目前在內存中針對名為 tri-web 的應用的 session 數目為 9，該服務器總共創建了 9 個 tri-web 應用的 session，同時備份表里面的 session 數目是 41。值得注意的是， 內存 (in-memory) 的 session 和備份表 (backup table) 里的 session 過一段時間后就會過時，這些過時的 session 會被服務器刪除，一旦 session 被刪除，以下兩個數據統計值就被清零。
- No of sessions in memory: (for this webapp)
- No of Replicated Sessions in the backup table(for this server)
????? 但是 created session 記錄的是 session 創建的歷史數據，只要服務器沒有被重啟，created session 里的數目只會隨著 session 的創建而不斷增加。
那么如何來診斷復制域成員的 session 復制服務是否正常工作？在下文中，我將分別介紹兩種復制拓撲結構的實際用戶場景，以及如何通過 DebugSessionCrossover 來診斷 session 的復制服務是否工作正常。
????? 某用戶創建了一個集群，該集群包含 3 個應用服務器，這 3 個應用服務器都是屬于同一個復制域，并且該復制域的副本數選擇“整個域”。然后用戶把應用安裝到這 3 個應用服務器上，并且把他們配置成“點對點”復制的拓撲結構。然后用戶不斷發送請求到這些應用服務器上，由于在 WebSphere Application Server 里默認的 session 超時時間為 30 分鐘，為了避免超時以及 session 過期帶來的干擾，我們簡化場景，壓力測試只跑 15 分鐘，壓力測試結束后等候幾分鐘以保證所有 session 處理完畢，最后再通過
http://<hostname>:<portnumber>/<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug?
來查看具體 session 信息。當然用戶也可以通過控制臺來更改 session 超時時間間隔，如圖 8 所示，但是在實際應用中 session 超時時間不宜過長，否則 session 無法及時清除，占用大量內存空間，從而影響服務器的性能。
????? 通過使用 IBMTrackerDebug.Servlet， 我們可以檢查所有復制域成員備份表中的 session 數目，所有復制域成員創建的 session 數目和復制域成員數目，應該滿足如下公式：
所有復制域成員備份表中的 session 數目總和 = 所有復制域成員創建 session 的數目總和 *（復制域成員數 – 1），也就是說，所有服務器創建的 session，在其他所有復制域成員有都有一份備份。
例如在上面的用戶場景中，我們得到如下的統計數據：
３個復制域成員備份表的 session 數目總和為：15+17+16 = 48, 如清單 2 所示 .
| *********************************************************************************** http://sndev03.cn.ibm.com:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 15 http://sndev03.cn.ibm.com:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 17 http://sndev03.cn.ibm.com:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 16 *********************************************************************************** |
?
3 個復制域成員創建 session 的數目總和 *（復制域成員數 – 1）= （9+7+8）*（3-1）=48, 如清單 3 所示 .
| *********************************************************************************** http://sndev03.cn.ibm.com:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 9 http://sndev03.cn.ibm.com:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 7 http://sndev03.cn.ibm.com:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 8 *********************************************************************************** |
?
根據上面的數據，我們可以看到該集群所有復制域成員的 session 復制服務正常工作。
????? 某用戶創建了一個集群，該集群包含 3 個應用服務器，這 3 個應用服務器都是屬于同一個復制域，并且該復制域的副本數選擇“單個副本”。然后用戶把應用安裝到這 3 個應用服務器上，并且把他們配置成“客戶機 / 服務器”復制的拓撲結構。同樣用戶不斷發送請求到這些應用服務器上，一直到壓力測試結束。然后通過
http://<hostname>:<portnumber>/<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug?
來查看具體 session 信息。如果“客戶機 / 服務器”復制拓撲結構滿足如下公式：
復制域成員備份表中的 session 數目總和 = 復制域成員創建 session 的數目總和
那么我們就認為該拓撲下的復制服務正常工作。否則用戶就要重新檢查自己的配置是否正確。
例如在上面的用戶場景中，我們得到如下的統計數據：
３個復制域成員備份表的 session 數目總和為：20+21+17 = 58, 如清單 4 所示 .
清單 4. 客戶機 / 服務器復制域成員備份表的 session 數目
| *********************************************************************************** http://sndev03.cn.ibm.com:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 20 http://sndev03.cn.ibm.com:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 21 http://sndev03.cn.ibm.com:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 17 *********************************************************************************** |
?
3 個復制域成員創建 session 的數目總和 =18+20+20 = 58, 如清單 5 所示 .
清單 5. 客戶機 / 服務器復制域成員創建的 session 數目
| *********************************************************************************** http://sndev03.cn.ibm.com:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 18 http://sndev03.cn.ibm.com:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 20 http://sndev03.cn.ibm.com:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 8 *********************************************************************************** |
?
????? 根據上面的數據，我們可以看到“客戶機 / 服務器”的復制拓撲工作正常。
????? 值得注意的是，以上兩個公式的使用都具有一定的局限性。它不適用于存在 session 過期的場景，因為 session 經常會過期，根據 session 復制原理，對于過期的 session，其備份也會被從其他復制域成員上刪除，而這中間，復制域成員之間通信會有一定的延遲，所以造成某一時刻，這個公式不再適用。
?
?
結束語
????? 本文主要介紹了在 WebSphere Application Server 集群環境下如何通過內存到內存的兩種復制拓撲有效地管理 HTTP session。并對兩種拓撲使用以及各自的優勢和局限性作了進一步的闡述。最后，本文以示例的方式，向讀者分享如何通過 DebugSessionCrossover 來查看復制域成員上的 session 統計信息。實際使用中，用戶需要根據需要，選擇合理的復制拓撲，從而達到其業務需求。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
