目錄
一.故事背景
二.Tomcat概述
1、Tomcat介紹
2、Tomcat歷史
二、Tomcat原理分析
1、Http工作原理
2、Tomcat整體架構
3、Coyote連接器架構
4、Catalina容器架構
5、Jasper處理流程
6、JSP編譯過程
7、Tomcat啟動流程
8、Tomcat請求處理流程
三、Tomcat安裝與配置
擴充知識:類與對象
四、Tomcat配置文件詳解
1.配置文件目錄
2.server.xml 詳解
Server
Listener
Service
Connector
executor
Engine
Host ??
Context
3.web.xml
歡迎頁面配置
4.context.xml
?5.tomcat-users.xml
6.拓展,查看server status
五、Tomcat高可用項目
1、項目概述
2、設計構架圖
3、實施流程
4.動靜分離
5.如何解決session共享問題
六.總結
一.故事背景
在學習完nginx后,本節課將會帶領了解tomcat的相關介紹,作為之后學習數據庫的過渡內容,接下來將講解tomcat。
二.Tomcat概述
1、Tomcat介紹
Tomcat是Apache 軟件基金會(Apache Software Foundation)的Jakarta 項目中的一個核心項目,由Apache、Sun 和其他一些公司及個人共同開發而成。由于有了Sun 的參與和支持,最新的Servlet 和JSP 規范總是能在Tomcat 中得到體現,Tomcat 5支持最新的Servlet 2.4 和JSP 2.0 規范。因為Tomcat 技術先進、性能穩定,而且免費,因而深受Java 愛好者的喜愛并得到了部分軟件開發商的認可,成為目前比較流行的Web 應用服務器。
Tomcat 服務器是一個免費的開放源代碼的Web 應用服務器,屬于輕量級應用服務器,在中小型系統和并發訪問用戶不是很多的場合下被普遍使用,是開發和調試JSP 程序的首選。對于一個初學者來說,可以這樣認為,當在一臺機器上配置好Apache 服務器,可利用它響應HTML(標準通用標記語言下的一個應用)頁面的訪問請求。實際上Tomcat是Apache 服務器的擴展,但運行時它是獨立運行的,所以當你運行tomcat 時,它實際上作為一個與Apache 獨立的進程單獨運行的。
2、Tomcat歷史
-
Tomcat 最初由Sun公司的軟件架構師 James Duncan Davidson 開發,名稱為“JavaWebServer”。
-
1999年,在 Davidson 的幫助下,該項目于1999年于apache軟件基金會旗下的JServ項目合并,并發布第一個版本(3.x),即是現在的Tomcat,該版本實現了Servlet2.2和JSP 1.1規范 。
-
2001年,Tomcat 發布了4.0版本, 作為里程碑式的版本,Tomcat 完全重新設計了其架構,并實現了Servlet 2.3和JSP 1.2規范。
-
目前 Tomcat 已經更新到 10.0.x版本,但是目前企業中的Tomcat服務器,主流版本還是7.x 和 8.x,所以本課程是基于 8.5 版本進行講解。
二、Tomcat原理分析
1、Http工作原理
HTTP協議(超文本傳輸協議)是瀏覽器與服務器之間的數據傳送協議。作為應用層協議,HTTP是基于TCP/IP協議來傳遞數據的(HTML文件、圖片、查詢結果等),HTTP協議不涉及數據包(Packet)傳輸,主要規定了客戶端和服務器之間的通信格式。它的整個過程如下圖所示:
-
用戶通過瀏覽器進行了一個操作,比如輸入網址并回車,或者是點擊鏈接,接著瀏覽器獲取了這個事件。
-
瀏覽器向服務端發出TCP連接請求。
-
服務程序接受瀏覽器的連接請求并經過TCP三次握手建立連接。
-
瀏覽器將請求數據打包成一個HTTP協議格式的數據包。
-
瀏覽器將該數據包推入網絡,數據包經過網絡傳輸,最終達到端服務程序。
-
服務端程序拿到這個數據包后,同樣以HTTP協議格式解包,獲取到客戶端的意圖。
-
得知客戶端意圖后進行處理,比如提供靜態文件或者調用服務端程序獲得動態結果。
-
服務器將響應結果(可能是HTML或者圖片等)按照HTTP協議格式打包。
-
服務器將響應數據包推入網絡,數據包經過網絡傳輸最終達到到瀏覽器。
-
瀏覽器拿到數據包后,以HTTP協議的格式解包,然后解析數據,假設這里的數據是 HTML。
-
瀏覽器將HTML文件展示在頁面上。
2、Tomcat整體架構
Tomcat要實現兩個核心功能:
-
處理Socket連接,負責網絡字節流與Request和Response對象的轉化。
-
加載和管理Servlet,以及具體處理Request請求。
因此Tomcat設計了兩個核心組件連接器(Connector)和容器(Container)來分別做這 兩件事情。連接器負責對外交流,容器負責內部處理。
3、Coyote連接器架構
Coyote是Tomcat的連接器框架的名稱 , 是Tomcat服務器提供的供客戶端訪問的外部接口。客戶端通過Coyote與服務器建立連接、發送請求并接受響應 。
Coyote封裝了底層的網絡通信(Socket請求及響應處理),為Catalina容器提供了統一的接口,使Catalina容器與具體的請求協議及IO操作方式完全解耦。Coyote 將Socket輸入轉換封裝為Request對象,交由Catalina容器進行處理,處理請求完成后,Catalina通過Coyote提供的Response對象將結果寫入輸出流 。
Coyote作為獨立的模塊,只負責具體協議和IO的相關操作,與Servlet規范實現沒有直接關系,因此即便是Request和Response對象也并未實現Servlet規范對應的接口, 而是在Catalina中將他們進一步封裝為ServletRequest和ServletResponse。
在Coyote中,Tomcat支持的IO模型
IO模型 | 描述 |
---|---|
NIO | 非阻塞I/O,采用Java NIO類庫實現。 |
NIO2 | 異步I/O,采用JDK 7最新的NIO2類庫實現。 |
APR | 采用Apache可移植運行庫實現,是C/C++編寫的本地庫。如果選擇該方案,需要單獨安裝APR庫。 |
在Coyote中,Tomcat支持的應用層協議
應用層協議 | 描述 |
---|---|
HTTP/1.1 | 這是大部分Web應用采用的訪問協議。 |
AJP/1.3 | 用于和Web服務器集成(如Apache),以實現對靜態資源的優化以及集群部署。 |
HTTP/2 | HTTP 2.0大幅度的提升了Web性能。下一代HTTP協議 , 自8.5以及9.0版本之后支持。 |
協議分層 ?
在8.0之前,Tomcat 默認采用的I/O方式為 BIO,之后改為 NIO。 無論 NIO、NIO2還是 APR,在性能方面均優于以往的BIO。 如果采用APR,甚至可以達到 Apache HTTP Server的影響性能。
Tomcat為了實現支持多種I/O模型和應用層協議,一個容器可能對接多個連接器,就好比一個房間有多個門。但是單獨的連接器或者容器都不能對外提供服務,需要把它們組裝起來才能工作,組裝后這個整體叫作Service組件。這里請你注意,Service本身沒有做什么重要的事情,只是在連接器和容器外面多包了一層,把它們組裝在一起。Tomcat內可能有多個Service,這樣的設計也是出于靈活性的考慮。通過在Tomcat中配置多個Service,可以實現通過不同的端口號來訪問同一臺機器上部署的不同應用。
Coyote的主要組件結構:
Coyote的各個組件的作用:
-
EndPoint:Coyote 通信端點,即通信監聽的接口,是具體Socket接收和發送處理器,是對傳輸層的抽象,因此EndPoint用來實現TCP/IP協議的。Tomcat 并沒有EndPoint接口,而是提供了一個抽象類AbstractEndpoint,里面定義了兩個內部類:Acceptor和SocketProcessor。Acceptor用于監聽Socket連接請求。SocketProcessor用于處理接收到的Socket請求,它實現Runnable接口,在Run方法里調用協議處理組件Processor進行處理。為了提高處理力,SocketProcessor被提交到線程池來執行,而這個線程池叫作執行器(Executor)。
-
Processor:Coyote 協議處理接口,如果說EndPoint是用來實現TCP/IP協議的,那么Processor用來實現HTTP協議,Processor接收來自EndPoint的Socket,讀取字節流解析成Tomcat Request和Response對象,并通過Adapter將其提交到容器處理,Processor是對應用層協議的抽象。
-
ProtocolHandler:Coyote 協議接口,通過Endpoint和Processor,實現針對具體協議的處理能力。Tomcat按照協議和I/O 提供了6個實現類 : AjpNioProtocol、AjpNio2Protocol、AjpAprProtocol、Http11NioProtocol、Http11Nio2Protocol、Http11AprProtocol。我們在配置tomcat / conf / server.xml時,至少要指定具體的ProtocolHandler , 當然也可以指定協議名稱,如:HTTP/1.1,如果安裝了APR,那么將使用Http11AprProtocol,否則使用 Http11NioProtocol 。
-
Adapter:由于協議不同,客戶端發過來的請求信息也不盡相同,Tomcat定義了自己的Request類 來“存放”這些請求信息。ProtocolHandler接口負責解析請求并生成Tomcat Request類。 但是這個Request對象不是標準的ServletRequest,也就意味著,不能用Tomcat Request作為參數來調用容器。Tomcat設計者的解決方案是引入CoyoteAdapter,這是 適配器模式的經典運用,連接器調用CoyoteAdapter的Sevice方法,傳入的是Tomcat Request對象,CoyoteAdapter負責將Tomcat Request轉成ServletRequest,再調用容器的Service方法。
4、Catalina容器架構
Tomcat的模塊分層結構
Tomcat本質上就是一款 Servlet 容器,因此Catalina 才是 Tomcat 的核心,其他模塊都是為Catalina提供支撐的。比如:通過Coyote模塊提供連接通信,Jasper 模塊提供JSP引擎,Naming 提供JNDI 服務,Juli提供日志服務。
Catalina的主要組件結構
Catalina的各個組件的作用
-
Catalina
負責解析Tomcat的配置文件 , 以此來創建服務器Server組件,并根據 命令來對其進行管理。
-
Server
服務器表示整個Catalina Servlet容器以及其它組件,負責組裝并啟動Servlet引擎、Tomcat連接器。Server通過實現Lifecycle接口,提供了 一種優雅的啟動和關閉整個系統的方式。
-
Service
服務是Server內部的組件,一個Server包含多個Service。它將若干個Connector組件綁定到一個Container(Engine)上。
-
Connector
連接器主要是處理與客戶端的通信,它負責接收客戶請求,然后轉給相關的容器處理,最后向客戶返回響應結果。
-
Container
容器負責處理用戶的Servlet請求,并返回對象給web用戶的模塊。
Container的主要組件結構
Tomcat設計了4種容器,分別是Engine、Host、Context和Wrapper。這4種容器不是平行關系,而是父子關系。Tomcat通過一種分層的架構,使得Servlet容器具有很好的靈活性。
Container的各個組件的作用:
-
Engine
表示整個Catalina的Servlet引擎,用來管理多個虛擬站點,一個Service最多只能有一個Engine,但是一個引擎可包含多個Host。
-
Host
代表一個虛擬主機或者說一個站點,可以給Tomcat配置多個虛擬主機地址,而一個虛擬主機下可包含多個Context。
-
Context
表示一個Web應用程序, 一個Web應用可包含多個Wrapper。
-
Wrapper
表示一個Servlet,Wrapper 作為容器中的最底層,不能包含子容器。
我們也可以再通過Tomcat的server.xml配置文件來加深對Tomcat容器的理解。Tomcat采用了組件化的設計,它的構成組件都是可配置的,其中最外層的是Server,其他組件按照一定的格式要求配置在這個頂層容器中。
<Server> <!-- 頂級元素,代表整個Tomcat實例 --><Service> <!-- 服務組件,關聯連接器和引擎 --><Connector/> <!-- 接收外部請求的連接器(HTTP/HTTPS/AJP) --><Engine> <!-- 請求處理引擎,包含多個虛擬主機 --><Realm/> <!-- 安全認證域 --><Host> <!-- 虛擬主機配置 --><Context/> <!-- Web應用配置(通常不推薦直接在此配置) --><Valve/> <!-- 攔截器,用于日志、IP過濾等 --></Host></Engine></service>
</Server>
那么,Tomcat是怎么管理這些容器的呢?你會發現這些容器具有父子關系,形成一個樹形結構,你可能馬上就想到了設計模式中的組合模式。沒錯,Tomcat就是用組合模式來管理這些容器的。具體實現方法是,所有容器組件都實現了Container接口,因此組合模式可以使得用戶對單容器對象和組合容器對象的使用具有一致性。這里單容器對象指的是最底層的Wrapper,組合容器對象指的是上面的Context、Host或者Engine。
5、Jasper處理流程
Tomcat在默認的web.xml中配置了一個org.apache.jasper.servlet.JspServlet,用于處理所有的.jsp或 .jspx結尾的請求,該Servlet 實現即是運行時編譯的入口。
<servlet><servlet-name>jsp</servlet-name><servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class><init-param><param-name>fork</param-name><param-value>false</param-value></init-param><init-param><param-name>xpoweredBy</param-name><param-value>false</param-value></init-param><load-on-startup>3</load-on-startup>
</servlet>
<servlet-mapping><servlet-name>jsp</servlet-name><url-pattern>*.jsp</url-pattern><url-pattern>*.jspx</url-pattern>
</servlet-mapping>
JspServlet 處理流程圖
如果在 tomcat/conf/web.xml 中配置了參數scratchdir,則jsp編譯后的結果,就會存儲在該目錄下 .如果沒有配置該選項,則會將編譯后的結果,存儲在Tomcat安裝目錄下的 work/Catalina(Engine名稱)/localhost(Host名稱)/Context名稱 。
除了運行時編譯,我們還可以直接在Web應用啟動時, 一次性將Web應用中的所有的JSP頁面一次性編譯完成。在這種情況下,Web應用運行過程中,便可以不必再進行實時編譯,而是直接調用JSP頁面對應的Servlet完成請求處理, 從而提升系統性能。
Tomcat 提供了一個Shell程序JspC,用于支持JSP預編譯,而且在Tomcat的安裝目錄下提供了一個 catalina-tasks.xml 文件聲明了Tomcat 支持的Ant任務, 因此,我們很容易使用 Ant 來執行JSP 預編譯。(要想使用這種方式,必須得確保在此之前已經下載并安裝了Apache Ant)。
6、JSP編譯過程
Compiler 編譯工作主要包含代碼生成和編譯兩部分:
-
代碼生成
-
Compiler 通過一個 PageInfo 對象保存JSP 頁面編譯過程中的各種配置,這些配置可能來源于 Web 應用初始化參數, 也可能來源于JSP頁面的指令配置(如 page , include)。
-
調用ParserController 解析指令節點, 驗證其是否合法,同時將配置信息保存到 PageInfo 中, 用于控制代碼生成。
-
調用ParserController 解析整個頁面, 由于 JSP 是逐行解析, 所以對于每一行會創建一個具體的Node 對象。如靜態文本(TemplateText)、Java代碼(Scriptlet)、定制標簽(CustomTag)、Include指令(IncludeDirective)。
-
驗證除指令外其他所有節點的合法性, 如腳本、定制標簽、EL表達式等。
-
收集除指令外其他節點的頁面配置信息。
-
編譯并加載當前 JSP 頁面依賴的標簽。
-
對于JSP頁面的EL表達式,生成對應的映射函數。
-
生成JSP頁面對應的Servlet類源代碼 編譯 代碼生成完成后,Compiler還會生成 SMAP信息。 如果配置生成 SMAP信息,Compiler則會在編譯階段將SMAP信息寫到class文件中 。
-
編譯階段
-
Compiler的兩個實現 AntCompiler 和 JDTCompiler 分別調用先關框架的 API 進行源代碼編譯。
-
對于 AntCompiler 來說, 構造一個 Ant 的javac 的任務完成編譯。
-
對于 JDTCompiler 來說, 調用 org.eclipse.jdt.internal.compiler.Compiler 完成編譯。
7、Tomcat啟動流程
8、Tomcat請求處理流程
三、Tomcat安裝與配置
版本號以及適配的java版本:
解壓安裝tomcat
安裝Java
啟動tomcat和關閉tomcat
8080口用于接收http請求,8009用于接收ajp協議請求,8005是tomcat用于停止的端口?
擴充知識:類與對象
類:是抽象的概念集合,表示的是一個共性的產物,類之中定義的是屬性和行為(方法);
對象:對象是一種個性的表示,表示一個獨立的個體,每個對象擁有自己獨立的屬性,依靠屬性來區分不同對象。
可以寫一個簡單的腳本來啟動或關閉tomcat
四、Tomcat配置文件詳解
1.配置文件目錄
conf配置文件目錄
名稱 | 作用 |
Catalina | 監聽8080號端口的應用 |
catalina.properties catalina.policy | catalina的通用配置 |
jaspic-providers.xml | jaspic的配置文件 |
logging.properties | 登錄配置 |
server.xml | 服務的配置文件 |
context.xml | 安全上下文配置 |
tomcat-users.xml | tomcat的用戶配置 |
web.xml | web頁面的訪問配置 |
2.server.xml 詳解
Server
Server是server.xml的根元素,用于創建一個Server實例,默認使用的實現類是 org.apache.catalina.core.StandardServer。
port:關閉Tomcat的監聽端口(發送SHUTDOWN命令)
shutdown:關閉指令的密碼(自定義字符串 )
Listener
<!‐‐ 用于以日志形式輸出服務器 、操作系統、JVM的版本信息 ‐‐>
<Listener className="org.apache.catalina.startup.VersionLoggerListener" /><!‐‐ 用于加載(服務器啟動) 和 銷毀 (服務器停止) APR。 如果找不到APR庫, 則會輸出日志, 并不影響Tomcat啟動 ‐‐>
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /><!‐‐ 用于避免JRE內存泄漏問題 ‐‐>
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /><!‐‐ 用戶加載(服務器啟動) 和 銷毀(服務器停止) 全局命名服務 ‐‐>
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /><!‐‐ 用于在Context停止時重建Executor 池中的線程, 以避免ThreadLocal 相關的內存泄漏 ‐‐>
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
Service
該元素用于創建 Service 實例,默認使用 org.apache.catalina.core.StandardService。默認情況下,Tomcat 僅指定了Service 的名稱, 值為 “Catalina”。Service 可以內嵌的元素為 : Listener、Executor、Connector、Engine,其中 : Listener 用于為Service添加生命周期監聽器, Executor 用于配置Service 共享線程池,Connector 用于配置Service 包含的鏈接器, Engine 用于配置Service中鏈接器對應的Servlet 容器引擎。一個Server服務器,可以包含多個Service服務。
name :引擎名稱(默認Catalina)?
namePrefix:所創建的每個線程的名稱前綴,一個單獨的線程名稱為namePrefix+threadNumber。
?minSpareThreads:活躍線程數,也就是核心池線程數,這些線程不會被銷毀,會一直存在。
maxIdleTime:線程空閑時間,超過該時間后,空閑線程會被銷毀,默認值為6000(1分鐘),單位毫秒。 ?
maxQueueSize:在被執行前最大線程排隊數目,默認為Int的最大值,也就是廣義的無限。除非特殊情況,這個值不需要更改, 否則會有請求不會被處理的情況發生。 ?
prestartminSpareThreads:啟動線程池時是否啟動 minSpareThreads部分線程。 默認值為false,即不啟動。 ?
threadPriority:線程池中線程優先級,默認值為5,值從1到10。 ?
className:線程池實現類,未指定情況下,默認實現類為? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?????????????????????org.apache.catalina.core.StandardThreadExecutor。 如果想使用自定義線程池首先? ? ? ? ? ? ? ? ? ? ? ?需要實現 org.apache.catalina.Executor接口。 ?
maxThreads:最大線程數(默認200)?
Connector
Connector 用于創建鏈接器實例。默認情況下,server.xml 配置了兩個鏈接器,一個支持HTTP協議,一個支持AJP協議。因此大多數情況下,我們并不需要新增鏈接器配置, 只是根據需要對已有鏈接器進行優化。
protocol:協議類型(HTTP/1.1或自動適配org.apache.coyote.http11.Http11NioProtocol)
connectionTimeout:連接超時時間(毫秒ms)
redirectPort:HTTP請求強制跳轉HTTPS的端口
executor
指定共享線程池的名稱, 也可以通過maxThreads、minSpareThreads 等屬性配置內部線程池。 ?
?URIEncoding:用于指定編碼URI的字符編碼, Tomcat8.x版本默認的編碼為UTF-8 , Tomcat7.x版本默認為ISO-8859-1。
?acceptCount:接收的連接數。
?maxConnections:接收的最大連接數。
compression:啟用響應壓縮。?
compressionMinSize:壓縮的大小。 ?
disableUploadTimeout:禁用上傳超時。 ?
Engine
??Engine 作為Servlet 引擎的頂級元素,內部可以嵌入: Cluster、Listener、Realm、 Valve和Host。
defaultHost:默認虛擬主機名(如localhost)
acceptCount:等待隊列長度(當線程用完時)
<Realm>:安全認證域(用戶權限)
Host ??
Host 元素用于配置一個虛擬主機, 它支持以下嵌入元素:Alias、Cluster、Listener、Valve、Realm、Context。
如果在Engine下配置Realm, 那么此配置將在當前Engine下的所有Host中共享。 同樣,如果在Host中配置Realm , 則在當前Host下的所有Context中共享。
Context中的Realm優先級 > Host 的Realm優先級 > Engine中的Realm優先級。
?name:主機域名(如www.example.com)
?appBase:Web應用存放目錄(如webapps)
?unpackWARs:是否解壓WAR包(默認true)
autoDeploy:是否自動部署新應用(生產環境建議false)
Context
Context 用于配置一個Web應用
docBase:Web應用目錄或者War包的部署路徑。可以是絕對路徑,也可以是相對于Host appBase的相對路徑。 ?
path:Web應用的Context 路徑。 ?
pattern:日志格式(如%{yyyy-MM-dd HH:mm:ss}t %r %s %Dms 記錄響應時間)?
ROOT/中有默認訪問頁面(8080端口)的配置
打開tomcat后,訪問8080端口可得到頁面
3.web.xml
web.xml 是web應用的描述文件, 它支持的元素及屬性來自于Servlet 規范定義 。 在Tomcat 中, Web 應用的描述信息包括 tomcat/conf/web.xml 中默認配置以及 Web應用 WEB-INF/web.xml 下的定制配置。
param‐name:初始化參數名稱。
param‐value:初始化參數的值。
description:這個參數的描述信息。
-
servlet-name:你想要讓哪個servlet處理,這里就寫哪個servlet名稱。
-
url-pattern:用于指定URL表達式,一個 servlet‐mapping可以同時配置多個 url‐ pattern。
filter:
-
filter-name:用于指定過濾器名稱,在web.xml中,過濾器名稱必須唯一。
-
filter-class:過濾器的全限定類名,該類必須實現Filter接口。
-
async-supported:該過濾器是否支持異步。
-
init-param:用于配置Filter的初始化參數, 可以配置多個, 可以通過FilterConfig.getInitParameter獲取。
-
param-name:初始化參數名稱。
-
param-value:初始化參數的值。
-
filter-mapping:
-
filter-name:這里指的是你想使用哪個過濾器進行過濾就寫哪個過濾器的名稱。
-
url-pattern:指定該過濾器需要攔截的URL。
歡迎頁面配置
welcome-file-list 用于指定web應用的歡迎文件列表。嘗試請求的順序,從上到下。
session-timeout: 會話超時時間,單位:分鐘。
定義了文本類型
4.context.xml
安全上下文,定義了默認的源頁面
?5.tomcat-users.xml
role定義角色,user定義用戶,然后再讓用戶和角色綁定
admin-gui:用于控制頁面訪問權限。
admin-script:用于控制以簡單文本的形式進行訪問。
6.拓展,查看server status
登錄tomcat時,點擊這個按鈕會提醒
將中間的角色信息添加到tomcat-users.xml中
再回到上下文中增加允許訪問信息(/usr/local/tomcat8/webapps/manager/META-INF/context.xml)
再去/usr/local/tomcat8/webapps/host-manager/META-INF/context.xml添加相同信息
重啟tomcat,再次訪問頁面,點擊server status則會彈出登錄信息,填寫后成功登錄。
五、Tomcat高可用項目
1、項目概述
由于單臺Tomcat的承載能力是有限的,當我們的業務系統用戶量比較大,請求壓力比較大時,單臺Tomcat是扛不住的,這個時候,就需要搭建Tomcat的集群,而目前比較流程的做法就是通過Nginx來實現Tomcat集群的負載均衡。
2、設計構架圖
?
3、實施流程
192.168.71.152配置,先安裝tomcat和java
在192.168.71.151上修改/etc/nginx.conf文件,并重啟,此時訪問151時,出現tomcat界面
4.動靜分離
修改192.168.71.151nginx.conf文件如下
再在文件夾中加入圖片后,在151后加/圖片名稱可以訪問圖片
直接訪問192.168.71.151變成
訪問192.168.71.151/index.jsp則是
5.如何解決session共享問題
ip_hash 策略
通過修改Nginx配置文件,讓每個請求按訪問 ip 的 hash 結果分配,這樣每個訪客固定訪問一個后端服務器,可以解決 session 的問題。 例如:
upstream server_pool {
ip_hash:
server 192.168.71.149:80
server 192.168.71.152:80
}
六.總結
以上是tomcat的整體內容,對于一些配置文件的作用要了解,需要自己去了解一些tomcat的故障排查的運維案例,明白如何去處理tomcat出現的問題,熟練運用。