什麼是Session分佈式共享

在瞭解session分佈式共享以前先來了解Session、Redis和Nginx的相關知識。

1、Session相關知識

一、Session 介紹

Session在網絡應用中，稱爲「會話控制」。 每一個用戶（瀏覽器）首次與web服務器創建鏈接時，就會產生一個Session，同時服務器會分配一個SessionId給用戶的瀏覽器。咱們能夠用Fiddler查看cookies中，會看到有一個SessionId的cookie，你們都知道Http是無狀態請求，可是Session彷彿又讓Http請求變得有狀態，其核心就在於這個叫SessionId的cookie，這個至關於數據庫的Key，服務器那邊再有個Session內容緩存表，是否是Session的內容就很容易獲得了。

剛接觸程序開發的人必定愛死Session了，由於Session讓Http從無狀態變成有狀態了，頁面之間傳值、用戶相關信息、一些不變的數據、甚至於查出來的DataTable也能夠放進去，取值的時候只須要Session[Key]便可，真是方便極了，但任何事物被封爲利器基本也是雙刃劍，Session的許多問題咱們不得不去面對。

這個問題不少人都遇到過，Session是致使這個緣由之一，Session丟了讓用戶從新登陸，解決方案爲是把Session時間調到9999，結果該發生的仍是繼續發生着，Session照樣丟失。

二、常見Session丟失緣由

• Session超時，用戶打開頁面，頁面長時間不操做會致使此緣由

• IIS應用程序池回收，或者重啓

• Web.Config修改，即IIS應用程序池重啓

• dll被替換或者動態頁面修改，即IIS應用程序池重啓

• 殺毒軟件對.config文件進行掃描，可能會致使IIS應用程序池回收

• 用戶瀏覽器禁用cookie

• 其餘緣由

爲何說其餘緣由呢，好多程序員沒法查明是什麼緣由致使Session丟失，但Session丟失我歸結爲兩大類，一個是數據的Key丟了，一個是Session內容數據庫的丟了，用戶瀏覽器禁用cookie必定是Key沒了。IIS應用程序池回收一定會致使Session的內容緩存表丟失。

三、解決Session丟失的方法

解決過Session丟失的都會用到這幾種方法：

• InProc:將Session存到進程內。

• StateServer:將Session存到獨立的狀態服務中(Asp.Net State Service)。

• SqlServer:將Session存到SqlServer中。

• Cookieless:設置客戶端Session存儲的方式。

2、Redis相關知識

一、Redis介紹

Redis是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。開發人員用它解決了丟失問題，後來發現它還能夠實現Session分佈式共享，Session丟失、以及持久化到SqlServer數據的性能問題也隨之解決。

二、RedisSessionProvider

首先經過nuget下載 RedisSessionProvider

【web.config配置以下】

<system.web> <sessionState mode="Custom" customProvider="RedisSessionProvider"> <providers> <add name="RedisSessionProvider" type="RedisSessionProvider.RedisSessionStateStoreProvider, RedisSessionProvider"/> </providers> </sessionState> </system.web>

【Global.asax】

void Application_Start(object sender, EventArgs e) { StackExchange.Redis.ConfigurationOptions redisConfigOpts = StackExchange.Redis.ConfigurationOptions.Parse("192.168.8.138:6379"); RedisSessionProvider.Config.RedisConnectionConfig.GetSERedisServerConfig = (HttpContextBase context) => { return new KeyValuePair<string, StackExchange.Redis.ConfigurationOptions>( "DefaultConnection", redisConfigOpts); }; }

【存儲方法】

Session["Test"] = "aa";

【調用方法】

string str = Session["Test"].ToString()

若是你配置好Redis，而且作好上面這些配置，運行若是出現如下問題，請更新RedisSessionProvider的依賴包StackExchange.Redis到最新。

三、Redis下載與安裝

Redis下載：https://github.com/MSOpenTech/redis

• 修改Redis.windows.conf，若是不修改，遠程不能訪問Redis

• 將bind 127.0.0.1 改爲了bind 0.0.0.0。注意：進入生產環境時候，要啓用密碼，不然會是Redis漏洞，具體請自行百度

• protected-mode yes 改爲 protected-mode no

• 詳細修改的傳送門： redis開啓遠程訪問

redis-server redis.windows.conf

上圖爲redis啓動成功，默認6379，能夠經過redis-cli進行測試，看別的機子可否訪問。還能夠在找個redis可視化工具看看裏面存了啥，也能夠監控Session是否持久化到Redis中了。

運行RedisSessionProvider這個項目。同一個IIS下，同域名，不一樣IP，同一瀏覽器，不一樣端口一個是2459，一個是2490。

不一樣瀏覽器SessionId是不一樣的。必須保證SessionId，測試必須是同一個瀏覽器進程分出的不一樣子標籤才能夠，這樣SessionId是共享的。

成功了就是這樣的拓撲圖：

3、Ngnix的相關知識

一、Ngnix安裝&下載

下載地址：http://nginx.org/

二、nginx.conf配置修改

a、接口修改

listen 80; 改爲 listen 1100; 由於通常都被80都被使用。

b、增長負載均衡】

upstream Jq_one { server 127.0.0.1:8770; server 192.168.8.138:7777; } server { ..... }

c、location節點修改

location / { root html; index index.aspx index.html index.htm; #其中jq_one 對應着upstream設置的集羣名稱 proxy_pass http://Jq_one; #設置主機頭和客戶端真實地址，以便服務器獲取客戶端真實IP proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

d、Nginx啓動命令

C:server ginx-1.0.2>start nginx或C:server ginx-1.0.2>nginx.exe

e、Nginx從新載入命令

C:server ginx-1.0.2>nginx.exe -s reload

4、Session分佈式共享

一、拓撲圖

經過Nginx+Redis實現對Session的分佈式共享功能有二種方式：

二、利用Nginx的Ip_Hash進行Session分佈式共享

使用nginx將同一ip的請求分配到固定服務器，修改以下。ip_hash會計算ip對應hash值，而後分配到固定服務器

upstream Jq_one{ server 127.0.0.1:8770; server 192.168.8.138:7777; 　 ip_hash; }

效果能夠理解爲就是一個Ip，經過Nginx路由到IIS_1上面，在屢次請求，會一直在IIS_1上，不會路由到IIS_2上面。

三、利用MachineKey進行Session分佈式共享

Ip_Hash在必定程度上解決了Session分佈式共享的問題，可是沒有發揮出nginx均衡負載的功能，繼續改進。

a、現將Ip_Hash去掉

去掉Ip_Hash重啓Nginx，打開網站，點擊設置Session按鈕，結果報錯

b、往web.config添加MachineKey

<machineKey validationKey="86B6275BA31D3D713E41388692FCA68F7D20269411345AA1C17A7386DACC9C46E7CE5F97F556F3CF0A07159659E2706B77731779D2DA4B53BC47BFFD4FD48A54" decryptionKey="9421E53E196BB56DB11B9C25197A2AD470638EFBC604AC74CD29DBBCF79D6046" validation="SHA1" decryption="AES" />

【注意】負載均衡的兩個網站的MachineKey必須同樣，不然出問題。

c、以下圖服務器的Ip在不斷變化，而Session卻沒有丟失，至此實現了Session分佈式共享。