l23456125847530

Nginx作為一款專業的反向代理服務器，由於其性能突出，現在一般中大型網站架構模式中，都會將它作為前置的反向代理服務器。但在部署反向代理之後，有個問題就來了，那就是如何實現會話保持？

什麼是會話保持？

我們知道，HTTP協議本身是無狀態的。什麼意思呢？就是用戶向瀏覽器發出請求後，服務器默認是無法直接識別用戶的，無法將用戶進行區分，這就會存在很多問題，於是就有了會話機制。

具體如何實現會話的呢？主要有兩種會話：Cookie會話、Session會話。Session會話是保存在服務器端的，然後將SessionID存入Cookie中，用戶下次請求服務器時，服務器能夠識別Cookie中的SessionID然後找到對應的Session，這樣服務器就能識別用戶了。

反向代理為什麼會導致會話丟失？

上面說到了，Session是存儲在服務器端的，當使用了反向代理後，同一用戶的多次請求不能保證都落在同一臺後端服務器上，這樣用戶瀏覽器中的Cookie即使傳遞到後端服務器，服務器也未必能找到對應的Session，於是，會話丟失了！

使用了反向代理後如何保持會話？

其實會話保持有很多種解決方案，下面結合我的實際經驗總結一下供大家參考：

1、Nginx會話保持機制

Nginx自帶有會話保持機制，常見的有：

• ip_hash：使用源地址哈希算法，這樣同一客戶端的請求都會到達同一個後端服務器；
  

• sticky_cookie_insert：此算法基於Cookie來實現的，此模塊需要編譯安裝。

2、會話共享機制

如果我們讓多個後端節點服務器的Session保持一致，不就可以解決落地服務器的會話保持了麼？說得通俗點，我們把Session集中管理，然後各個節點服務器從這裡取Session，就能保持會話了。

實現方案很多，比如說：

• Session入庫；
  

• Session存入NoSQL（Memcache、Redis）中。

網絡圈

常用的方法有兩種:

1, IP hash, 根據請求的ip不同固定的轉發到指定的服務器上實現保持

2, cookie, 服務器給客戶端下發一個cookie, 根據cookie決定轉發的服務器.

關鍵字: Nginx 反向 代理服務器