????? HTTP 協(xié)議本身是“連接 - 請求 - 應(yīng)答 - 關(guān)閉連接”的模式，是一種無狀態(tài)協(xié)議；然而隨著 web 動態(tài)化的需求，我們往往需要把兩次連續(xù)的請求關(guān)聯(lián)起來，從而使得客戶端和服務(wù)端的會話變得有狀態(tài)。Session 就是滿足這種需求的一種實現(xiàn)方式。

????? 它的基本原理是服務(wù)器端為每一個 session 管理一份會話信息數(shù)據(jù)。而客戶端和服務(wù)器端依靠一個全局唯一標(biāo)示符 —— sessionID 來訪問會話信息數(shù)據(jù)。當(dāng)用戶訪問 web 應(yīng)用時，服務(wù)器端會先檢查客戶端的請求里是否包含 sessionID，如果沒有或者檢索不到，服務(wù)器端會自動創(chuàng)建一個新的 sessionID，同時開辟數(shù)據(jù)存儲空間， 并且在本次響應(yīng)中將 sessionID 返回給客戶端保存。

????? 當(dāng)服務(wù)器端需要開辟數(shù)據(jù)存儲空間時， 一般會在內(nèi)存中創(chuàng)建相應(yīng)的數(shù)據(jù)結(jié)構(gòu)，但在訪問量非常大的系統(tǒng)中，session 會占用大量的內(nèi)存空間，而且系統(tǒng)一旦宕掉或者掉電，所有的會話數(shù)據(jù)就會丟失，這種事故在電子商務(wù)網(wǎng)站中會造成嚴(yán)重的后果。當(dāng)然也可以將 session 內(nèi)容存儲在數(shù)據(jù)庫中，從而在某種程度上實現(xiàn)持久化，但是這樣會增加 I/O 開銷，影響系統(tǒng)的性能。

在 IBM Websphere Application Server 中提供了兩種不同的 session 持久化管理方案，如圖 1 所示，分別是

1.使用數(shù)據(jù)庫做 session 持久化管理? 所有的 session 信息被集中存放于數(shù)據(jù)庫中.
2.內(nèi)存到內(nèi)存的復(fù)制?? 所有 session 的信息會存放在各個應(yīng)用服務(wù)器的內(nèi)存中.

?

?

圖 1. session 持久化管理方案

????? 使用數(shù)據(jù)庫存儲 session 數(shù)據(jù)時需要對存儲的信息作序列化操作，在某種程度上影響了響應(yīng)的時間和效率，適用于 session 數(shù)據(jù)量大，并且對持久化要求比較高的應(yīng)用場景。在內(nèi)存到內(nèi)存的復(fù)制方案里，session 管理者可以把最近經(jīng)常使用的 session 保存在內(nèi)存里面，極大地降低了獲取 session 數(shù)據(jù)的時間開銷，從而滿足了對效率和響應(yīng)時間要求高的應(yīng)用需求。從內(nèi)存到內(nèi)存的 session 復(fù)制，一般適用于 session 數(shù)據(jù)量不大的應(yīng)用場景。本文將詳細(xì)介紹內(nèi)存到內(nèi)存復(fù)制的持久化管理方案。

內(nèi)存到內(nèi)存復(fù)制

????? 內(nèi)存到內(nèi)存的 session 復(fù)制指的是將 sessions 復(fù)制到另一個 WebSphere Application Server 上。在這個模式下，sessions 可以被復(fù)制到一個或者多個應(yīng)用服務(wù)器上，從而防止 HTTP Session 單點失敗（single point of failure）的發(fā)生。

????? Session 復(fù)制的目的，是將 session 的信息進(jìn)行備份保存，以便在服務(wù)器發(fā)生故障的情況下，session 狀態(tài)不會丟失，實現(xiàn) session 的高可用性，從而保證即使有故障發(fā)生，也不會影響到客戶正在進(jìn)行的業(yè)務(wù)，避免造成損失，進(jìn)而提高客戶滿意度。

目前 WebSphere Application Server 提供了三種復(fù)制方式（如圖 2 所示）：

• 僅服務(wù)器模式： 所謂僅服務(wù)器，指的是該應(yīng)用服務(wù)器只會存儲其他應(yīng)用服務(wù)器的 session 備份，而不會把自己創(chuàng)建的 session 分發(fā)并復(fù)制到其他應(yīng)用服務(wù)器上。
• 僅客戶機(jī)模式： 所謂僅客戶機(jī)，指的是該應(yīng)用服務(wù)器只會把自身的 session 分發(fā)并復(fù)制到其他應(yīng)用服務(wù)器上，但不會存儲其他應(yīng)用服務(wù)器的 session 備份。
• 客戶機(jī)和服務(wù)器模式： 所謂客戶機(jī)和服務(wù)器，指的是該應(yīng)用服務(wù)器既能作為服務(wù)器存儲其他應(yīng)用服務(wù)器的 session 備份，也能作為客戶機(jī)把自身的 session 分發(fā)并復(fù)制到其他應(yīng)用服務(wù)器上。

圖 2. session 復(fù)制模式

WebSphere Application Server 默認(rèn)的是客戶機(jī)和服務(wù)器模式。用戶也可以根據(jù)需要選擇合適的復(fù)制模式。目前 WebSphere Application Server 支持兩種 session 復(fù)制拓?fù)浣Y(jié)構(gòu)，分別為：

• 客戶機(jī) / 服務(wù)器 (Client/Server)
• 點對點 (Peer-to-Peer)

針對這兩種拓?fù)浣Y(jié)構(gòu)，我們將在余下的章節(jié)中作詳細(xì)的介紹。

?

復(fù)制域

????? 首先，內(nèi)存到內(nèi)存復(fù)制功能是通過應(yīng)用服務(wù)器上的數(shù)據(jù)復(fù)制服務(wù)實例來實現(xiàn)的，我們要確保這些數(shù)據(jù)復(fù)制服務(wù)實例是屬于同一個復(fù)制域的，否則這些實例相互間就不能進(jìn)行復(fù)制，從而影響內(nèi)存到內(nèi)存復(fù)制功能的實現(xiàn)。

如圖 3 所示 , 復(fù)制域 Domain1 包含三個成員 Server1，Server2 和 Server3，因此這三個 server 之間能相互進(jìn)行復(fù)制。但是由于 Server4 并不屬于復(fù)制域 Domain1 里面的成員，因此 Server4 上的 session 不能復(fù)制到復(fù)制域 Domain1 的成員上，同時也不能備份 Domain1 上成員的 session 信息。

圖 3. session 復(fù)制域

????? 其次，屬于同一個復(fù)制域的所有會話復(fù)制都必須具有相同的拓?fù)浣Y(jié)構(gòu)。如果同一個復(fù)制域中的一個會話管理實例使用的是客戶機(jī) / 服務(wù)器拓?fù)浣Y(jié)構(gòu)，則其余所有的會話管理實例只能是“僅服務(wù)器”模式或者“僅客戶機(jī)”模式。相反，如果有一個會話管理實例使用的是點對點的拓?fù)浣Y(jié)構(gòu)，則其余 所有的會話管理實例只能被配置成“客戶機(jī)和服務(wù)器”模式。“僅服務(wù)器”模式或者“僅客戶機(jī)”模式不能與“客戶機(jī)和服務(wù)器”模式共存于同一個復(fù)制域里面。

在集群環(huán)境中，默認(rèn)采用的是點對點的單備份復(fù)制，但是我們也可以在復(fù)制域里面修改復(fù)制的數(shù)量。如圖 4 所示，如果副本數(shù)選擇單個副本，那么 session 只會被備份到一個復(fù)制域成員上，如果選擇整個域，則 session 就會備份到所有其他復(fù)制域成員。當(dāng)然，我們也可以根據(jù)實際需要來指定復(fù)制的副本數(shù)目。

圖 4. 復(fù)制域配置

?

?

內(nèi)存到內(nèi)存復(fù)制拓?fù)浣Y(jié)構(gòu)：點對點

????? 圖 5 是一個點對點復(fù)制的拓?fù)浣Y(jié)構(gòu)圖。在這個結(jié)構(gòu)圖中，每一個復(fù)制域成員都把 session 的信息保存在自己的內(nèi)存中。同時它也會把 session 的備份信息發(fā)送并保存到其他復(fù)制域成員上，同時，它也從其他的復(fù)制域成員上獲取 session 的信息。在這種情況下，每個復(fù)制域成員既可以作為一個客戶端，從其他的復(fù)制域成員上獲取 session 的信息；也可以作為服務(wù)端，把自身 session 的信息存儲到其他復(fù)制域成員上。也就是說，每個復(fù)制域成員的復(fù)制模式都是“客戶機(jī)和服務(wù)器”。

圖 5. 點對點復(fù)制的拓?fù)浣Y(jié)構(gòu)圖

????? 在這種配置方式下，不同的服務(wù)端之間的關(guān)系是平等的，而且需要最少的服務(wù)器進(jìn)程，因此它代表了最牢固的拓?fù)浣Y(jié)構(gòu)。尤其當(dāng)各個節(jié)點具有相同的性能（CPU，內(nèi)存等等）和處理相同數(shù)量的工作時，該拓?fù)浣Y(jié)構(gòu)可以達(dá)到最穩(wěn)定的實施。

點對點復(fù)制的拓?fù)浣Y(jié)構(gòu)的優(yōu)勢是不需要額外的進(jìn)程和產(chǎn)品來避免單點失敗，從而減少了配置和維持額外進(jìn)程或產(chǎn)品的時間和費用的成本。但這個拓 撲結(jié)構(gòu)的局限性就是它需要占用一定的內(nèi)存空間，因為每個服務(wù)端都需要備份這個復(fù)制域里所有 session 的信息。假如一個 session 需要 10KB 的空間來存儲信息，那么當(dāng) 100 萬個用戶同時登陸到這個系統(tǒng)中時，每個應(yīng)用服務(wù)器就需要花費 10GB 的內(nèi)存空間來保存所有 session 的信息。它的另一個局限性是每一個 session 信息的修改都會被復(fù)制到其他所有的應(yīng)用服務(wù)器上，這極大地影響了整個系統(tǒng)的性能。

在 Websphere Application Server V7 開始支持 session 熱故障恢復(fù) (session hot failover) 功能。這個功能只適用于點到點復(fù)制模式。在集群環(huán)境中，session affinity 會把客戶的所有后續(xù)請求分發(fā)到同一臺應(yīng)用服務(wù)器上。啟用這一特性之后，如果運(yùn)行某個實例的服務(wù)端突然宕掉，那么 Websphere Application Server plug-in 就會把其后續(xù)請求轉(zhuǎn)發(fā)到集群環(huán)境中其他合適的服務(wù)端上。

????? 對于設(shè)置成點到點復(fù)制模式的集群來說，這個新特性可以觸發(fā)插件程序，從而讓保存這些 session 備份的復(fù)制域成員來直接接管宕掉的復(fù)制域成員的工作，這樣可以減少從另一個復(fù)制域成員那里再次獲取 session 備份的開銷。

內(nèi)存到內(nèi)存復(fù)制拓?fù)浣Y(jié)構(gòu)：客戶機(jī) / 服務(wù)器

????? “客戶機(jī) / 服務(wù)器”拓?fù)渚褪前鸭褐械膹?fù)制域成員分別設(shè)置成“僅服務(wù)器”模式或者“僅客戶機(jī)”模式。這種拓?fù)淇梢园褌浞輸?shù)據(jù)和本地數(shù)據(jù)分離開來，所有“僅客戶機(jī)”成 員共享“僅服務(wù)器”成員上 session 備份，減少了單個復(fù)制域成員的復(fù)制開銷。拿“僅客戶機(jī)”成員來說，它就不用再負(fù)責(zé)為別的成員進(jìn)行 session 備份，可以有更多的資源來運(yùn)行業(yè)務(wù)；而對于“僅服務(wù)器”成員來說，它只負(fù)責(zé)備份 session，不需要處理業(yè)務(wù)，其上不需要部署任何應(yīng)用程序。

圖 6 描述的就是“客戶機(jī) / 服務(wù)器”拓?fù)浣Y(jié)構(gòu)。

圖 6. 客戶機(jī) / 服務(wù)器復(fù)制的拓?fù)浣Y(jié)構(gòu)圖

????? 這種拓?fù)浣Y(jié)構(gòu)的優(yōu)勢是它明確區(qū)分了客戶機(jī)和服務(wù)器的角色。“僅服務(wù)器”成員將所有的 session 信息保存在內(nèi)存中，而“僅客戶機(jī)”成員專門處理業(yè)務(wù)。這樣可以減少每個客戶機(jī)的內(nèi)存開銷和性能影響。

所有“僅客戶機(jī)”成員可以共享“僅服務(wù)器”成員，當(dāng)有“僅服務(wù)器”成員且數(shù)據(jù)有多余兩個以上的備份時，就可以實現(xiàn)故障恢復(fù)的目的。

在實際操作中，我們推薦使用多個備份服務(wù)器從而減少單點錯誤的發(fā)生。

?

兩種復(fù)制拓?fù)涞谋容^

????? 在前面兩個章節(jié)中，我們分別介紹了點到點和客戶機(jī) / 服務(wù)器兩種復(fù)制拓?fù)浣Y(jié)構(gòu)的原理及其優(yōu)勢和局限性，在本章節(jié)中，我們將進(jìn)一步比較這兩種復(fù)制拓?fù)洹?

Session 問題診斷

????? 在實際應(yīng)用中，管理員可以通過啟動 DebugSessionCrossover 來查看每個復(fù)制域成員上 session 的信息，可以查看到該成員上針對每個應(yīng)用的 session 統(tǒng)計信息。啟動該功能的步驟如下：

點擊 服務(wù)器 > 應(yīng)用程序服務(wù)器 > 《服務(wù)器名字》 > Web 容器設(shè)置 > Web 容器 > 定制屬性 > 新建

在相應(yīng)的屬性里填寫如圖 7 所示的值，然后點擊確定。

圖 7. 啟動 DebugSessionCrossover 檢測

通過啟動該功能，管理員就可以通過訪問 URL：http://<hostname>:<portnumber> /<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug? 來查看具體 session 信息，如清單 1 所示：

清單 1. 服務(wù)器 session 信息示例

?

????? 在清單 1 里，我們可以看到目前在內(nèi)存中針對名為 tri-web 的應(yīng)用的 session 數(shù)目為 9，該服務(wù)器總共創(chuàng)建了 9 個 tri-web 應(yīng)用的 session，同時備份表里面的 session 數(shù)目是 41。值得注意的是， 內(nèi)存 (in-memory) 的 session 和備份表 (backup table) 里的 session 過一段時間后就會過時，這些過時的 session 會被服務(wù)器刪除，一旦 session 被刪除，以下兩個數(shù)據(jù)統(tǒng)計值就被清零。

• No of sessions in memory: (for this webapp)
• No of Replicated Sessions in the backup table(for this server)

????? 但是 created session 記錄的是 session 創(chuàng)建的歷史數(shù)據(jù)，只要服務(wù)器沒有被重啟，created session 里的數(shù)目只會隨著 session 的創(chuàng)建而不斷增加。

那么如何來診斷復(fù)制域成員的 session 復(fù)制服務(wù)是否正常工作？在下文中，我將分別介紹兩種復(fù)制拓?fù)浣Y(jié)構(gòu)的實際用戶場景，以及如何通過 DebugSessionCrossover 來診斷 session 的復(fù)制服務(wù)是否工作正常。

用戶場景一：“點對點”復(fù)制拓?fù)浣Y(jié)構(gòu)

????? 某用戶創(chuàng)建了一個集群，該集群包含 3 個應(yīng)用服務(wù)器，這 3 個應(yīng)用服務(wù)器都是屬于同一個復(fù)制域，并且該復(fù)制域的副本數(shù)選擇“整個域”。然后用戶把應(yīng)用安裝到這 3 個應(yīng)用服務(wù)器上，并且把他們配置成“點對點”復(fù)制的拓?fù)浣Y(jié)構(gòu)。然后用戶不斷發(fā)送請求到這些應(yīng)用服務(wù)器上，由于在 WebSphere Application Server 里默認(rèn)的 session 超時時間為 30 分鐘，為了避免超時以及 session 過期帶來的干擾，我們簡化場景，壓力測試只跑 15 分鐘，壓力測試結(jié)束后等候幾分鐘以保證所有 session 處理完畢，最后再通過

http://<hostname>:<portnumber>/<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug?

來查看具體 session 信息。當(dāng)然用戶也可以通過控制臺來更改 session 超時時間間隔，如圖 8 所示，但是在實際應(yīng)用中 session 超時時間不宜過長，否則 session 無法及時清除，占用大量內(nèi)存空間，從而影響服務(wù)器的性能。

圖 8. 更改 session 超時時間

????? 通過使用 IBMTrackerDebug.Servlet， 我們可以檢查所有復(fù)制域成員備份表中的 session 數(shù)目，所有復(fù)制域成員創(chuàng)建的 session 數(shù)目和復(fù)制域成員數(shù)目，應(yīng)該滿足如下公式：

所有復(fù)制域成員備份表中的 session 數(shù)目總和 = 所有復(fù)制域成員創(chuàng)建 session 的數(shù)目總和 *（復(fù)制域成員數(shù) – 1），也就是說，所有服務(wù)器創(chuàng)建的 session，在其他所有復(fù)制域成員有都有一份備份。

例如在上面的用戶場景中，我們得到如下的統(tǒng)計數(shù)據(jù)：

３個復(fù)制域成員備份表的 session 數(shù)目總和為：15+17+16 = 48, 如清單 2 所示 .

清單 2. 點對點復(fù)制域成員備份表的 session 數(shù)目

?

3 個復(fù)制域成員創(chuàng)建 session 的數(shù)目總和 *（復(fù)制域成員數(shù) – 1）= （9+7+8）*（3-1）=48, 如清單 3 所示 .

清單 3. 點對點復(fù)制域成員創(chuàng)建的 session 數(shù)目

?

根據(jù)上面的數(shù)據(jù)，我們可以看到該集群所有復(fù)制域成員的 session 復(fù)制服務(wù)正常工作。

用戶場景二： “客戶機(jī) / 服務(wù)器”復(fù)制拓?fù)浣Y(jié)構(gòu)

????? 某用戶創(chuàng)建了一個集群，該集群包含 3 個應(yīng)用服務(wù)器，這 3 個應(yīng)用服務(wù)器都是屬于同一個復(fù)制域，并且該復(fù)制域的副本數(shù)選擇“單個副本”。然后用戶把應(yīng)用安裝到這 3 個應(yīng)用服務(wù)器上，并且把他們配置成“客戶機(jī) / 服務(wù)器”復(fù)制的拓?fù)浣Y(jié)構(gòu)。同樣用戶不斷發(fā)送請求到這些應(yīng)用服務(wù)器上，一直到壓力測試結(jié)束。然后通過

http://<hostname>:<portnumber>/<your_app_context_root>/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug?

來查看具體 session 信息。如果“客戶機(jī) / 服務(wù)器”復(fù)制拓?fù)浣Y(jié)構(gòu)滿足如下公式：

復(fù)制域成員備份表中的 session 數(shù)目總和 = 復(fù)制域成員創(chuàng)建 session 的數(shù)目總和

那么我們就認(rèn)為該拓?fù)湎碌膹?fù)制服務(wù)正常工作。否則用戶就要重新檢查自己的配置是否正確。

例如在上面的用戶場景中，我們得到如下的統(tǒng)計數(shù)據(jù)：

３個復(fù)制域成員備份表的 session 數(shù)目總和為：20+21+17 = 58, 如清單 4 所示 .

清單 4. 客戶機(jī) / 服務(wù)器復(fù)制域成員備份表的 session 數(shù)目

?

3 個復(fù)制域成員創(chuàng)建 session 的數(shù)目總和 =18+20+20 = 58, 如清單 5 所示 .

清單 5. 客戶機(jī) / 服務(wù)器復(fù)制域成員創(chuàng)建的 session 數(shù)目

?

????? 根據(jù)上面的數(shù)據(jù)，我們可以看到“客戶機(jī) / 服務(wù)器”的復(fù)制拓?fù)涔ぷ髡！?

????? 值得注意的是，以上兩個公式的使用都具有一定的局限性。它不適用于存在 session 過期的場景，因為 session 經(jīng)常會過期，根據(jù) session 復(fù)制原理，對于過期的 session，其備份也會被從其他復(fù)制域成員上刪除，而這中間，復(fù)制域成員之間通信會有一定的延遲，所以造成某一時刻，這個公式不再適用。

?

?

結(jié)束語

????? 本文主要介紹了在 WebSphere Application Server 集群環(huán)境下如何通過內(nèi)存到內(nèi)存的兩種復(fù)制拓?fù)溆行У毓芾?HTTP session。并對兩種拓?fù)涫褂靡约案髯缘膬?yōu)勢和局限性作了進(jìn)一步的闡述。最后，本文以示例的方式，向讀者分享如何通過 DebugSessionCrossover 來查看復(fù)制域成員上的 session 統(tǒng)計信息。實際使用中，用戶需要根據(jù)需要，選擇合理的復(fù)制拓?fù)洌瑥亩_(dá)到其業(yè)務(wù)需求。

Websphere 集群 Session 內(nèi)存到內(nèi)存復(fù)制