Tomcat是什麼：Tomcat與Java技、Tomcat與Web應用以及Tomcat基本框架及相關配置

一、Tomcat是什麼
       Apache Tomcat是由Apache Software Foundation（ASF）開發的一個開源Java WEB應用服務器。

       相似功能的還有：Jetty、Resin、Websphere、weblogic、JBoss、Glassfish、GonAS等，它們的市場佔有率以下，能夠看到Tomcat是最受歡迎的Java WEB應用服務器。

       Tomcat在技術實現上所處的位置以下：

 

       下面咱們來了解下Tomcat與這些技術之間的關係。

1-一、Tomcat與Java
一、Tomcat與Java SE

      Tomcat是用Java語言編寫的，須要運行在Java虛擬機上，因此通常須要先安裝JDK，以提供運行環境。

二、Tomcat與Java EE

      Tomcat實現了幾個Java EE規範，包括Java Servlet、Java Server Pages（JSP），Java Expression Language和Java WebSocket等，這些是都下載Tomcat安裝包默認提供的，能夠在源碼中看到相關Java EE 規範API源碼引用，以下：

 

       此外，官網還提供了另一些Java EE規範的實現，如JMX Remote、Web services，要使用的話須要另外下載，放到Tomat安裝目錄/lib中，官網相關下載以下：

 

       能夠說Tomcat是一個不完整的Java EE應用服務器。

       更多關於Java SE、Java EE等java技術信息請參考：《Java平臺體系：組成結構 運行機制 JRE/JDK/OpenJDK Java SE/EE/ME Java優勢》

1-二、Tomcat與Servlet/編程開發
       Tomcat實現的幾個Java EE規範最重的是Servlet，由於實現了Servlet規範，因此Tomcat也是一個Servlet容器，能夠運行咱們本身編寫的Servlet應用程序處理動態請求。

       平時用的Struts二、SpringMVC框架就是基於Servlet，因此咱們能夠在這些框架的基礎上進行快速開發，而後部署到Tomcat中運行。

       另外對於JSP規範實現：能夠混合HTML與Java開發在一個文件中（.jsp），這種文件在第一次調用以後會被Tomcat的Jasper組件編譯成一個servlet類，在後續的操做中則能夠直接使用此類。這種開發方式不靈活，通常少用。

1-三、Tomcat與WEB/HTTP請求
       Tomcat的（HTTP類型）Connector組件實現了HTTP請求的解析，Tomcat經過Connector組件接收HTTP請求並解析，而後把解析後的信息交給Servlet處理：

       對於靜態資源（html/js/jpg等）請求，Tomcat提供默認的Servlet來處理並響應；

       對於動態請求，能夠映射到本身編寫的Servlet應用程序來處理。

1-四、Tomcat與Nginx/Apache的應用架構
       Nginx、Apache都是目前主流的Web服務器，也能夠做爲反向代理服務器；它們在處理大量併發的請求鏈接、鏈接會話管理和靜態內容請求等方面相比Tomcat更具優點。

       因此通常在實際應用中，先是經過Nginx（或Apache）反向代理服務器接收請求，匹配分離動態/靜態請求（動靜分離）;

       若是是靜態請求，則轉發到另外的Nginx WEB服務器上，返回靜態內容；若是是動態請求，則轉發到後面的Tomcat應用服務器，處理動態請求的業務邏輯。

       簡單的架構以下：

 

       更多信息請參考：《各類容器與服務器的區別與聯繫：Servlet容器 WEB容器 Java EE容器 應用服務器 WEB服務器 Java EE服務器》

二、Tomcat安裝目錄

       Tomcat安裝後根目錄如上圖，由環境變量$ CATALINA_HOME表示，能夠手動設置，能夠由/bin/catalina.sh命令腳本自動設置該環境變量，若是使用多個Tomcat實例，須要爲每一個實例定義$ CATALINA_BASE環境變量。

       這些目錄說明以下：

      bin：啓動、關閉和其餘腳本， * .sh文件（對於Unix系統）是* .bat文件的功能重複（對於Windows系統）。

      conf：配置文件及相關數據文件存放目錄，如server.xml,tomcat-users.xml,web.xml；

       logs：默認的日誌文件存放目錄，如訪問日誌，能夠經過server.xml文件配置到其餘目錄；

       lib：Tomcat使用的庫文件存放目錄，如Servlet規範的API；

       temp：臨時文件的工做目錄，如上傳大文件時的緩存數據會存儲到這裏；

      webapps：咱們的應用程序部署目錄，能夠經過server.xml文件配置；

       work：Tomcat工做目錄，如存放JSP編譯後的類文件。

       更多相關信息請參考：http://tomcat.apache.org/tomcat-8.5-doc/introduction.html

三、Tomcat配置文件
       Tomcat的配置文件默認存放在$CATALINA_HOME/conf目錄中，主要有如下幾個：

      server.xml： Tomcat核心配置文件，包含Service, Connector, Engine, Realm, Valve, Hosts主組件的相關配置信息。

      context.xml：爲部署與此Tomcat實例上的web應用程序提供的默認配置文件，每一個webapp均可以使用獨有的context.xml,一般放置於webapp目錄的META-INF子目錄中，經常使用於定義會話管理器，Realm已經JDBC等。

      web.xml：爲部署與Tomcat實例上的全部web應用程序提供部署描述符，一般用於爲webapp提供默認的servlet定義和基本的MUIME映射表。

      tomcat-users.xml：Realm認證時用到的相關角色、用戶和密碼等信息；Tomcat自帶的manager默認狀況下會用到此文件；在Tomcat中添加/刪除用戶，爲用戶指定角色等將經過編輯此文件實現。

       catalina.policy：當基於-securty選項啓動tomcat實例時會讀取此配置文件；此文件是JAVA的安全策略配置文件，用於配置訪問codebase（代碼庫）或某些Java類的權限。

      catalina.properties：java屬性定義文件，設定類加載器路徑，安全包列表和一些調整性能的參數信息。

      logging.properties：定義日誌相關的配置信息，如日誌級別、文件路徑等。

四、WEB應用部署目錄結構
       咱們的應用程序通常會打包成歸檔格式（.war），而後放到Tomcat的應用程序部署目錄。而webapp有特定的組織格式，是一種層次型目錄結構，一般包含了servlet代碼文件、HTML/jsp頁面文件、類文件、部署描述符文件等等，相關說明以下：

       /：web應用程序的根目錄，能夠存放HTML/JSP頁面以及其餘客戶端瀏覽器必須可見的其餘文件（如js/css/圖像文件）。在較大的應用程序中，還能夠選擇將這些文件劃分爲子目錄層次結構。

      /WEB-INF：此webapp的全部私有資源目錄，用戶瀏覽器不可能訪問到的，一般web.xml和context.xml均放置於此目錄。

      /WEB-INF/web.xml：此webapp的私有的部署描述符，描述組成應用程序的servlet和其餘組件（如filter），以及相關初始化參數和容器管理的安全性約束。

       /WEB-INF/classes：此webapp自有的Java程序類文件（.class）及相關資源存放目錄。

       /WEB-INF/lib：此目錄存放webapp自有的JAR文件，其中包含應用程序所需的Java類文件（及相關資源），例如第三方類庫或JDBC驅動程序。

       更多信息請參考：

      Tomcat《Application Developer's Guide》Deployment

       《Servlet3.1規範（最終版）》第10章

五、Tomcat基本框架及相關配置

       如上圖，Tomcat能夠按功能劃分許多不一樣的組件，這些組件均可以經過/conf/server.xml文件中可定義和配置，包括Server, Service, Connector, Engine, Cluster, Host, Alias, Context, Realm, Valve, Manager, Listener, Resources, ResourceEnvRef, WatchedResource, Store, Transaction, Channel, Membership, Transport, Member, ClusterListener等，通常可分爲如下四類：

      一、頂級組件：位於配置層次的頂級，而且彼此間有着嚴格的對應關係，有Server組件、Service組件；

      二、鏈接器：鏈接客戶端（能夠是瀏覽器或Web服務器）請求至Servlet容器，只有Connector組件，

      三、容器：表示其功能是處理傳入請求的組件，並建立相應的響應。如Engine處理對一個Service的全部請求，Host處理對特定虛擬主機的全部請求，而且Context處理對特定web應用的全部請求；

      四、被嵌套的組件：位於一個容器當中，但不能包含其它組件；一些組件能夠嵌套在任何Container中，而另外一些只能嵌套在Context中。

       如server.xml默認配置（刪除註釋內容）以下：

 

       下面來了解下上圖中主要的組件。

5-一、Server組件
       Server（服務器）表示Tomcat的一個實例，所以，它必須是/conf / server.xml配置文件中的單個最外層元素，它的屬性表示servlet容器的總體特性。一般一個JVM只能包含一個Tomcat實例。

       默認配置表示監聽在8005端口以接收shutdown命令，默認僅容許經過本機訪問。

       更多Server配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Server Component

5-二、Service組件
       Service（服務）主要用於關聯一個Engine和與此Engine相關的Connector，每一個Connector經過一個特定的端口和協議接收請求，並將其轉發相當聯的Engine進行處理。

       所以，Service能夠包含一個Engine、以有一個或多個Connector；而一個Server能夠包含多個Service組件，但一般情下只爲一個Server指派一個Service。一般須要給Service命名，能夠方便管理員在日誌文件中識別不一樣Service產生的日誌。

       如默認配置中server只包含一個名爲"Catalina"的service，而service裏包含兩個Connector，其中一個監聽8080端口接收HTTP請求，另外一個監聽8009端口接收AJP協議的請求。

       更多Service配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Service Component

5-三、Connector組件
       如上面所述，Connector（鏈接器）經過一個特定的端口接收特定協議的客戶端請求，並將其轉發相當聯的Engine進行處理。一個Engine能夠配置多個鏈接器，但這些鏈接器必須使用不一樣的端口。

       定義鏈接器可使用多種屬性，有些屬性也只適用於某特定的鏈接器類型。通常說來，鏈接器類型能夠分爲兩種：

（1）、HTTP鏈接器

      HTTP鏈接器元素表示支持HTTP / 1.1協議的鏈接器組件，它能使Tomcat可以做爲獨立的Web服務器。此組件的特定實例偵聽服務器上特定TCP端口號上的鏈接，每一個轉發到相關聯的Engine以執行請求處理並建立響應。

      HTTP鏈接器又有三種不一樣的實現：Java Nio Connector、Java Nio2 Connector、APR/native Connector，它們的對好比下：

 

       默認配置文件，定義了一個鏈接器爲protocol="HTTP/1.1" 表示的是使用自動切換機制來選擇基於Java NIOConnector或基於APR /Native Connector（須要設置），也能夠手動指定，

      更多HTTP鏈接器配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The HTTP Connector

（2）、AJP 1.3鏈接器

      AJP鏈接器元素表示經過AJP(Apache JServ Protocol)協議與Web鏈接器通訊的鏈接器組件。

      AJP協議是基於二進制的格式在Web服務器和Tomcat之間傳輸數據，這比HTTPP得到更好的效率，但比較複雜不通用。

      一般用於將Tomcat集成到現有Apache服務器中，而且但願Apache處理Web應用程序中包含的靜態內容或SSL鏈接處理的狀況，即Apache服務器做爲代理服務器。Apache與Tomcat結合能夠由mod_jk或mod_proxy模塊來實現，但它們的使用範圍不一樣：mod_jk支持apache/1.3,apache/2.0，mod_proxy支持apache/2.2+。

       默認配置文件中定義了一個監聽8009端口的AJP鏈接器，其實官方文檔說明這種鏈接器不久後再也不支持，通常用得很少，就再也不多介紹了。

      更多AJP 1.3鏈接器配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The AJP Connector

   

       定義鏈接器時能夠配置的屬性很是多，但一般定義HTTP鏈接器時必須定義的屬性只有"port"，定義AJP鏈接器時必須定義的屬性只有"protocol"，由於默認的協議爲HTTP。如下爲經常使用屬性的說明（更多請參考前面給出的文檔）：

      1) 、address：指定鏈接器監聽的地址，默認爲全部地址，即0.0.0.0；

      2)、 maxThreads：支持的最大併發鏈接數，默認爲200；

      3)、port：監聽的端口，默認爲0；

      4) 、protocol：鏈接器使用的協議，默認爲HTTP/1.1，定義AJP協議時一般爲AJP/1.3；

      5) 、redirectPort：若是某鏈接器支持的協議是HTTP，當接收客戶端發來的HTTPS請求時，則轉發至此屬性定義的端口；

      6)、connectionTimeout：等待客戶端發送請求的超時時間，單位爲毫秒，默認爲60000，即1分鐘；

      7)、enableLookups：是否經過request.getRemoteHost()進行DNS查詢以獲取客戶端的主機名；默認爲true；

      8) 、acceptCount：設置等待隊列的最大長度；一般在tomcat全部處理線程均處於繁忙狀態時，新發來的請求將被放置於等待隊列中；

5-四、Engine組件
       Engine（引擎）表示與特定Service相關聯的整個請求處理機制，即Servlet容器引擎。它接收和處理來自一個或多個鏈接器的全部請求，並檢查每個請求的HTTP首部信息以辨別此請求應該發往哪一個Host或Context，並將完成的響應返回到鏈接器，以便最終傳輸回客戶端。

       一個Engine元素必須嵌套在Service元素內，它能夠包含多個host組件，還能夠包含Realm、Listener和Valve等子容器。

 

       經常使用的屬性定義：

      一、defaultHost：Tomcat支持基於FQDN的虛擬主機，這些虛擬主機能夠經過在Engine容器中定義多個不一樣的Host組件來實現；但若是此引擎的鏈接器收到一個發往非非明肯定義虛擬主機的請求時則須要將此請求發往一個默認的虛擬主機進行處理，所以，在Engine中定義的多個虛擬主機的主機名稱中至少要有一個跟defaultHost定義的主機名稱同名。

      二、name：Engine組件的名稱，用於日誌和錯誤信息記錄時區別不一樣的引擎。

       如默認配置中定義了一個名爲"Catalina"的Engine，而Engine裏包含一個Hots，並被配置爲默認的虛擬主機。

      更多Engine配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Engine Component

5-五、Host組件
       Host（虛擬主機）相似於Apache中的虛擬主機，但在Tomcat中只支持基於FQDN的"虛擬主機"。Host位於Engine容器中用於接收請求並進行相應處理，它是服務器（例如"www.mycompany.com"）的網絡名稱與運行Tomcat的特定服務器的關聯。

       客戶端一般使用主機名來標識他們但願鏈接的服務器，但要使客戶端可以使用其網絡名稱鏈接到Tomcat服務器，此名稱必須在管理所屬的Internet域的域名服務（DNS）服務器中註冊。此主機名也包含在HTTP請求標頭中，Tomcat從HTTP頭中提取主機名，並查找具備匹配名稱的主機；若是未找到匹配項，請求將路由到默認主機。

       一個Engine至少要包含一個Host組件，而在Host元素內能夠嵌入與此虛擬主機關聯的Web應用程序的Context等元素。

 

       經常使用屬性說明：

      1)、name：此Host的FQDN虛擬主機名稱；

      2) 、appBase：此Host的webapps目錄，即存放非歸檔的web應用程序的目錄或歸檔後的WAR文件的目錄路徑；可使用基於$CATALINA_HOME的相對路徑；

       3)、autoDeploy：在Tomcat處於運行狀態時放置於appBase目錄中的應用程序文件是否自動進行deploy；默認爲true；

      4) 、unpackWars：在啓用此webapps時是否對WAR格式的歸檔文件先進行展開；默認爲true。

       如默認配置中定義了一個主機名爲"localhost"的Host，而webapps目錄爲$ CATALINA_BASE相對的"webapps"，即前面說到的默認目錄，也可用絕對路徑來配置其餘目錄。

       更多Host配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Host Component

5-六、Context組件
       Context（上下文）表示在特定虛擬主機中運行的Web應用程序，一個Context對應一個Web應用程序，而裏面的Wrapper能夠理解爲一個個Servlet程序。

       Context須要根據其定義的上下文路徑（path）匹配請求URI的最長前綴（除主機名外）來選擇。一旦選擇，能夠由docBase來找到該上下文將對應的web應用程序部署目錄，由目錄中web.xml定義的servlet映射選擇一個合適的servlet來處理傳入的請求。

       一個Host能夠有多個Context，一般不建議定義在server.xml文件中，而是每個context定義使用一個單獨的XML文件進行，其文件的目錄      爲$CATALINA_HOME/conf/<engine name>/<host name>。

       能夠看到server.xml中默認沒有定義Context，但存在/conf/context.xml，在前面說Tomcat配置文件時曾介紹過，context.xml爲部署與此Tomcat實例上全部的web應用程序提供的默認配置文件，刪除註釋後其內容以下：

 

       經過它能夠找到默認的和各web應用程序提供部署描述符文件web.xml，/conf/web.xml定義了Tomcat提供的默認Servlet處理程序，主要用來處理靜態資源請求；而各webapp的web.xml能夠定義其餘的動態請求url映射到不一樣Servlet程序處理。

       經常使用的屬性定義有：

      1) 、docBase：相應的Web應用程序的存放位置；也可使用相對路徑，起始路徑爲此Context所屬Host中appBase定義的路徑；切記，docBase的路徑名不能與相應的Host中appBase中定義的路徑名有包含關係，好比，若是appBase爲deploy，而docBase毫不能爲deploy-bbs類的名字；

      2) 、path：相對於Web服務器根路徑而言的URI；若是爲空""，則表示爲此webapp的根路徑；若是context定義在一個單獨的xml文件中，此屬性不須要定義；

      3)、reloadable：是否容許從新加載此context相關的Web應用程序的類；默認爲false；

       更多Context配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Context Component

5-七、Realm組件
       Realm（領域）表示分配給這些用戶的用戶名，密碼和角色（相似於Unix組）的"數據庫"。一個Realm（領域）表示一個安全上下文，它是一個受權訪問某個給定Context的用戶列表和某用戶所容許切換的角色相關定義的列表。

       Catalina容器（Engine，Host或Context）能夠包含不超過一個Realm元素（但自身能夠嵌套）。此外，與引擎或主機關聯的領域由低級容器自動繼承，除非下級容器顯式定義了本身的領域。若是沒有爲引擎配置領域，將自動爲引擎配置空領域的實例。

       定義Realm時唯一必需要提供的屬性是classname，它是Realm的多個不一樣實現，用於表示此Realm認證的用戶及角色等認證信息的存放位置，Tomcat中實現了多種不一樣的Realm，以下：

      UserDatabaseRealm：基於UserDatabase文件(一般是tomcat-user.xml)實現用戶認證，它實現是一個徹底可更新和持久有效的MemoryRealm，所以可以跟標準的MemoryRealm兼容；它經過JNDI實現；

      LockOutRealm：提供鎖定功能，以便在給定時間段內出現過多的失敗認證嘗試時提供用戶鎖定機制；

      JAASRealm：基於Java Authintication and Authorization Service實現用戶認證；

      JDBCRealm：經過JDBC訪問某關係型數據庫表實現用戶認證；

      JNDIRealm：基於JNDI使用目錄服務實現認證信息的獲取；

      MemoryRealm：查找tomcat-user.xml文件實現用戶信息的獲取。

       能夠看到默認配置文件中定義了一個LockOutRealm並嵌套一個UserDatabaseRealm的Realm來經過tomcat-user.xml文件實現用戶認證。

       更多Realm配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Realm Component

5-八、Valve組件
       Valve（閥門）相似於過濾器，用來攔截請求並在將其轉至目標以前進行某種處理操做；它能夠工做於Engine和Host/Context之間、Host和Context之間以及Context和Web應用程序的某資源之間。

       Valve常被用來記錄客戶端請求、客戶端IP地址和服務器等信息，這種處理技術一般被稱做請求轉儲(request dumping)。請求轉儲valve記錄請求客戶端請求數據包中的HTTP首部信息和cookie信息文件中，響應轉儲valve則記錄響應數據包首部信息和cookie信息至文件中。

       一個容器內能夠創建多個Valve，並且Valve定義的次序也決定了它們生效的次序。不一樣類型的Value具備不一樣的處理能力，Tomcat中實現了多種不一樣的Valve：

      AccessLogValve：訪問日誌Valve

      ExtendedAccessValve：擴展功能的訪問日誌Valve

      RequestDumperValve：請求轉儲Valve；

      RemoteAddrValve：基於遠程地址的訪問控制；

      RemoteHostValve：基於遠程主機名稱的訪問控制；

      SemaphoreValve：用於控制Tomcat主機上任何容器上的併發訪問數量；

      ReplicationValve：專用於Tomcat集羣架構中，能夠在某個請求的session信息發生更改時觸發session數據在各節點間進行復制；

      SingleSignOn：將兩個或多個須要對用戶進行認證webapp在認證用戶時鏈接在一塊兒，即一次認證便可訪問全部鏈接在一塊兒的webapp；

      ClusterSingleSingOn：對SingleSignOn的擴展，專用於Tomcat集羣當中，須要結合ClusterSingleSignOnListener進行工做。

       經過屬性className定義相關的java實現的類名來選擇Value。如默認配置文件中定義了一個AccessLogValve的Value來記錄訪問日誌到文件中。

       更多Valve配置信息請參考：《Apache Tomcat 8 Configuration Reference》 The Valve Component

5-九、其餘組件
一、Logger

      日誌記錄器(Logger)：用於記錄組件內部的狀態信息，可被用於除Context以外的任何容器中。日誌記錄的功能可被繼承，所以，一個引擎級別的Logger將會記錄引擎內部全部組件相關的信息，除非某內部組件定義了本身的Logger組件（前面介紹的AccessLogValve使用自包含的邏輯來寫它的日誌文件，以得到更好的效率）。

二、Listener

      Listener用於建立和配置LifecycleListener對象，而LifecycleListener一般被開發人員用來建立和刪除容器。

三、Loader

      Java的動態裝載功能是其語言功能強大表現之一，Servlet容器使用此功能在運行時動態裝載servlet和它們所依賴的類。Loader能夠用於Context中控制java類的加載，即WebApp類加載器。

四、Resources

      常常用於實如今Context中指定須要裝載的但不在Tomcat本地磁盤上的應用資源，如Java類，HTML頁面，JSP文件等。

五、GlobalNamingResources

      應用於整個服務器的JNDI映射，此能夠避免每一個Web應用程序都須要在各自的web.xml建立，這在web應用程序以WAR的形式存在時尤其有用。它一般能夠包含三個子元素：Environment、Resource和ResourceEnvRef。

六、WatchedResource

      WatchedResource能夠用於Context中監視指定的webapp程序文件的改變，而且可以在監視到文件內容發生改變時從新裝載此文件。

七、Manager

      Manger對象用於實現HTTP會話管理的功能，Tomcat中有5種Manger的實現：

1) 、StandardManager

      Tomcat6的默認會話管理器，用於非集羣環境中對單個處於運行狀態的Tomcat實例會話進行管理。當Tomcat關閉時，這些會話相關的數據會被寫入磁盤上的一個名叫SESSION.ser的文件，並在Tomcat下次啓動時讀取此文件。

2) 、PersistentManager

      當一個會話長時間處於空閒狀態時會被寫入到swap會話對象，這對於內存資源比較吃緊的應用環境來講比較有用。

3)、DeltaManager

      屬於ClusterManager，用於Tomcat集羣的會話管理器，它經過將改變了會話數據同步給集羣中的其它節點實現會話複製。這種實現會將全部會話的改變同步給集羣中的每個節點，也是在集羣環境中用得最多的一種實現方式。

但集羣節點較多時，會消耗大量的網絡資源，通常適用於三、4個節點的集羣。

4)、BackupManager

      屬於ClusterManager，用於Tomcat集羣的會話管理器，與DeltaManager不一樣的是，某節點會話的改變只會同步給集羣中的另外一個而非全部節點。

5)、SimpleTcpReplicationManager

      Tomcat4時用到的版本，過於老舊了。

八、Stores

      PersistentManager必須包含一個Store元素以指定將會話數據存儲至何處。這一般有兩種實現方式：FileStore和JDBCStore。

九、Cluster

      專用於配置Tomcat集羣的元素，可用於Engine和Host容器中。在用於Engine容器中時，Engine中的全部Host均支持集羣功能。在Cluster元素中，須要直接定義一個Manager元素，這個Manager元素有一個其值爲org.apache.catalina.ha.session.DeltaManager或org.apache.catalina.ha.session.BackupManager的className屬性。同時，Cluster中還須要分別定義一個Channel和ClusterListener元素。

十、Channel

      用於Cluster中給集羣中同一組中的節點定義通訊"信道"。Channel中須要至少定義Membership、Receiver和Sender三個元素，此外還有一個可選元素Interceptor。

十一、Membership

      用於Channel中配置同一通訊信道上節點集羣組中的成員狀況，即監控加入當前集羣組中的節點並在各節點間傳遞心跳信息，並且能夠在接收不到某成員的心跳信息時將其從集羣節點中移除。Tomcat6中Membership的實現是org.apache.catalina.tribes.membership.McastService。

十二、Sender

      用於Channel中配置"複製信息"的發送器，實現發送須要同步給其它節點的數據至集羣中的其它節點。發送器不須要屬性的定義，但能夠在其內部定義一個Transport元素。

1三、Transport

      用於Sender內部，配置數據如何發送至集羣中的其它節點。Tomcat有兩種Transport的實現：

1) 、PooledMultiSender

      基於Java阻塞式IO，能夠將一次將多個信息併發發送至其它節點，但一次只能傳送給一個節點。

2)、PooledParallelSener

      基於Java非阻塞式IO，即NIO，能夠一次發送多個信息至一個或多個節點。

1四、Receiver

       用於Channel定義某節點如何從其它節點的Sender接收復制數據，Tomcat中實現的接收方式有兩種BioReceiver和NioReceiver。

轉發地址：http://www.javashuo.com/article/p-tqhjmmro-a.html