分布式session一致性問題

傳統的網站結構（并發量不大，沒有session的不一致的問題。

傳統的網站結構圖：

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

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

分布式中session一致性問題

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

什么是負載均衡和反向代理？

什么是負載均衡？：

負載均衡：將客戶端的請求按照一定的規則分配到一群服務器中，并將處理結果返回個相應的客戶端。

例如：上圖client 發送請求A經過負載均衡（按照某一規則）分配到webserver1中，并且將請求的結果在返回客戶端。如果并發量大的時，負載均衡就會很好的控制服務端處理的任務量，避免一個服務器處理量大，一個處于空閑。

負載均衡的實現

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

• 基于軟件方面。（實際開發中應用最多）。

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

什么是會話保持，有什么作用

會話保持是指在負載均衡器上有一種機制，在作負載均衡的同時，還保持同一用戶相關連的請求會被分配到同一臺服務器上。

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

會話同步

網絡集群時會同步的3中方法
在做了網絡集群后，你肯定會首先考慮會話同步問題，因為通過負載均衡后，同一IP訪問同一頁面會被分配到不同的服務器上，如果會話不同步的話，一個登陸用戶，一會是登陸狀態，一會又不是登陸狀態。

• 1 利用數據庫同步會話（不常用）

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

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

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

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

• 3 利用memcache或者redis同步會話

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

優點：以這種方式來同步會話，不會加大數據庫的負擔，并且安全性比用餅干大大的提高，把會議放到內存里面，比從文件中讀取要快很多。 缺點：內存緩存把內存分成很多種規格的存儲塊，有塊就有大小，這種方式也就決定了，內存緩存不能完全利用內存，會產生內存碎片，如果存儲塊不足，還會產生內存溢出。