分布式session一致性問題

傳統(tǒng)的網(wǎng)站結(jié)構(gòu)（并發(fā)量不大，沒有session的不一致的問題。

傳統(tǒng)的網(wǎng)站結(jié)構(gòu)圖：

   **結(jié)論：**從圖中可以看出在傳統(tǒng)的網(wǎng)站結(jié)構(gòu)中，所有的客戶端都連接一個(gè)服務(wù)器，每個(gè)客戶端發(fā)送過來的請求都被該服務(wù)器處理，所以對于用戶來說session是一致的不存在改變。我們都知道服務(wù)器是通過cookie中的JSESSIONID來判斷該用戶的身份，所以在該用戶再發(fā)送其他請求是可以不需要驗(yàn)證的。但session也是有期限的，一但session過期用戶就得重新登陸?，F(xiàn)在有個(gè)問題要說的是如果用戶在同個(gè)瀏覽器打開兩個(gè)窗口session是否一致？其實(shí)服務(wù)器對用戶的判斷只是根據(jù)JSESSIONID ，它只認(rèn)這id其他的看都不看一樣，而我們又知道JSESSIONID又存在瀏覽器的cookie中，而同一瀏覽器打開兩個(gè)窗口是共用一個(gè)cookie，因此session有可能會(huì)從。（不排除特殊情況）。

瀏覽器禁用cookie，我們怎么傳SESSIONID呢？
答案：就是URL重寫，注意在URL重寫中的JSESSIONID的位置不是在？之后而是在？之前并且用；隔開。例如：http://127.0.0.1:8080/cookie/demo2.do;jsessionid=D2B0058380743E3731D50C49E6355144?age=12

分布式中session一致性問題

如圖
 結(jié)論：從圖中可以客戶端發(fā)送一個(gè)請求，經(jīng)過負(fù)載均衡后該請求會(huì)被分配到下列服務(wù)器中的任意一個(gè)，這時(shí)用戶驗(yàn)證了，如果用戶在發(fā)送一個(gè)請求，該請求被負(fù)載到了另一服務(wù)器上，此時(shí)檢查cookie中的sessionid 發(fā)現(xiàn)該服務(wù)器沒有，這是會(huì)出現(xiàn)用戶的登陸。像這樣每次請求每次驗(yàn)證肯定造成用戶的體驗(yàn)極差，所以解決分布式session一致問題極其重要。下面我就講講分布式session中的問題吧。

什么是負(fù)載均衡和反向代理？

什么是負(fù)載均衡？：

負(fù)載均衡：將客戶端的請求按照一定的規(guī)則分配到一群服務(wù)器中，并將處理結(jié)果返回個(gè)相應(yīng)的客戶端。

例如：上圖client 發(fā)送請求A經(jīng)過負(fù)載均衡（按照某一規(guī)則）分配到webserver1中，并且將請求的結(jié)果在返回客戶端。如果并發(fā)量大的時(shí)，負(fù)載均衡就會(huì)很好的控制服務(wù)端處理的任務(wù)量，避免一個(gè)服務(wù)器處理量大，一個(gè)處于空閑。

負(fù)載均衡的實(shí)現(xiàn)

• 基于硬件方面。（但實(shí)際不怎么考慮，成本太大）

• 基于軟件方面。（實(shí)際開發(fā)中應(yīng)用最多）。

什么是反向代理：
要明白反向代理首先就得明白什么是正向代理什么是反向代理：所謂正向代理就是內(nèi)網(wǎng)通過代理訪問外網(wǎng)，這個(gè)代理就是正向代理，而反向代理其實(shí)與正向代理剛好相反，就是外網(wǎng)通過代理訪問內(nèi)網(wǎng)，這種代理模式就是反向代理。從中我們不難發(fā)現(xiàn)反向代理時(shí)外網(wǎng)訪問內(nèi)網(wǎng)時(shí)根本不知道那個(gè)服務(wù)器提供的服務(wù)，給人的感覺就是好像連接一個(gè)服務(wù)器。
反向代理與負(fù)載均衡一樣，也是位于客戶端與服務(wù)器之間，客戶端向服務(wù)器發(fā)起的請求都是先經(jīng)過反向代理，然后分發(fā)到服務(wù)器上，然后服務(wù)器將返回結(jié)果交給反向代理，反向代理再交割客戶端。
二者的區(qū)別
最大的區(qū)別就是負(fù)載均衡只有在服務(wù)器大禹2臺的時(shí)候才有意義，其主要側(cè)重于將負(fù)載均衡到各個(gè)服務(wù)器上。

什么是會(huì)話保持，有什么作用

會(huì)話保持是指在負(fù)載均衡器上有一種機(jī)制，在作負(fù)載均衡的同時(shí)，還保持同一用戶相關(guān)連的請求會(huì)被分配到同一臺服務(wù)器上。

**會(huì)話保持的作用：**保證用戶發(fā)送的請求在一定時(shí)間會(huì)被同一臺服務(wù)器處理，而不是負(fù)載均衡到別的服務(wù)器。 所以會(huì)話保持有時(shí)間限制。如果只使用會(huì)話保持也不能解決session的問題，因此還的會(huì)話同步。

會(huì)話同步

網(wǎng)絡(luò)集群時(shí)會(huì)同步的3中方法
在做了網(wǎng)絡(luò)集群后，你肯定會(huì)首先考慮會(huì)話同步問題，因?yàn)橥ㄟ^負(fù)載均衡后，同一IP訪問同一頁面會(huì)被分配到不同的服務(wù)器上，如果會(huì)話不同步的話，一個(gè)登陸用戶，一會(huì)是登陸狀態(tài)，一會(huì)又不是登陸狀態(tài)。

• 1 利用數(shù)據(jù)庫同步會(huì)話（不常用）

在做多服務(wù)器會(huì)話同步時(shí)我沒有用這種方法，如果非要用這種方法的話，我想過二種方法： a，用一個(gè)低端電腦建個(gè)數(shù)據(jù)庫專門存放web服務(wù)器的會(huì)話，或者，把這個(gè)專門的數(shù)據(jù)庫建在文件服務(wù)器上，用戶訪問web服務(wù)器時(shí)，會(huì)去這個(gè)專門的數(shù)據(jù)庫檢查一下會(huì)話的情況，以達(dá)到會(huì)同步的目的 .b，這種方法是把存放會(huì)話的表和其他數(shù)據(jù)庫表放在一起，如果mysql也做了集群了話，每個(gè)MySQL的節(jié)點(diǎn)都要有這張表，并且這張會(huì)話表的數(shù)據(jù)表要實(shí)時(shí)同步。 說明：用數(shù) 庫來同步會(huì)話，會(huì)加大數(shù)據(jù)庫的負(fù)擔(dān)，數(shù)據(jù)庫本來就是容易產(chǎn)生瓶頸的地方，如果把會(huì)議還放到數(shù)據(jù)庫里面，無疑是雪上加霜。上面的二種方法，第一點(diǎn)方法較好，把放會(huì)話的表獨(dú)立開來，減輕了真正數(shù)據(jù)庫的負(fù)擔(dān)

• 2 利用cookie （cookie安全隱患）

同步會(huì)話是文件的形勢存放在服務(wù)器端的，cookie是文件的形勢存在客戶端的，怎么實(shí)現(xiàn)同步呢？方法很簡單，就是把用戶訪問頁面產(chǎn)生的會(huì)話放到cookie里面，就是以cookie為中轉(zhuǎn)站。你訪問網(wǎng)絡(luò)服務(wù)器A，產(chǎn)生了會(huì)話把它放到餅干里面了，你訪問被分配到網(wǎng)頁服務(wù)器B，這個(gè)時(shí)候，網(wǎng)絡(luò)服務(wù)器乙先判斷服務(wù)器有沒有這個(gè)會(huì)話，如果沒有，在去看看客戶端的餅干里面有沒有這個(gè)會(huì)議上，如果也沒有，說明會(huì)議真的不存，如果餅干里面有，就把餅干里面的sessoin同步到網(wǎng)絡(luò)服務(wù)器B，這樣就可以實(shí)現(xiàn)會(huì)話的同步了。

說明：這種方法實(shí)現(xiàn)起來簡單，方便，也不會(huì)加大數(shù)據(jù)庫的負(fù)擔(dān)，但是如果客戶端把餅干禁掉了的話，那么會(huì)議就無從同步了，這樣會(huì)給網(wǎng)站帶來損失;餅干的安全性不高，雖然它已經(jīng)加了密，但是還是可以偽造的。

• 3 利用memcache或者redis同步會(huì)話

memcache可以做分布式，如果沒有這功能，他也不能用來做會(huì)話同步。他可以把web服務(wù)器中的內(nèi)存組合起來，成為一個(gè)“內(nèi)存池”，不管是哪個(gè)服務(wù)器產(chǎn)生的sessoin都可以放到這個(gè)“內(nèi)存池”中，其他的都可以使用。

優(yōu)點(diǎn)：以這種方式來同步會(huì)話，不會(huì)加大數(shù)據(jù)庫的負(fù)擔(dān)，并且安全性比用餅干大大的提高，把會(huì)議放到內(nèi)存里面，比從文件中讀取要快很多。 缺點(diǎn)：內(nèi)存緩存把內(nèi)存分成很多種規(guī)格的存儲(chǔ)塊，有塊就有大小，這種方式也就決定了，內(nèi)存緩存不能完全利用內(nèi)存，會(huì)產(chǎn)生內(nèi)存碎片，如果存儲(chǔ)塊不足，還會(huì)產(chǎn)生內(nèi)存溢出。