Tomcat集群Cluster實現(xiàn)原理剖析

1、本文意在介紹對tomcat集群進行更深入詳細的配置以滿足特定需求。 對于WEB應(yīng)用集群的技術(shù)實現(xiàn)而言，最大的難點就是如何能在集群中的多個節(jié)點之間保持數(shù)據(jù)的一致性，會話（Session）信息是這些數(shù)據(jù)中最重要的一 塊。要實現(xiàn)這一點，大體上有兩種方式，一種是把所有Session數(shù)據(jù)放到一臺服務(wù)器上或者數(shù)據(jù)庫中，集群中的所有節(jié)點通過訪問這臺Session服務(wù)器 來獲取數(shù)據(jù)；另一種就是在集群中的所有節(jié)點間進行Session數(shù)據(jù)的同步拷貝，任何一個節(jié)點均保存了所有的Session數(shù)據(jù)。兩種方式都各有優(yōu)點，第 一種方式簡單、易于實現(xiàn)，但是存在著Session服務(wù)器發(fā)生故障會導(dǎo)致全系統(tǒng)不能正常工作的風險；第

2、二種方式可靠性更高，任一節(jié)點的故障不會對整個系統(tǒng) 對客戶訪問的響應(yīng)產(chǎn)生影響，但是技術(shù)實現(xiàn)上更復(fù)雜一些。常見的平臺或中間件如microsoft 和IBM WAS都會提供對兩種共享方式的支持，tomcat也是這樣，但是一般采用第二種方式。當采用tomcat默認集群配置（）時，配置的細節(jié)實際上被 省略了，對于大多數(shù)應(yīng)用而言，使用默認配置已經(jīng)足夠，完整的默認配置應(yīng)該是這樣：推薦精選推薦精選 下面筆者對這里的配置項作詳細解釋，以下內(nèi)容均是筆者閱讀了tomcat官方文檔后自己的理解，有些可能不對，希望讀者能帶著批判的眼光閱讀，并歡迎指正筆者錯誤。 tomcat集群各節(jié)點通過建立tcp鏈接來完成Sessio

3、n的拷貝，拷貝有同步和異步兩種模式。在同步模式下，對客戶端的響應(yīng)必須在Session拷 貝到其他節(jié)點完成后進行；異步模式無需等待Session拷貝完成就可響應(yīng)。異步模式更高效，但是同步模式可靠性更高。同步異步模式由 channelSendOptions參數(shù)控制，默認值是8，為異步模式，4是同步模式。在異步模式下，可以通過加上拷貝確認（Acknowledge） 來提高可靠性，此時channelSendOptions設(shè)為10。 Manager用來在節(jié)點間拷貝Session，默認使用DeltaManager，DeltaManager采用的一種all-to-all的工作方 式，即集群中的節(jié)點會把Ses

4、sion數(shù)據(jù)向所有其他節(jié)點拷貝，而不管其他節(jié)點是否部署了當前應(yīng)用。當集群中的節(jié)點數(shù)量很多并且部署著不同應(yīng)用時，可以使 用BackupManager，BackManager僅向部署了當前應(yīng)用的節(jié)點拷貝Session。但是到目前為止BackupManager并未經(jīng)過 大規(guī)模測試，可靠性不及DeltaManager。推薦精選 Channel負責對tomcat集群的IO層進行配置。Membership用于發(fā)現(xiàn)集群中的其他節(jié)點，這里的address用的是組播地址（Multicast address，了解更多組播地址詳情請參見 使用同一個組播地址和端口的多個節(jié)點同屬一個子集群，因此通過自定義組播地址和端口

5、就可將一個大的tomcat集群分成多個子集群。Receiver用于 各個節(jié)點接收其他節(jié)點發(fā)送的數(shù)據(jù)，在默認配置下tomcat會從4000-4100間依次選取一個可用的端口進行接收，自定義配置時，如果多個 tomcat節(jié)點在一臺物理服務(wù)器上注意要使用不同的端口。Sender用于向其他節(jié)點發(fā)送數(shù)據(jù)，具體實現(xiàn)通過Transport配 置，PooledParallelSender是從tcp連接池中獲取連接，可以實現(xiàn)并行發(fā)送，即集群中的多個節(jié)點可以同時向其他所有節(jié)點發(fā)送數(shù)據(jù)而互不 影響。Interceptor有點類似下面將要解釋的Valve，起到一個閥門的作用，在數(shù)據(jù)到達目的節(jié)點前進行檢測或其他操作，如

6、 TcpFailureDetector用于檢測在數(shù)據(jù)的傳輸過程中是否發(fā)生了tcp錯誤。關(guān)于Channel的編程模型，請參見推薦精選/tomcat-6.0-doc/api/org/apache/catalina/tribes/Channel.html。 Valve用于在節(jié)點向客戶端響應(yīng)前進行檢測或進行某些操作，ReplicationValve就是用于用于檢測當前的響應(yīng)是否涉及Session數(shù)據(jù)的 更新，如果是則啟動Session拷貝操作，filter用于過濾請求，如客戶端對圖片，css，js的請求就不會涉及Session，因此不需檢測，默 認狀態(tài)下不

7、進行過濾，監(jiān)測所有的響應(yīng)。JvmRouteBinderValve會在前端的Apache mod_jk發(fā)生錯誤時保證同一客戶端的請求發(fā)送到集群的同一個節(jié)點，tomcat官方文檔并未解釋如何實現(xiàn)這一點，而且筆者認為這一設(shè)置似乎并無多大實 用性。 Deployer用于集群的farm功能，監(jiān)控應(yīng)用中文件的更新，以保證集群中所有節(jié)點應(yīng)用的一致性，如某個用戶上傳文件到集群中某個節(jié)點的應(yīng)用程序目錄 下，Deployer會監(jiān)測到這一操作并把這一文件拷貝到集群中其他節(jié)點相同應(yīng)用的對應(yīng)目錄下以保持所有應(yīng)用的一致。這是一個相當強大的功能，不過很遺 憾，tomcat集群目前并不能做到這一點，開發(fā)人員正在努力實現(xiàn)它，這

8、里的配置只是預(yù)留了一個接口。推薦精選 Listener用于跟蹤集群中節(jié)點發(fā)出和收到的數(shù)據(jù)，也有點類似Valve的功能。 在大體了解了tomcat集群實現(xiàn)模型后，就可以對集群作出更優(yōu)化的配置了，tomcat推薦了一套配置，使用了比DeltaManager更高效的 BackupManager，并且對ReplicationValve設(shè)置了請求過濾，注意在一臺服務(wù)器部署多個節(jié)點時需要修改Receiver的偵聽端 口，另外，為了更高效的在節(jié)點間拷貝數(shù)據(jù)，所有tomcat節(jié)點最好采用相同的配置，具體配置如下： 推薦精選推薦精選 Tomcat集群除了可以進行Session數(shù)據(jù)的拷貝，還可進行Context屬

9、性的拷貝，通過修改context.xml的Context配置可以實 現(xiàn)，使用替換默認 Context即可，當然也可再加上distributable=true屬性。 下面通過假想的一組場景來描述tomcat集群如何工作，集群采用默認配置，由t1和t2兩個tomcat例程組成，場景按照時間順序排列。推薦精選1.t1啟動 t1按照標準的tomcat啟動，當Host對象被創(chuàng)建時，一個Cluster對象（默認配置下是SimpleTcpCluster）也同時被關(guān)聯(lián)到這個 Host對象。當某個應(yīng)用在web.xml中設(shè)置了distributable時，Tomcat將為此應(yīng)用的上下文環(huán)境創(chuàng)建一個 DeltaMa

10、nager。SimpleTcpCluster啟動membership服務(wù)和Replication服務(wù)（用于建立tcp連接）。2.t2啟動（待t1啟動完成后） 首先t2會執(zhí)行和t1一樣的操作，然后SimpleTcpCluster會建立一個由t1和t2組成的membership。接著t2向集群中已啟動的服 務(wù)器即t1請求Session數(shù)據(jù)，如果t1沒有響應(yīng)t2的拷貝請求，t2會在60秒后time out。在Session數(shù)據(jù)拷貝完成之前t2不會接收客戶端的http或mod_jk/ajp請求。3.t1接收http請求，創(chuàng)建Session s1 t1正常響應(yīng)客戶請求，但是在t1把結(jié)果發(fā)送回客戶端時，R

11、eplicationValve會攔截當前請求（如果filter中配置了不需攔截的請求類 型，這一步就不會進行，默認配置下攔截所有請求），如果發(fā)現(xiàn)當前請求更新了Session，調(diào)用Replication服務(wù)建立tcp連接把 Session拷貝到membership列表中的其他節(jié)點即t2，返回結(jié)果給客戶端（注意，如果采用同步拷貝，必須等拷貝完成后才會返回結(jié)果，異步拷貝 在數(shù)據(jù)發(fā)送到tcp連接就返回結(jié)果，不等待拷貝完成）。在拷貝時，所有保存在當前Session中的可序列化的對象都會被拷貝，而不僅僅是發(fā)生更新的部 分。推薦精選4.t1崩潰 當t1崩潰時，t2會被告知t1已從集群中退出，然后t2就會把t

12、1從自己的membership列表中刪除，發(fā)生在t2的Session更新不再往t1拷貝，同時負載均衡器會把后續(xù)的http請求全部轉(zhuǎn)發(fā)給t2。在此過程中所有的Session數(shù)據(jù)不會丟失。5.t2接收s1的請求 t2正常響應(yīng)s1的請求，因為t2保存著s1的所有數(shù)據(jù)。6.t1重新啟動 按步驟1、2一樣的操作啟動，加入集群，從t2拷貝所有Session數(shù)據(jù)，拷貝完成后開放自己的http和mod_jk/ajp端口接收請求。推薦精選7.t1接收請求，s1失效 t1繼續(xù)接收來自s1的請求，把s1設(shè)置為過期。這里的過期并非因為s1處于非活動狀態(tài)超過設(shè)置的時間，而是執(zhí)行類似注銷的操作而引起的Session失 效。這時t1并非發(fā)送s1的所有數(shù)據(jù)而是一個類似s1 expired的消息，t2收到消息后也會把s1設(shè)為過