Tomcat集群快速入门
生活随笔
收集整理的這篇文章主要介紹了
Tomcat集群快速入门
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
這一節我們學習tomcat集群,這一節非常重要,請大家仔細認真學習,首先我們看一下目錄,會領著大家一起回顧一下,第一期的tomcat配置,然后是mac和linux下的,還有一個windows下的,然后再回顧一下第一期的nginx配置,簡要回顧,首先我們思考第一個問題,tomcat集群后能帶來什么,然后是tomcat集群后的實現原理,還有tomcat集群新舊架構的對比解析,第一期我們是單服務器,單tomcat,而二期我們要用tomcat集群了,會領著大家一起把架構進行一個對比和分析,然后再思考一個問題,tomcat集群帶來了什么新問題,后邊會詳細的給大家一起來學習
然后講一下tomcat單擊部署多應用,多機部署多應用,什么意思呢,單機部署多應用就是說,我有一臺服務器,在這臺服務器上,我開多個tomcat實例,那我們課程開兩個,當然多個的方法也有講,大家認真聽講肯定能搞定,多機部署多應用呢,就是說假設我有A,B,C三條服務器,然后我在A,B,C這三臺服務器上,每一個機器安裝了一個tomcat,然后把這三臺做成一個集群,對于學習來說,單機部署多應用,更富有挑戰性,而且考慮到大家并沒有那么多電腦,開多個虛擬機電腦也容易卡,在阿里云購買多個阿里云服務器的時候,畢竟還要付出一定的成本,我們會重點講一下nginx的一些配置,策略,場景及特點,這點非常重要,前兩個講完之后,就會講nginx+tomcat集群,然后就是tomcat集群的驗證,目錄雖然少,但是干貨非常多,我們一起來往下看
tomcat集群能帶來什么,挑重要的兩句話來講,這兩句話就是,第一提高服務的性能,并發能力,以及高可用性,當然實際公司的線上環境,都會選擇一臺機器部署一個tomcat,畢竟一個機器部署一個tomcat,他們還是有共享瓶頸的,如他們的網卡公用一個,他們的內存是公用的,他們的磁盤IO等等性能,那么在實際的生產環境呢,會把他們進行一個隔離,一臺機器部署一個tomcat,并發能力很簡單,一臺tomcat的http線程池,是有限的,根據你機器的性能,那兩臺我能承載的,http線程就變成了二倍,高可用性這個也非常好理解,什么叫高可用呢,那簡單理解,nginx下面掛了多臺tomcat,當tomcat1掛掉的時候,我們可以把這個節點,從nginx負載均衡,tomcat集群的配置當中摘掉,ngxin還會搭到可用的tomcat服務器上,并不影響我們提供的服務器,tomcat就能帶來一定的可用性,第二個非常重要,提供項目架構的橫向擴展能力,如何理解橫向擴展能力,假設我又一臺服務器,我通過不斷地升級他的內存,CPU換成固態硬盤,這種我們認為是一種縱向,縱向提高機器的配置,來達到提高tomcat所提供服務的一個性能,那隨著硬件的不斷提高,其實這個成本是上升的,這個在一期架構演進上,有講,那tomcat能帶來一個橫向擴展能力,很簡單,打個比方,例如說天貓的雙十一,雙十一是一個非常重要的,對于天貓來說,平時的訪問量可能沒有那么高,那雙十一的時候,訪問量是非常的高,tomcat集群OK之后呢,我們就可以做一個橫向擴展,只要去加tomcat節點,就可以了,根據實際的數據,以及對歷史數據做一個評估,當然這個還有一定的動態能力,就是說我根據實際情況,動態的增加幾個節點,讓nginx進行一個熱部署,就把新增的節點加入到這個節點當中,這兩點很重要,大家好好理解這兩點,我們繼續
我們繼續,tomcat集群實現的原理,咱們課程一定是本著最簡單的學習,來學習復雜的知識,所以一句話概括,我們通過nginx負載均衡,對多個tomcat,進行請求轉發,來實現我們二期的tomcat集群,接下來比較重要,開始進行新舊架構對比,一期架構和二期架構的對比,我們先看看一期的架構,上面三個圓圈,123代表用戶,他們訪問nginx,也就是說,nginx對外開放80端口,然后nginx把這個請求,轉發到下面的tomcat app server,然后我們部署到tomcat服務器上的javai項目呢,下面連著DB,右邊連著ftp file server,ftp服務器,在項目當中呢,提供圖片的上傳,下載,瀏覽等功能,然后有session,因為我們一臺服務器,所以session直接存在server里面,用的servlet原生的一個session,那這個時候,我們看一下,我們把tomcat進行橫向擴展的一個架構
我們把tomcat http server橫向擴展之后的架構,那就來到了想當然的二期架構,我們一起來看一下,user 1 2 3來請求server,就是說nginx,然后nginx進行一個load balance,負載均衡,然后下邊掛著三個節點,三個tomcat,下面連著DB,右側呢,是ftp file server,這個時候,我來提問一個問題,大家想一下,user1順著這個路徑往下找,他請求了web server,然后負載均衡到第一臺web server上,那這個請求呢,是登陸請求,登陸請求,他把session信息存在第一臺tomcat上,user1的登陸信息,存到了這里,user1這個時候呢,發起下單,生成訂單,我們的邏輯是說,想生成訂單之前,必須是已登錄狀態,而它這一次請求,生成的訂單,通過web server,也就是nginx,請求到了第二臺tomcat上,這個session并沒有user1的登陸信息,它會讓user1重新登陸,那其實已經中斷了我們的下單流程,從用戶體驗上呢,user1其實是已經登陸了,他不了解你下邊的技術原理實現,他總之會認為,我已經登陸了,為什么還要讓我登陸,那除非是user1這個用戶,所有的請求都達到第一臺tomcat上,那能保證這個流程是順暢的,這個的弊端,以及均衡的配置,后邊會有詳細的講,想當然二次架構就會出現這個問題,我們的session沒有共享,那我們要解決這個問題,我們繼續看
帶來了什么新問題,一句話,session登陸信息,存儲及讀取的問題,還有服務器定時任務并發的問題,咱們項目在下完訂單之后,如果沒有付款,需要自動關閉,自動關閉這個訂單,當然呢,會有一個定時器,他下單之后,多久沒有付款,然后來關閉這個訂單,并把庫存釋放出來,定時器假設我們配置的,是每分鐘跑一次,監聽這一分鐘,需要關閉的訂單,那我們的tomcat是多態服務器,一到這個時間點的時候,所有機器都啟動了這個定時任務,他們一起去讀取SQL,然后判斷訂單,這個是一個非常簡單的配置,首先我們這個邏輯非常的簡單,并不會造成線上的嚴重的故障,那如果遇到非常復雜的場景呢,非常容易造成我們線上的數據錯亂,并且該更新的更新不上,他們之間有一個競爭關系,這個是非常嚴重的,而且在查問題的時候呢,還不是太好查,然后是....,對于不同的場景會有很多的問題,這個要闡述什么呢,就是隨著我們項目架構的演進,從架構層面的變化,會引起代碼層面的變化,以及解決方案的變化,千萬不要想當然的認為,集群就是多部署幾個TOMCAT就OK了,這個都要根據實際的業務場景,去分析,去改變,去演進,所以大家在學這個課的時候,希望大家的思考力,思考問題的深度,廣度還有角度呢,都有所提高,我們不能再做單純的小白,希望大家學完這個課,從技術,思想,方面都有提高
我們看一下解決方案,如果單純的想解決登陸的問題,我們可以用nginx ip hash這么的一個策略,他的優點很簡單,就是可以不改變現有的技術架構,直接實現橫向擴展,兩個字,省事,也就是說,根據請求的IP,那user1有一個ip,他的ip進行一個hash取模,hash之后他指定到指定的服務器,那么這個ip發過來的請求,都會請求到這臺服務器上,當然呢他也有缺點,這種方式在實際的公司,生產環境用的是非常少的,他的缺點是什么呢,第一導致服務器請求,負載不平均,完全依賴hash ip的結果,很簡單我們用局限的思維簡單的考慮一下,假設有兩個人,這兩個人的服務器,ip hash之后,全部請求到第一臺tomcat上,那這個時候呢,假設就兩個人來訪問,而我們有兩個tomcat,那我們這個服務,對我們的用戶來說,tomcat2其實是沒用的,因為這兩個ip hash,只會請求到第一個tomcat上,一臺服務器使兩個請求都達到這里,另外一臺服務器閑的蛋疼,一個請求都沒有,那還有一個缺點,在IP變化的環境下,無法服務,如果你的網絡環境,IP經常變化,那我這次哈希到tomcat1上,過了一會又變化了,又hash到tomcat2上,那對于這個用戶來說,我們的服務無法給她提供一個正常的服務,在用戶體驗上呢,也是非常不好的,那我們來看一下,我們二期的真架構是什么樣的
這個圖一打眼看上去, 比一期的要復雜多了,但是聽我慢慢地給大家講,首先上面是用戶,這個是一個web server nginx,load balance,那http請求轉發呢,轉發到這三臺服務器上,tomcat app server,ABC ok,那下面還是DB,三條路徑來請求DB,右側請求一個ftp file server,這里要強調一下,架構絕對不是一蹴而就的,所以我們項目慢慢演進,高可用性也會不斷提高,例如文件服務器組成分布式的,我們nginx也會做一個集群,項目架構會一點點演進,并且呢隨著演進,會產生代碼的演進,這個過程,是彌足珍貴,并且是非常重要的,所以呢我們還是腳踏實地的,一步一步的來,先把我們二期課程,學明白,理解透,學精,然后我們來看一下左側,多了一個分布式的redis,session server,那tomcat abc,請求session的時候呢,全部指向這個分布式的redis session server,那就很容易理解了,user1請求過來,無論達到abc哪臺機器上,我都會把session信息,存儲到redis的session服務器當中,第二次請求無論打到任何一臺機器上,都會從這個分布式redis,session服務器當中,獲取他的登陸信息,因為我們做了分布式,redis的一個session server,所以我們還要做一個單點登陸,后面的章節就有講,然后我們還會利用這個分布式redis,做一個分布式鎖,來解決我們tomcat abc,在同一個時間點啟動,定時任務的一個問題,先不管他們會不會對數據或邏輯,造成問題,那么從另外一個角度,如果不去做分布式鎖的話,其實已經造成CPU內存的浪費,因為在同一個時間點,需要一臺機器啟動一個定時任務就可以了,其他機器不需要啟動,并且隨便那一臺都OK,那在線上的生產環境,由于請求對于某些業務邏輯,處理的一個放大,那其實我們一點點的優化,對整個架構都會有比較大的正向作用,那我們這一期會領著大家,搭建reids,然后呢,講一下redis的分布式原理,怎么用redis做一個分戶式鎖,還有講一下,redis的一個主從,希望我所講的一切,都被小伙伴們吸收百分之一百,那再說一點,如果是學過一期的小伙伴,之前肯定看過,如果是學過二期的小伙伴,也不用擔心,我有一個大型架構的一個演進,那個是一個文本總結,小伙伴們一定不要著急,架構都是一步一步來的,把tomcat進行集群之后,我們有很多的點需要進行修改,優化,提高,慢慢的包括隊列
?
總結
以上是生活随笔為你收集整理的Tomcat集群快速入门的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Redis分布式锁原理解析
- 下一篇: Tomcat集群快速入门2