集群和分布式都是從集中式進(jìn)化而來的。分布式和集群會(huì)相互合作的,同時(shí)的集群和分布式。在這里重點(diǎn)說說集群
集群能提高單位時(shí)間內(nèi)處理的任務(wù)數(shù)量,提升服務(wù)器性能
有多臺(tái)服務(wù)器去處理任務(wù),但是每個(gè)任務(wù)都是由一臺(tái)服務(wù)器獨(dú)立完成的
分布式能縮短單個(gè)任務(wù)處理的時(shí)間
跟集群一樣,也有多臺(tái)服務(wù)器去處理任務(wù),但是每個(gè)任務(wù)由多臺(tái)服務(wù)器合作完成,每臺(tái)服務(wù)器負(fù)責(zé)完成大任務(wù)中的一個(gè)小任務(wù)
集中式就是最傳統(tǒng)的那種,所有任務(wù)由一臺(tái)大機(jī)完成
可以在一臺(tái)物理服務(wù)器上集群多個(gè)應(yīng)用服務(wù)器,每個(gè)應(yīng)用服務(wù)器獨(dú)立工作。再在前端分配一個(gè)中央控制服務(wù)器,負(fù)責(zé)把發(fā)送到這臺(tái)物理服務(wù)器的請(qǐng)求,按照一定權(quán)重分發(fā)給各個(gè)應(yīng)用服務(wù)器。
以tomcat為例子,可以采用1*apache+N*tomcat的模式
apache作為門面,在前端用負(fù)載均衡把請(qǐng)求發(fā)給各個(gè)tomcat服務(wù)器
通常集群32位的服務(wù)器來代替單個(gè)64位的服務(wù)器,這樣能盡量發(fā)揮出硬件的性能
由于http請(qǐng)求是無狀態(tài)的,那么對(duì)于會(huì)話級(jí)別的事務(wù),如何保持用戶的狀態(tài)?
在單個(gè)服務(wù)器中,提供了session-sessionID的機(jī)制來保存用戶的狀態(tài)
那么現(xiàn)在有多臺(tái)服務(wù)器,如何記錄用戶的狀態(tài)?
有兩個(gè)大方向:
這種方式也成為親和式集群,給session創(chuàng)造粘性,意思是讓用戶每次都訪問的同一個(gè)應(yīng)用服務(wù)器
這樣就要在前端服務(wù)器apache中記錄下,用戶首次訪問的是哪個(gè)tomcat,將用戶后面發(fā)送的請(qǐng)求都發(fā)送到這個(gè)tomcat上去
這樣帶來的后果是,各個(gè)服務(wù)器負(fù)載不均衡,因?yàn)橹辉谟脩羰状卧L問的時(shí)候,采用了負(fù)載均衡分發(fā),但是這個(gè)影響也不會(huì)那么明顯
worker.controller.sticky_session=true|falseworker.controller.sticky_session_force=true|false
這是在apache對(duì)于session粘性的配置
worker.controller.sticky_session,為true會(huì)開啟session粘性機(jī)制,為false關(guān)閉
worker.controller.sticky_session_force,為true意味著即使這個(gè)服務(wù)器宕機(jī)了,也仍然發(fā)送到這個(gè)服務(wù)器,為false則會(huì)選擇發(fā)送其他到其他服務(wù)器
建議選擇前者為true,后者為false。這樣既能達(dá)到session粘性,又能在服務(wù)器宕機(jī)的時(shí)候繼續(xù)提供服務(wù)
優(yōu)點(diǎn):
缺點(diǎn):
這種方式需要在一個(gè)地方存放session的所有信息,并且能讓每個(gè)服務(wù)器節(jié)點(diǎn)都能訪問得到這些session
這種方式大概有三種方案:
cookie同步是將session的所有信息存放在客戶端,每次請(qǐng)求的時(shí)候,將session也發(fā)送上來
優(yōu)點(diǎn):
缺點(diǎn):
將session信息存放在一個(gè)都能訪問到的數(shù)據(jù)庫(kù)
優(yōu)點(diǎn):
缺點(diǎn):
將session信息存放在一個(gè)都能訪問到的內(nèi)存數(shù)據(jù)庫(kù)中,比如Redis、memcached
優(yōu)點(diǎn):
缺點(diǎn):
session同步最好的是第三種,內(nèi)存數(shù)據(jù)庫(kù)同步
session同步的好處是不怕單個(gè)服務(wù)器宕機(jī),但是他占用的資源、速度也比session粘性要大
聯(lián)系客服