ASP.NET Core如何解決分布式Session一致性問題

一、我們知道Session的常見形式是會(huì)話cookie，即為設(shè)置過期時(shí)間的cookie，它的默認(rèn)的生命周期為瀏覽器會(huì)話期間，一旦瀏覽器關(guān)閉窗口，這個(gè)cookie就消失了。其實(shí)現(xiàn)機(jī)制為：當(dāng)用戶發(fā)起一個(gè)請求的時(shí)候，服務(wù)器會(huì)檢查該請求中是否包含sessionID，如果不包含，則服務(wù)器會(huì)生成一個(gè)名為JSESSIONID的cookie返回到瀏覽器，（這個(gè)cookie存放在內(nèi)存中，并不會(huì)存在硬盤）。同時(shí)在服務(wù)器端以HashTable的形式寫到服務(wù)器內(nèi)存中；當(dāng)請求中包含sessionID時(shí)，服務(wù)器端會(huì)在HashTable中查找與該session相匹配的信息，若存在則直接使用該sessionID，否則重新生成新的session。

二、 Session共享：如果網(wǎng)站是存放在一臺(tái)機(jī)器上，是不存在session共享這個(gè)問題的，因?yàn)樗械臅?huì)話數(shù)據(jù)都在這一臺(tái)機(jī)器上。但是，現(xiàn)在的網(wǎng)站大部分都是需要做負(fù)載均衡的，即需要把用戶的請求分發(fā)到不同機(jī)器，當(dāng)然這時(shí)會(huì)話ID在客戶端是不存在問題的，但是服務(wù)端會(huì)出現(xiàn)取不到session數(shù)據(jù)的情況。如下圖：

在該架構(gòu)中，采用Nginx做負(fù)載均衡，兩個(gè)Tomcat做后端服務(wù)器，假設(shè)當(dāng)客戶端第一次請求時(shí)，Nginx將其分發(fā)到了Tomcat1，這時(shí)候Tomcat1會(huì)產(chǎn)生sessionID返回給客戶端，并同時(shí)保存在自己的內(nèi)存中；當(dāng)客戶端第二次請求時(shí)，Nginx將其分發(fā)到了Tomcat2，這時(shí)便無法取到session。從而就會(huì)重新生成session，返回給客戶端，并保存在自己的內(nèi)存中。兩臺(tái)Tomcat中保存的同一個(gè)用戶的session不同，這便是session的一致性問題。

為了解決這個(gè)問題，首當(dāng)其沖，我會(huì)想到，將Tomcat1中的session復(fù)制到Tomcat2中即可，當(dāng)然是可以的，但是不方便，因?yàn)檫@里只有兩臺(tái)服務(wù)器，而當(dāng)后臺(tái)服務(wù)器增多時(shí)，會(huì)很麻煩。從而，便有了如下的解決方法：

即，將session分離出來，每個(gè)服務(wù)器都是從該session服務(wù)器（集群）中獲取。這樣以來，新增加的服務(wù)器也只需從session集群中獲取。

（session集群可以通過memcached或redis來實(shí)現(xiàn)）

三、那么我們來看看ASP.NET Core使用Redis存儲(chǔ)Session實(shí)現(xiàn)分布式共享？

Session 是客戶端與服務(wù)器通訊會(huì)話跟蹤技術(shù)，服務(wù)器與客戶端保持整個(gè)通訊的會(huì)話基本信息?？蛻舳嗽诘谝淮卧L問服務(wù)端的時(shí)候，服務(wù)端會(huì)響應(yīng)一個(gè)sessionId并且將它存入到本地cookie中，在之后的訪問會(huì)將cookie中的sessionId放入到請求頭中去訪問服務(wù)器，如果通過這個(gè)sessionid沒有找到對應(yīng)的數(shù)據(jù)那么服務(wù)器會(huì)創(chuàng)建一個(gè)新的sessionid并且響應(yīng)給客戶端。

1、為什么要分布式共享Session? 

單服務(wù)器web應(yīng)用中，session信息只需存在該服務(wù)器中，這是我們前幾年最常接觸的方式，但是近幾年隨著分布式系統(tǒng)的流行，單系統(tǒng)已經(jīng)不能滿足日益增長的百萬級用戶的需求，集群方式部署服務(wù)器已在很多公司運(yùn)用起來，當(dāng)高并發(fā)量的請求到達(dá)服務(wù)端的時(shí)候通過負(fù)載均衡的方式分發(fā)到集群中的某個(gè)服務(wù)器，這樣就有可能導(dǎo)致同一個(gè)用戶的多次請求被分發(fā)到集群的不同服務(wù)器上，就會(huì)出現(xiàn)取不到session數(shù)據(jù)的情況，于是session的共享就成了一個(gè)問題。這個(gè)時(shí)候就需要解決Session一致性。

2、分布式Session存在的問題？

假設(shè)第一次訪問服務(wù)A生成一個(gè)sessionid并且存入cookie中，第二次卻訪問服務(wù)B客戶端會(huì)在cookie中讀取sessionid加入到請求頭中，如果在服務(wù)B通過sessionid沒有找到對應(yīng)的數(shù)據(jù)那么它創(chuàng)建一個(gè)新的并且將sessionid返回給客戶端,這樣并不能共享我們的Session無法達(dá)到我們想要的目的。

說白了一句話就是: 分布式Session存在會(huì)話不一致性的問題。 

3、分布式Session解決方案有哪些？

實(shí)現(xiàn)分布式session的方案非常多，選型時(shí)需要一種可靠、簡單的實(shí)現(xiàn)方式，結(jié)合我們項(xiàng)目中的使用經(jīng)驗(yàn)來看，使用基于Redis實(shí)現(xiàn)的分布式session方案還是比較靠譜的。

騰訊課堂

網(wǎng)易云課堂