為什么要使用集群？主要有兩方面原因：一是對于一些核心系統(tǒng)要求長期不能中斷服務(wù)，為了提供高可用性我們需要由多臺(tái)機(jī)器組成的集群；另外一方面，隨著訪問量越來越大且業(yè)務(wù)邏輯越來越復(fù)雜，單臺(tái)機(jī)器的處理能力已經(jīng)不足以處理如此多且復(fù)雜的邏輯，于是需要增加若干臺(tái)機(jī)器使整個(gè)服務(wù)處理能力得到提升。
如果說一個(gè)web應(yīng)用不涉及會(huì)話的話，那么做集群是相當(dāng)簡單的，因?yàn)楣?jié)點(diǎn)都是無狀態(tài)的，集群內(nèi)各個(gè)節(jié)點(diǎn)無需互相通信，只需要將各個(gè)請求均勻分配到集群節(jié)點(diǎn)即可。但基本所有web應(yīng)用都會(huì)使用會(huì)話機(jī)制，所以做web應(yīng)用集群時(shí)整個(gè)難點(diǎn)在于會(huì)話數(shù)據(jù)的同步。
當(dāng)然你可以通過一些策略規(guī)避復(fù)雜的額數(shù)據(jù)同步操作，例如前面說到的把會(huì)話信息保存在分布式緩存或數(shù)據(jù)庫中統(tǒng)一集中管理，如下圖，每個(gè)tomcat實(shí)例只需去寫入或讀取數(shù)據(jù)庫即可，避免了tomcat集群之間的通信。但這種方式也有不足，要額外引入數(shù)據(jù)庫或緩存服務(wù)，同時(shí)也要保證它們的高可用性，增加了機(jī)器和維護(hù)成本。
全節(jié)點(diǎn)會(huì)話同步模型鑒于統(tǒng)一將會(huì)話存放到數(shù)據(jù)庫或緩存上存在的不足，提供另一種解決思路就是tomcat集群節(jié)點(diǎn)自身完成各自的數(shù)據(jù)同步，不管訪問到哪個(gè)節(jié)點(diǎn)都能找到對應(yīng)的會(huì)話，如下圖，客戶端第一次訪問生成會(huì)話，tomcat自身會(huì)將會(huì)話信息同步到其他節(jié)點(diǎn)上，而且是每次請求完成都會(huì)同步此次請求過程中對session的所有操作，這樣一來下一次請求到集群中任意節(jié)點(diǎn)都能找到響應(yīng)的會(huì)話信息，且能保證信息的及時(shí)性。而且任意一個(gè)節(jié)點(diǎn)宕掉了也不影響整體對外的服務(wù)。
會(huì)話備份單節(jié)點(diǎn)模型Tomcat提供的第二種集群會(huì)話管理的機(jī)制就是單節(jié)點(diǎn)備份機(jī)制，下面看看這種方式具體的工作機(jī)制，集群一般是通過負(fù)載均衡對外提供整體服務(wù)，所有節(jié)點(diǎn)被隱藏在后端組成一個(gè)整體。前面各種模式的實(shí)現(xiàn)都無需負(fù)載均衡協(xié)助，所以圖中都把負(fù)載均衡省略了。最常見的負(fù)載方式是前面用apache拖所有節(jié)點(diǎn)，它支持將類似“326257DA6DB76F8D2E38F2C4540D1DEA.tomcat1”的會(huì)話id進(jìn)行分解，定位到tomcat集群中以tomcat1命名的節(jié)點(diǎn)上（這種方式稱為Session Stick，由apache jk模塊實(shí)現(xiàn)）。每個(gè)會(huì)話存在一個(gè)原件和一個(gè)備份，且備份與原件不會(huì)保存在同一個(gè)節(jié)點(diǎn)上，如下圖，例如當(dāng)客戶端發(fā)起請求后通過負(fù)載均衡被分發(fā)到tomcat1實(shí)例節(jié)點(diǎn)上，生成一個(gè)包含.tomcat1后綴的會(huì)話標(biāo)識，并且tomcat1節(jié)點(diǎn)根據(jù)一定策略選出此次會(huì)話對象備份的節(jié)點(diǎn)，然后將包含了{(lán)會(huì)話id，備份ip}的信息發(fā)送給tomcat2、tomcat3、tomcat4，如圖中虛線所示，這樣每個(gè)節(jié)點(diǎn)都有一個(gè)會(huì)話id、備份ip列表，即每個(gè)節(jié)點(diǎn)都有每個(gè)會(huì)話的備份ip地址。
完成上面一步后就是將會(huì)話內(nèi)容備份到備份節(jié)點(diǎn)上，假如tomcat1的s1、s2兩個(gè)會(huì)話的備份地址為tomcat2，則把會(huì)話對象備份到tomcat2中，類似的有tomcat2把s3會(huì)話備份到tomcat4，tomcat4把s4、s5兩個(gè)對話備份到tomcat3，這樣集群中所有的會(huì)話都已經(jīng)有了一份備份。當(dāng)tomcat1一直不出故障，由于Session Stick技術(shù)客戶端將一直訪問到tomcat1節(jié)點(diǎn)上，保證一直能獲取到會(huì)話。而當(dāng)tomcat1出故障了，這時(shí)tomcat也提供了一個(gè)failover機(jī)制，apache感知到后端集群tomcat1節(jié)點(diǎn)被移除了，這時(shí)它會(huì)把請求隨機(jī)分配到其他任意節(jié)點(diǎn)上，接下去會(huì)有兩種情況：
①剛好分到了備份節(jié)點(diǎn)tomcat2上，此時(shí)仍能獲取到s1會(huì)話，除此之外，tomcat2還要另外做的事是將這個(gè)s1會(huì)話標(biāo)記為原件且繼續(xù)選取一個(gè)備份地址備份s1會(huì)話，這樣一來又有了備份。
②假如分到了非備份節(jié)點(diǎn)tomcat3，此時(shí)肯定找不到s1會(huì)話，于是它將向集群所有節(jié)點(diǎn)發(fā)問，“請問誰有s1會(huì)話的備份ip地址信息？”，因?yàn)橹挥衪omcat2有s1的備份地址信息，它接收到詢問后應(yīng)答告知tomcat3節(jié)點(diǎn)s1會(huì)話的備份在tomcat2，根據(jù)這個(gè)信息就能查到s1會(huì)話了，并且tomcat3在自己本地生成s1會(huì)話并標(biāo)為原件，tomcat2上的副本不變，這樣一來同樣能找到s1會(huì)話，正常完整整個(gè)請求處理。
生產(chǎn)部署選型以上兩種模型都有各自的優(yōu)缺點(diǎn)，在實(shí)際生產(chǎn)上部署應(yīng)該根據(jù)實(shí)際情況選擇適合的模型。
對于全節(jié)點(diǎn)會(huì)話同步模型
細(xì)看很容易發(fā)現(xiàn)集群的節(jié)點(diǎn)之間的會(huì)話是兩兩互相復(fù)制的，一旦集群節(jié)點(diǎn)數(shù)量及訪問量大起來，將導(dǎo)致大量的會(huì)話信息需要互相復(fù)制同步，很容易導(dǎo)致網(wǎng)絡(luò)阻塞，而且這些同步操作很可能會(huì)成為整體性能的瓶頸，根據(jù)經(jīng)驗(yàn)，此種方案在實(shí)際生產(chǎn)上推薦的集群節(jié)點(diǎn)個(gè)數(shù)為3-6個(gè)，它無法組建更大的集群，而且冗余了大量的數(shù)據(jù)，利用率較低。
對于集群增量會(huì)話管理器，可通過配置server.xml文件使用它，在tomcat中使用集群模式需要在
對于會(huì)話備份模型
針對上面全節(jié)點(diǎn)會(huì)話同步模型的網(wǎng)絡(luò)流量隨節(jié)點(diǎn)數(shù)量增加呈平方趨勢增長的問題，也正是因?yàn)檫@個(gè)因素導(dǎo)致無法構(gòu)建較大規(guī)模的集群，為了使集群節(jié)點(diǎn)能更加大，首要解決的就是數(shù)據(jù)復(fù)制時(shí)流量增長的問題，tomcat提出會(huì)話備份模型對前面的模型進(jìn)行優(yōu)化，它使會(huì)話備份的網(wǎng)絡(luò)流量隨節(jié)點(diǎn)數(shù)量的增加呈線性趨勢增長，每個(gè)會(huì)話只會(huì)有一個(gè)備份，大大減少了網(wǎng)絡(luò)流量和邏輯操作，此模型可構(gòu)建較大的集群。生產(chǎn)上可以組成十個(gè)以上的節(jié)點(diǎn)作為一個(gè)集群。
對于集群備份會(huì)話管理器，可通過配置server.xml文件使用它，它的配置與DeltaManager的配置基本相似，在
重慶分公司
重慶分公司
