同一個目標，同一個夢想

引自：http://zyycaesar.javaeye.com/blog/296606

 

對于WEB應用集群的技術實現而言，最大的難點就是如何能在集群中的多個節點之間保持數據的一致性，會話（Session）信息是這些數據中最重要的一塊。要實現這一點，大體上有兩種方式，一種是把所有Session數據放到一臺服務器上或者數據庫中，集群中的所有節點通過訪問這臺Session服務器來獲取數據；另一種就是在集群中的所有節點間進行Session數據的同步拷貝，任何一個節點均保存了所有的Session數據。兩種方式都各有優點，第一種方式簡單、易于實現，但是存在著Session服務器發生故障會導致全系統不能正常工作的風險；第二種方式可靠性更高，任一節點的故障不會對整個系統對客戶訪問的響應產生影響，但是技術實現上更復雜一些。常見的平臺或中間件如microsoft asp.net和IBM WAS都會提供對兩種共享方式的支持，tomcat也是這樣，但是一般采用第二種方式。

 

     當采用tomcat默認集群配置（<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>）時，配置的細節實際上被省略了，對于大多數應用而言，使用默認配置已經足夠，完整的默認配置應該是這樣：

 

     <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.JvmRouteSessionIDBinderListener"/>
          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
        </Cluster> 

 

     下面筆者對這里的配置項作詳細解釋，以下內容均是筆者閱讀了tomcat官方文檔后自己的理解，有些可能不對，希望讀者能帶著批判的眼光閱讀，并歡迎指正筆者錯誤。

    

     tomcat集群各節點通過建立tcp鏈接來完成Session的拷貝，拷貝有同步和異步兩種模式。在同步模式下，對客戶端的響應必須在Session拷貝到其他節點完成后進行；異步模式無需等待Session拷貝完成就可響應。異步模式更高效，但是同步模式可靠性更高。同步異步模式由channelSendOptions參數控制，默認值是8，為異步模式，4是同步模式。在異步模式下，可以通過加上拷貝確認（Acknowledge）來提高可靠性，此時channelSendOptions設為10。

 

     Manager用來在節點間拷貝Session，默認使用DeltaManager，DeltaManager采用的一種all-to-all的工作方式，即集群中的節點會把Session數據向所有其他節點拷貝，而不管其他節點是否部署了當前應用。當集群中的節點數量很多并且部署著不同應用時，可以使用BackupManager，BackManager僅向部署了當前應用的節點拷貝Session。但是到目前為止BackupManager并未經過大規模測試，可靠性不及DeltaManager。

 

     Channel負責對tomcat集群的IO層進行配置。Membership用于發現集群中的其他節點，這里的address用的是組播地址（Multicast address，了解更多組播地址詳情請參見http://zyycaesar.javaeye.com/admin/blogs/296501），使用同一個組播地址和端口的多個節點同屬一個子集群，因此通過自定義組播地址和端口就可將一個大的tomcat集群分成多個子集群。Receiver用于各個節點接收其他節點發送的數據，在默認配置下tomcat會從4000-4100間依次選取一個可用的端口進行接收，自定義配置時，如果多個tomcat節點在一臺物理服務器上注意要使用不同的端口。Sender用于向其他節點發送數據，具體實現通過Transport配置，PooledParallelSender是從tcp連接池中獲取連接，可以實現并行發送，即集群中的多個節點可以同時向其他所有節點發送數據而互不影響。Interceptor有點類似下面將要解釋的Valve，起到一個閥門的作用，在數據到達目的節點前進行檢測或其他操作，如TcpFailureDetector用于檢測在數據的傳輸過程中是否發生了tcp錯誤。關于Channel的編程模型，請參見http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/tribes/Channel.html。

 

     Valve用于在節點向客戶端響應前進行檢測或進行某些操作，ReplicationValve就是用于用于檢測當前的響應是否涉及Session數據的更新，如果是則啟動Session拷貝操作，filter用于過濾請求，如客戶端對圖片，css，js的請求就不會涉及Session，因此不需檢測，默認狀態下不進行過濾，監測所有的響應。JvmRouteBinderValve會在前端的Apache mod_jk發生錯誤時保證同一客戶端的請求發送到集群的同一個節點，tomcat官方文檔并未解釋如何實現這一點，而且筆者認為這一設置似乎并無多大實用性。

 

     Deployer用于集群的farm功能，監控應用中文件的更新，以保證集群中所有節點應用的一致性，如某個用戶上傳文件到集群中某個節點的應用程序目錄下，Deployer會監測到這一操作并把這一文件拷貝到集群中其他節點相同應用的對應目錄下以保持所有應用的一致。這是一個相當強大的功能，不過很遺憾，tomcat集群目前并不能做到這一點，開發人員正在努力實現它，這里的配置只是預留了一個接口。

 

    Listener用于跟蹤集群中節點發出和收到的數據，也有點類似Valve的功能。

    在大體了解了tomcat集群實現模型后，就可以對集群作出更優化的配置了，tomcat推薦了一套配置，使用了比DeltaManager更高效的BackupManager，并且對ReplicationValve設置了請求過濾，注意在一臺服務器部署多個節點時需要修改Receiver的偵聽端口，另外，為了更高效的在節點間拷貝數據，所有tomcat節點最好采用相同的配置，具體配置如下：

 

     <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="6">

          <Manager className="org.apache.catalina.ha.session.BackupManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"
                   mapSendOptions="6"/>

          <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;.*\.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>

    

     Tomcat集群除了可以進行Session數據的拷貝，還可進行Context屬性的拷貝，通過修改context.xml的Context配置可以實現，使用<Context className="org.apache.catalina.ha.context.ReplicatedContext"/>替換默認Context即可，當然也可再加上distributable="true"屬性。

 

     下面通過假想的一組場景來描述tomcat集群如何工作，集群采用默認配置，由t1和t2兩個tomcat例程組成，場景按照時間順序排列。

1. t1啟動

     t1按照標準的tomcat啟動，當Host對象被創建時，一個Cluster對象（默認配置下是SimpleTcpCluster）也同時被關聯到這個Host對象。當某個應用在web.xml中設置了distributable時，Tomcat將為此應用的上下文環境創建一個DeltaManager。SimpleTcpCluster啟動membership服務和Replication服務（用于建立tcp連接）。

2. t2啟動（待t1啟動完成后）
     首先t2會執行和t1一樣的操作，然后SimpleTcpCluster會建立一個由t1和t2組成的membership。接著t2向集群中已啟動的服務器即t1請求Session數據，如果t1沒有響應t2的拷貝請求，t2會在60秒后time out。在Session數據拷貝完成之前t2不會接收客戶端的http或mod_jk/ajp請求。

3. t1接收http請求，創建Session s1
     t1正常響應客戶請求，但是在t1把結果發送回客戶端時，ReplicationValve會攔截當前請求（如果filter中配置了不需攔截的請求類型，這一步就不會進行，默認配置下攔截所有請求），如果發現當前請求更新了Session，調用Replication服務建立tcp連接把Session拷貝到membership列表中的其他節點即t2，返回結果給客戶端（注意，如果采用同步拷貝，必須等拷貝完成后才會返回結果，異步拷貝在數據發送到tcp連接就返回結果，不等待拷貝完成）。在拷貝時，所有保存在當前Session中的可序列化的對象都會被拷貝，而不僅僅是發生更新的部分。

4. t1崩潰
     當t1崩潰時，t2會被告知t1已從集群中退出，然后t2就會把t1從自己的membership列表中刪除，發生在t2的Session更新不再往t1拷貝，同時負載均衡器會把后續的http請求全部轉發給t2。在此過程中所有的Session數據不會丟失。

5. t2接收s1的請求
     t2正常響應s1的請求，因為t2保存著s1的所有數據。

6. t1重新啟動
     按步驟1、2一樣的操作啟動，加入集群，從t2拷貝所有Session數據，拷貝完成后開放自己的http和mod_jk/ajp端口接收請求。

7. t1接收請求，s1失效
     t1繼續接收來自s1的請求，把s1設置為過期。這里的過期并非因為s1處于非活動狀態超過設置的時間，而是執行類似注銷的操作而引起的Session失效。這時t1并非發送s1的所有數據而是一個類似s1 expired的消息，t2收到消息后也會把s1設為過期。

8. t2接收請求，創建Session s2
     和步驟3一樣。

9. t1 s2過期
     對于因超時引起的Session失效t1無需通知t2，因為t2同樣知道s2已經超時。因此對于tomcat集群有一點非常重要，所有節點的操作系統時間必須一致！不然會出現某個節點Session已過期而在另一節點此Session仍處于活動狀態的現象。