概述

集群和分布式都是從集中式進(jìn)化而來的。分布式和集群會相互合作的，同時(shí)的集群和分布式。在這里重點(diǎn)說說集群

集群是什么？

集群能提高單位時(shí)間內(nèi)處理的任務(wù)數(shù)量，提升服務(wù)器性能
有多臺服務(wù)器去處理任務(wù)，但是每個(gè)任務(wù)都是由一臺服務(wù)器獨(dú)立完成的

分布式是什么？

分布式能縮短單個(gè)任務(wù)處理的時(shí)間
跟集群一樣，也有多臺服務(wù)器去處理任務(wù)，但是每個(gè)任務(wù)由多臺服務(wù)器合作完成，每臺服務(wù)器負(fù)責(zé)完成大任務(wù)中的一個(gè)小任務(wù)

集中式是什么？

集中式就是最傳統(tǒng)的那種，所有任務(wù)由一臺大機(jī)完成

集群場景

可以在一臺物理服務(wù)器上集群多個(gè)應(yīng)用服務(wù)器，每個(gè)應(yīng)用服務(wù)器獨(dú)立工作。再在前端分配一個(gè)中央控制服務(wù)器，負(fù)責(zé)把發(fā)送到這臺物理服務(wù)器的請求，按照一定權(quán)重分發(fā)給各個(gè)應(yīng)用服務(wù)器。

例子

以tomcat為例子，可以采用1*apache+N*tomcat的模式
apache作為門面，在前端用負(fù)載均衡把請求發(fā)給各個(gè)tomcat服務(wù)器

好處

通常集群32位的服務(wù)器來代替單個(gè)64位的服務(wù)器，這樣能盡量發(fā)揮出硬件的性能

1. 在64位的程序中，由于指針膨脹以及內(nèi)存對齊，會造成內(nèi)存浪費(fèi)。
2. 在單個(gè)64位的服務(wù)器宕機(jī)的時(shí)候，所產(chǎn)生的快照很大，不好分析
3. 大內(nèi)存的服務(wù)器，意味著要對更大的內(nèi)存區(qū)域進(jìn)行垃圾收集，那么會增大GC的時(shí)間，會加長服務(wù)器的停頓

難點(diǎn)

由于http請求是無狀態(tài)的，那么對于會話級別的事務(wù)，如何保持用戶的狀態(tài)？
在單個(gè)服務(wù)器中，提供了session-sessionID的機(jī)制來保存用戶的狀態(tài)
那么現(xiàn)在有多臺服務(wù)器，如何記錄用戶的狀態(tài)？
有兩個(gè)大方向：

1. session粘性
2. 共享session

session粘性

這種方式也成為親和式集群，給session創(chuàng)造粘性，意思是讓用戶每次都訪問的同一個(gè)應(yīng)用服務(wù)器
這樣就要在前端服務(wù)器apache中記錄下，用戶首次訪問的是哪個(gè)tomcat，將用戶后面發(fā)送的請求都發(fā)送到這個(gè)tomcat上去
這樣帶來的后果是，各個(gè)服務(wù)器負(fù)載不均衡，因?yàn)橹辉谟脩羰状卧L問的時(shí)候，采用了負(fù)載均衡分發(fā)，但是這個(gè)影響也不會那么明顯

worker.controller.sticky_session=true|false
worker.controller.sticky_session_force=true|false

這是在apache對于session粘性的配置
worker.controller.sticky_session，為true會開啟session粘性機(jī)制，為false關(guān)閉
worker.controller.sticky_session_force，為true意味著即使這個(gè)服務(wù)器宕機(jī)了，也仍然發(fā)送到這個(gè)服務(wù)器，為false則會選擇發(fā)送其他到其他服務(wù)器
建議選擇前者為true，后者為false。這樣既能達(dá)到session粘性，又能在服務(wù)器宕機(jī)的時(shí)候繼續(xù)提供服務(wù)

優(yōu)點(diǎn)：

1. 占用的內(nèi)存少，因?yàn)橹挥涗浟藄essionID以及對應(yīng)發(fā)送的服務(wù)器

缺點(diǎn)：

1. 如果服務(wù)器宕機(jī)了，在這個(gè)服務(wù)器上的session信息都會丟失

同步session

這種方式需要在一個(gè)地方存放session的所有信息，并且能讓每個(gè)服務(wù)器節(jié)點(diǎn)都能訪問得到這些session
這種方式大概有三種方案：

1. cookie同步
2. 數(shù)據(jù)庫同步
3. 內(nèi)存數(shù)據(jù)庫同步

cookie同步

cookie同步是將session的所有信息存放在客戶端，每次請求的時(shí)候，將session也發(fā)送上來
優(yōu)點(diǎn)：

1. 不占用服務(wù)器內(nèi)存
2. 服務(wù)器宕機(jī)不會丟失session信息

缺點(diǎn)：

1. 放在客戶端，不安全
2. 受瀏覽器的限制，瀏覽器禁用cookie
3. 增大流量，變相拉低響應(yīng)時(shí)間
4. session序列化和反序列都需要額外的時(shí)間

數(shù)據(jù)庫同步

將session信息存放在一個(gè)都能訪問到的數(shù)據(jù)庫
優(yōu)點(diǎn)：

1. 服務(wù)器宕機(jī)不會丟失session信息

缺點(diǎn)：

1. 占用的內(nèi)存大
2. 增大數(shù)據(jù)庫負(fù)擔(dān)
3. session序列化和反序列都需要額外的時(shí)間
4. 訪問數(shù)據(jù)庫會需要額外的時(shí)間

內(nèi)存數(shù)據(jù)庫同步

將session信息存放在一個(gè)都能訪問到的內(nèi)存數(shù)據(jù)庫中，比如Redis、memcached
優(yōu)點(diǎn)：

1. 服務(wù)器宕機(jī)不會丟失session信息
2. 訪問的速度快

缺點(diǎn):

1. 占用內(nèi)存大
2. session序列化和反序列都需要額外的時(shí)間

總結(jié)

session同步最好的是第三種，內(nèi)存數(shù)據(jù)庫同步
session同步的好處是不怕單個(gè)服務(wù)器宕機(jī)，但是他占用的資源、速度也比session粘性要大

缺點(diǎn)

1. 節(jié)點(diǎn)對共享資源的競爭，如磁盤文件
2. 節(jié)點(diǎn)對同一資源進(jìn)行操作帶來的問題，如對同一文件進(jìn)行讀寫
3. 32位的節(jié)點(diǎn)受最大內(nèi)存的限制
4. 節(jié)點(diǎn)內(nèi)資源池的閑置。如連接池，可能會出現(xiàn)某些節(jié)點(diǎn)的連接池用滿，某些節(jié)點(diǎn)還有可用連接。可以考慮配置同一資源池，集中式JNDI
5. 節(jié)點(diǎn)內(nèi)的本地緩存重復(fù)，因?yàn)槊糠莨?jié)點(diǎn)都有一份本地緩存。可以考慮采用緩存數(shù)據(jù)庫統(tǒng)一存放緩存，如redis
6. 浪費(fèi)內(nèi)存，節(jié)點(diǎn)越多，重復(fù)加載的類越多，jvm中的方法區(qū)內(nèi)容差不多，但是每個(gè)節(jié)點(diǎn)都有一份。