相關內容詳情可以查看集群配置文檔
只需將下列信息放入 <Engine>
或 <Host>
元素即可實現(xiàn)集群:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
上述配置啟用了全局(all-to-all)會話復制功能,全局會話復制是指利用 DeltaManager
來只復制會話中的變更(Session Delta,也譯作“會話增量”)。這里說的“全局”是指:會話變更會被復制到集群中的所有其他節(jié)點(指 Tomcat 實例)中。全局復制非常適于小集群,但不建議在大集群(包含很多 Tomcat 節(jié)點)上采用這種方法。另外,值得注意的是,當使用 delta manager
時,它會將變更復制到所有的節(jié)點上,甚至包括那些根本沒有部署該應用的節(jié)點。
為了解決這個問題,你就得使用 BackupManager。它會把會話數(shù)據(jù)復制給一個指定的備份節(jié)點(這種復制也被稱為“配對復制”),而且該備份節(jié)點也一定要部署了相關應用。BackupManager 的缺點在于:不像 DeltaManager 那樣久經(jīng)實踐考驗。
下面是一些重要的默認值。
java.net.InetAddress.getLocalHost().getHostAddress()
(你一定不能廣播 127.0.0.1,這是一個常見錯誤。)ClusterSessionListener
。TcpFailureDetector
和 MessageDispatch15Interceptor
。下面是默認的集群配置:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
稍后,本文檔將更詳細地闡述這部分的內容。
要想在 Tomcat 8 上運行會話復制,需要執(zhí)行以下步驟:
java.io.Serializable
。Cluster
元素。ReplicationValve
。tcpListenPort
。通常 Tomcat 會自行解決這個問題,會在 4000 - 4100 上自動偵測可用的端口。web.xml
含有 <distributable/>
屬性。<Engine name="Catalina" jvmRoute="node01" >
上設定 jvmRoute
屬性。jvmRoute
屬性值必須匹配 workers.properties 中的 worker 名稱。負載均衡可以通過多種技術來實現(xiàn),參看負載均衡部分。
注意:會話狀態(tài)是通過 cookie 來記錄的,所以你的 URL 必須保持一致,否則就會創(chuàng)建一個新會話。
注意:當前如要支持集群,需要 JDK 1.5 或更新版本。
集群模塊使用 Tomcat 的 JULI 日志框架,所以可以通過 logging.properties 文件來配置日志。為了跟蹤消息,你可以啟用 org.apache.catalina.tribes.MESSAGES
鍵上的日志。
在 Tomcat 中,可以使用以下方法中的一種啟用會話復制:
在這一版本的 Tomcat 中,可以使用 DeltaManager
執(zhí)行全局式會話狀態(tài)復制,或者使用 BackupManager
執(zhí)行備份復制,將會話復制到一個節(jié)點上。全局式會話復制這種算法只有在集群較小時才比較有效。對于大型集群,更多使用主從會話復制,將會話存儲到一臺配置了 BackupManager 的備份服務器上。
當前可以使用域名 worker 屬性(mod_jk 版本 > 1.2.8)來構建集群分區(qū),從而有可能利用 DeltaManager 實現(xiàn)更具有可擴展性的集群方案(需要為此配置域的攔截器)。為了在全局性環(huán)境中降低網(wǎng)絡流量,可以將集群分成幾個較小的分組。為不同的分組使用不同的組播地址即能實現(xiàn)這種方案。下圖展示的是一種簡單的配置方案。
DNS 輪詢
|
負 載 均 衡 器
/ \
集群 1 集群 2
/ \ / \
Tomcat 1 Tomcat 2 Tomcat 3 Tomcat 4
值得注意的是,使用會話復制僅僅是集群化的一個基礎方案。關于集群的實現(xiàn),另一個常用的概念是耕種(farming),比如:只需將應用部署到一個服務器上,集群就會將部署分發(fā)到整個集群的各個節(jié)點中。這都是 FarmWarDeployer 所具有的功能(參看 server.xml
中的集群范例)。
下一節(jié)將深入介紹會話復制的工作原理以及配置方式。
通過組播心跳包(heartbeat)建立起成員(Membership)關系,因此,如果希望細分集群,可以改變 <Membership>
元素中的組播 IP 地址或端口。
心跳包中含有 Tomcat 節(jié)點的 IP 地址,以及 Tomcat 用來偵聽會話復制流量的 TCP 端口。所有的數(shù)據(jù)通信都使用了 TCP 協(xié)議。
ReplicationValve
用于查找請求結束的時間,如果存在會話復制,就對該復制進行初始化。只復制會話變更的數(shù)據(jù)(通過在會話上調用 setAttribute
或 removeAttribute
來完成)。
復制的異步與同步模式應該是最值得我們注意的一個特點了。在同步復制模式下,復制的會話通過線纜傳送,重新在所有集群節(jié)點上實例化,這樣才會返回請求。同步和異步是通過 channelSendOptions
標志(整型值)來配置的。SimpleTcpCluster/DeltaManager
組合的默認值是 8,從而是異步。詳情可以參考一下 send flag(overview) 或 send flag(javadoc)。在異步復制過程中,請求不必等到數(shù)據(jù)被復制完畢即可返回。異步復制縮短了請求時間,而同步復制則保證了能在請求返回之前復制完會話。
如果你使用了 mod_jk 而沒有使用粘性會話(sticky session),或者粘性會話由于某種原因而不起作用,或者僅是故障轉移,會話 id 需要修改,因為它之前含有之前 Tomcat 的 worker id(通過 Engine 元素中的 jvmRoute 定義)。為了解決這個問題,就要用到 JvmRouteBinderValve。
JvmRouteBinderValve 將重寫會話 id,以便確保下一個請求在故障轉移后依然能保持粘性(不會因為 worker 不再可用而回滾到某個隨機的節(jié)點中)。利用同樣的名字,該值重寫了 cookie 中的 JSESSIONID 值。假如沒有正確地設置 valve,將使 mod_jk 模塊在失敗后很難保持會話的粘性。
記住,如果在 server.xml 中自定義值,那么默認值將不再有效,所以一定要確保添加了默認所定義的值。
提示:
利用屬性 sessionIdAttribute 可以改變包含舊會話 id 的請求屬性名。默認的請求屬性名是:org.apache.catalina.ha.session.JvmRouteOrignalSessionID。
技巧:
可以啟用 mod_jk 翻轉模式在刪除一個節(jié)點, 然后啟用了 mod_jk Worker 禁用 JvmRouteBinderValves 。這種用例意味著只有請求的會話才能得到遷移。
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
<Manager className="org.apache.catalina.ha.session.BackupManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
mapSendOptions="6"/>
<!--
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
-->
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="5000"
selectorTimeout="100"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
下面來仔細剖析一下這段代碼。
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
Cluster 是主要元素,可在該元素內配置所有的集群相關細節(jié)。 對于 SimpleTcpCluster
類或者調用 SimpleTcpCluster.send
方法的對象,它們所發(fā)出的每一個消息上都附加著一個 channelSendOptions
標志。關于發(fā)送標志的描述可參見我們的 javadoc 文檔。DeltaManager
使用 SimpleTcpCluster.send
方法發(fā)送信息,而備份管理器則直接通過 channel 來發(fā)送自身。
更多詳細信息請參見集群配置參考文檔。
<Manager className="org.apache.catalina.ha.session.BackupManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
mapSendOptions="6"/>
<!--
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
-->
如果在 <Context>
元素中沒有定義 manager,則以上可當做 manager 的配置模板。在 Tomcat 5.x 時期,每個標識為可分發(fā)(distributable)的 Web 應用都必須使用同樣的 manager,而如今不同了,我們可以為每個應用定義一個 manager 類,從而在集群中混合多個 manager。顯然,A 節(jié)點上的某個應用的所有 manager 必須與 B 節(jié)點上的同樣應用的 manager 相同。如果沒有為應用指定
manager,而且該應用被標識為 <distributable/>
,Tomcat 就會采取這種 manager 配置,創(chuàng)建一個克隆該配置的 manager 實例。
更多詳細信息請參見集群管理器文檔。
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
Channel 元素是 Tribes 架構的一個重要組成部分,Tribes 是 Tomcat 內部所使用的分組通信架構。Channel 元素封裝了所有通信相關事項以及成員邏輯。
詳情參見集群 Channel 文檔。
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
成員關系(Membership)是通過組播來實現(xiàn)的。注意,如果你想將成員擴展到組播范圍之外的某個點時,Tribes 現(xiàn)在已經(jīng)能夠支持使用 StaticMembershipInterceptor
的靜態(tài)成員。address
屬性是所用的組播地址,port
是所用的組播端口號。這兩項組合起來將集群隔離開。如果你希望一個 QA 集群和一個生產(chǎn)集群,最簡單的方法就是將 QA 集群的組播地址和端口號不同于生產(chǎn)集群的組播地址和端口號組合。
成員組件將其自身的 TCP 地址和端口廣播到其他節(jié)點處,從而使節(jié)點間的通信都可以通過 TCP 協(xié)議來完成。請注意被廣播的 TCP 地址正是 Receiver.address
屬性值。
詳情參見集群成員文檔。
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="5000"
selectorTimeout="100"
maxThreads="6"/>
在 Tribes 架構中,數(shù)據(jù)的發(fā)送與接收以及被拆分為兩種功能性組件了。正如其名所示,Receiver 負責接收信息。由于 Tribes 與線程無關(其他架構也開始采用這一種常見改進了),該組件內部包含一個線程池,設定有 maxThreads
和 minThreads
兩種參數(shù)。
address
參數(shù)值是主機地址,由成員組件廣播到其他節(jié)點中。
關于更多詳情,可參看Receiver 文檔。
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
Sender 組件負責將消息發(fā)送給其他節(jié)點。Sender 含有一個 shell 組件 ReplicationTransmitter
,但真正所要完成的任務則是通過子組件 Transport
來完成的。由于 Tribes 支持一個 Sender 池,所以消息可以做到同步;如果使用的是 NIO Sender,你也可以并發(fā)地發(fā)送消息。
并發(fā)(Concurrently)意味著將同時有多個發(fā)送者對應著一條消息,并行(Parallel)則意味著同時有多個消息對應著多個發(fā)送者。詳情請參考這篇文檔。
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
</Channel>
Tribes 利用了一個堆棧傳送消息。每個堆棧內的元素都被稱為攔截器,跟 Tomcat 容器中的 valve 的作用差不多。使用攔截器,邏輯可被分成更容易管理的代碼段。上面配置中的攔截器:
TcpFailureDetector
通過 TCP 核實崩潰的節(jié)點。如果組播包丟失,該攔截器就會防止誤報的情況出現(xiàn),比如,某個正在運行的節(jié)點雖然活躍,但也被標示為已崩潰。MessageDispatch15Interceptor
分派消息到線程(線程池),異步發(fā)送消息。ThroughputInterceptor
輸出對信息流量的簡單統(tǒng)計。請注意,攔截器的順序很重要。在 server.xml 中定義的順序正是它們出現(xiàn)在 channel 堆棧中的順序。這種機制就像是鏈表,最前面的是第一個攔截器,末尾的是最后一個攔截器。更多詳細資料,可參看這篇文檔。
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
集群使用 valve 來跟蹤針對 Web 應用的請求。我們之前已經(jīng)提到過 ReplicationValve 和 JvmRouteBinderValve。<Cluster>
元素本身并不是 Tomcat 管道的一部分,集群將 valve 添加到了它的父容器上,比如說 <Cluster>
元素被配置到 <Engine>
元素中,那么 valve 就會被加到 <Engine>
元素中。更多詳情,請參考
集群 valve 配置文檔。
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
默認的 Tomcat 集群支持耕種部署(farmed deployment),比如說集群可以在其他的節(jié)點上部署和取消部署應用。該組件的狀態(tài)目前還不穩(wěn)定,但我們很快就會解決這個問題。Tomcat 5.0 和 5.5 版本相比,在部署算法上有一點變化。組件的邏輯改變到部署目錄必須與應用目錄相匹配。
更多詳情,請參考集群部署器文檔。
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
因為 SimpleTcpCluster
本身既是 Channel 對象的發(fā)送者,又是接受者,所以組件可以將它們自身注冊成SimpleTcpCluster 的偵聽器。 上面這個偵聽器 ClusterSessionListener
將偵聽 DeltaManager
復制的消息,并將會話變更應用到 manager 上,反過來應用到會話上。
更多詳情,參看 集群偵聽器文檔。
組件層級:
Server
|
Service
|
Engine
| \
| --- Cluster --*
|
Host
|
------
/ \
Cluster Context(1-N)
| \
| -- Manager
| \
| -- DeltaManager
| -- BackupManager
|
---------------------------
| \
Channel \
----------------------------- \
| \
Interceptor_1 .. \
| \
Interceptor_N \
----------------------------- \
| | | \
Receiver Sender Membership \
-- Valve
| \
| -- ReplicationValve
| -- JvmRouteBinderValve
|
-- LifecycleListener
|
-- ClusterListener
| \
| -- ClusterSessionListener
|
-- Deployer
\
-- FarmWarDeployer
為了便于理解集群的工作機制,下面將通過一些實際情境來加深一下你的理解,我們只打算采用 2 個 Tomcat 實例:Tomcat A
和 Tomcat B
。具體發(fā)生的事件流程為:
Tomcat A
啟動。Tomcat A
啟動完畢后,Tomcat B
才啟動。Tomcat A
接收一個請求,創(chuàng)建了一個會話 S1
。Tomcat A
崩潰。Tomcat B
接收到對會話 S1
的請求。Tomcat A
啟動。Tomcat A
接收到一個請求,調用會話 S1
上的 invalidate
方法。Tomcat B
接收到一個對新會話 S2
的請求。Tomcat A
會話 S2
由于不活躍而超時。介紹完了事件序列,下面詳細剖析一下在會話復制代碼中到底發(fā)生了什么。
1.Tomcat A
啟動
Tomcat 使用標準啟動順序來啟動。Host 對象創(chuàng)建好之后,會關聯(lián)一個 Cluster 對象。在解析上下文時,如果 web.xml 中包含 distributable 元素,Tomcat 就會讓 Cluster 類(在該例中是 SimpleTcpCluster
)創(chuàng)建復制的上下文的管理器。啟用了集群并在 web.xml 中設置了 distributable 元素后,Tomcat 會為該上下文創(chuàng)建一個 DeltaManager
(而不是 StandardManager
)。Cluster
類會啟動一個成員服務(組播)和一個復制服務(TCP 單播)。下文將會介紹更多的架構細節(jié)。
2.Tomcat B
啟動
Tomcat B 啟動時,采取的順序與 Tomcat A 基本一樣。集群啟動,建立成員(Tomcat A 與 Tomcat B)。Tomcat B 會請求集群中已有服務器(本例中是 Tomcat A)的會話狀態(tài)。如果 Tomcat A 響應該請求,那么在 Tomcat B 開始偵聽 HTTP 請求之前,Tomcat A 會將會話狀態(tài)傳到 Tomcat B那里;如果 Tomcat A 沒有響應該請求,Tomcat 會等待 60 秒,超過這個時間之后,發(fā)出一個日志項。該會話狀態(tài)會發(fā)送到每一個在 web.xml 中設置了 distributable 元素的應用。注意:為了有效地使用會話復制,所有的 Tomcat 實例都必須擁有相同的配置。
3.Tomcat A
接收一個請求,創(chuàng)建了一個會話 S1
Tomcat A 對發(fā)送給它的請求的處理方式,與沒有會話復制時的處理方式完全相同。請求完成時會觸發(fā)相應行為,ReplicationValve
會在響應返回用戶之前攔截請求。如發(fā)現(xiàn)會話已經(jīng)更改,則使用 TCP 將會話復制到 Tomcat B 上。一旦序列化的數(shù)據(jù)被轉交給操作系統(tǒng)的 TCP 邏輯,請求就會重新通過 valve 管道返回給用戶。對于每一個請求,都將復制所有的會話,這樣做就有利于復制那些在會話中修改屬性的代碼,使其即使不必調用 setAttribute
或 removeAttribute
,也能被復制。另外,使用 useDirtyFlag
配置參數(shù)也可以優(yōu)化會話的復制次數(shù)。
4.Tomcat A
崩潰
當 Tomcat A 崩潰時,Tomcat B 會接到通知,得知 Tomcat A 已被移出集群,隨即 Tomcat B 就在其成員列表中也將 Tomcat A 移除,Tomcat B 從而不再收到關于 Tomcat A 的任何通知。負載均衡器會把從 Tomcat A 發(fā)送給 Tomcat B 的請求重新定向,所有的會話都將保持現(xiàn)有的狀態(tài)。
5.Tomcat B
接收到對會話 S1
的請求
毫無懸念,Tomcat B 會照處理其他請求的方式那樣來處理該請求。
6.Tomcat A
啟動
在 Tomcat A 開始接收新的請求之前,將會根據(jù)上面(1)(2)兩條所所說明的啟動序列來啟動。Tomcat A 會加入集群,聯(lián)系 Tomcat B 并獲取所有的會話狀態(tài)。一旦接收到會話狀態(tài),就會完成加載,并打開 HTTP/mod_jk 端口。所以,除非 Tomcat A 從 Tomcat B 那里接收到了會話變更,否則沒有發(fā)給 Tomcat A 的請求。
7.Tomcat A
接收到一個請求,調用會話 S1
上的 invalidate
方法
會攔截對 invalidate
的調用, 并且 session
會被加入失效會話隊列。 在請求完成時,不會發(fā)送會話改變消息,而是發(fā)送一個 “到期” 消息給 Tomcat B,Tomcat B 也會讓此會話失效。
8.Tomcat B
接收到一個對新會話 S2
的請求
同步驟 3。
9.Tomcat A
會話 S2
由于不活躍而超時
invalidate 調用會被攔截,當一個會話被用戶標記失效時,該會話就會加入到無效會話隊列。此時,失效的會話不會被復制,直到另一個請求通過系統(tǒng)并檢查無效會話隊列。
Membership 集群成員是通過非常簡單的組播 ping 命令來實現(xiàn)的。每個 Tomcat 實例都會定期發(fā)送一個組播 ping,ping 消息中包含 Tomcat 實例自身的 IP 和配置的 TCP 監(jiān)聽端口。如果實例在一個給定的時間內沒有收到這樣的 ping 信息,就會認為那個成員已經(jīng)崩潰了。非常簡潔高效!當然,您需要在系統(tǒng)上啟用廣播。
TCP 復制 一旦收到一個多播 ping 包,在下一個復制請求時成員被添加到集群,發(fā)送實例將使用的主機和端口信息,以及建立TCP套接字。使用該套接字發(fā)送序列化的數(shù)據(jù)。之選擇TCP套接字,是因為它內建有流量控制和保證發(fā)送的功能。所以發(fā)送的數(shù)據(jù)肯定會到達那里。
分布式的鎖定與使用架構的頁面s Tomcat 在跨集群同步不保持會話實例。這種邏輯的實現(xiàn)將是多開銷和導致各種各樣的問題。如果你的客戶用同一個會話同時發(fā)送多個請求,那么最后的請求將會覆蓋集群中的其他會話。
使用集群時,如何監(jiān)控是一個重要課題。有些集群對象是 JMX MBean。
添加下列屬性到啟動腳本上。
set CATALINA_OPTS=\
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=%my.jmx.port% \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false
下面是 Cluster 的 MBean 列表:
名稱 | 描述 | MBean 對象名-引擎 | MBean 對象名-主機 |
---|---|---|---|
Cluster
|
完整的 cluster 元素 | type=Cluster
|
type=Cluster,host=${HOST}
|
DeltaManager
|
該管理器控制會話,并處理會話復制 | type=Manager,context=${APP.CONTEXT.PATH}, host=${HOST}
|
type=Manager,context=${APP.CONTEXT.PATH}, host=${HOST}
|
FarmWarDeployer
|
將一個應用部署到該集群的所有節(jié)點上。 | 目前不支持 | type=Cluster, host=${HOST}, component=deployer
|
Member
|
代表集群中的一個節(jié)點 | type=Cluster, component=member, name=${NODE_NAME}
|
type=Cluster, host=${HOST}, component=memdber, name=${NODE_NAME}
|
ReplicationValve
|
該 valve 控制到備份節(jié)點的會話復制 | type=Valve,name=ReplicationValve
|
type=Valve,name=ReplicationValve,host=${HOST}
|
JvmRouteBinderValve
|
將 Session ID 變?yōu)?tomcat 當前的 jvmroute 的集群回滾值 | type=Valve,name=JvmRouteBinderValve, context=${APP.CONTEXT.PATH}
|
type=Valve,name=JvmRouteBinderValve,host=${HOST}, context=${APP.CONTEXT.PATH}
|
請參看 FAQ:集群文檔。
更多建議: