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

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

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

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

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

?

?

圖 1. session 持久化管理方案

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

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

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

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

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

• 僅服務(wù)器模式： 所謂僅服務(wù)器，指的是該應(yīng)用服務(wù)器只會(huì)存儲(chǔ)其他應(yīng)用服務(wù)器的 session 備份，而不會(huì)把自己創(chuàng)建的 session 分發(fā)并復(fù)制到其他應(yīng)用服務(wù)器上。
• 僅客戶機(jī)模式： 所謂僅客戶機(jī)，指的是該應(yīng)用服務(wù)器只會(huì)把自身的 session 分發(fā)并復(fù)制到其他應(yīng)用服務(wù)器上，但不會(huì)存儲(chǔ)其他應(yīng)用服務(wù)器的 session 備份。
• 客戶機(jī)和服務(wù)器模式： 所謂客戶機(jī)和服務(wù)器，指的是該應(yīng)用服務(wù)器既能作為服務(wù)器存儲(chǔ)其他應(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)
• 點(diǎn)對(duì)點(diǎn) (Peer-to-Peer)

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

?

復(fù)制域

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

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

圖 3. session 復(fù)制域

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

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

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

?

?

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

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

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

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

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

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

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

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

????? “客戶機(jī) / 服務(wù)器”拓?fù)渚褪前鸭褐械膹?fù)制域成員分別設(shè)置成“僅服務(wù)器”模式或者“僅客戶機(jī)”模式。這種拓?fù)淇梢园褌浞輸?shù)據(jù)和本地?cái)?shù)據(jù)分離開來，所有“僅客戶機(jī)”成 員共享“僅服務(wù)器”成員上 session 備份，減少了單個(gè)復(fù)制域成員的復(fù)制開銷。拿“僅客戶機(jī)”成員來說，它就不用再負(fù)責(zé)為別的成員進(jìn)行 session 備份，可以有更多的資源來運(yùn)行業(yè)務(wù)；而對(duì)于“僅服務(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)勢(shì)是它明確區(qū)分了客戶機(jī)和服務(wù)器的角色。“僅服務(wù)器”成員將所有的 session 信息保存在內(nèi)存中，而“僅客戶機(jī)”成員專門處理業(yè)務(wù)。這樣可以減少每個(gè)客戶機(jī)的內(nèi)存開銷和性能影響。

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

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

?

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

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

Session 問題診斷

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

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

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

圖 7. 啟動(dòng) DebugSessionCrossover 檢測(cè)

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

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

?

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

• 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ù)目只會(huì)隨著 session 的創(chuàng)建而不斷增加。

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

用戶場(chǎng)景一：“點(diǎn)對(duì)點(diǎn)”復(fù)制拓?fù)浣Y(jié)構(gòu)

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

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

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

圖 8. 更改 session 超時(shí)時(shí)間

????? 通過使用 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ù)制域成員有都有一份備份。

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

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

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

?

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

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

?

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

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

????? 某用戶創(chuàng)建了一個(gè)集群，該集群包含 3 個(gè)應(yīng)用服務(wù)器，這 3 個(gè)應(yīng)用服務(wù)器都是屬于同一個(gè)復(fù)制域，并且該復(fù)制域的副本數(shù)選擇“單個(gè)副本”。然后用戶把應(yīng)用安裝到這 3 個(gè)應(yīng)用服務(wù)器上，并且把他們配置成“客戶機(jī) / 服務(wù)器”復(fù)制的拓?fù)浣Y(jié)構(gòu)。同樣用戶不斷發(fā)送請(qǐng)求到這些應(yīng)用服務(wù)器上，一直到壓力測(cè)試結(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ù)正常工作。否則用戶就要重新檢查自己的配置是否正確。

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

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

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

?

3 個(gè)復(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ù)涔ぷ髡！?

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

?

?

結(jié)束語

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

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