nginx作反向代理url重寫？

Nginx作為一款專業(yè)的反向代理服務(wù)器，由于其性能突出，現(xiàn)在一般中大型網(wǎng)站架構(gòu)模式中，都會將它作為前置的反向代理服務(wù)器。但在部署反向代理之后，有個(gè)問題就來了，那就是如何實(shí)現(xiàn)會話保持？

什么是會話保持？

我們知道，HTTP協(xié)議本身是無狀態(tài)的。什么意思呢？就是用戶向?yàn)g覽器發(fā)出請求后，服務(wù)器默認(rèn)是無法直接識別用戶的，無法將用戶進(jìn)行區(qū)分，這就會存在很多問題，于是就有了會話機(jī)制。

具體如何實(shí)現(xiàn)會話的呢？主要有兩種會話：Cookie會話、Session會話。Session會話是保存在服務(wù)器端的，然后將SessionID存入Cookie中，用戶下次請求服務(wù)器時(shí)，服務(wù)器能夠識別Cookie中的SessionID然后找到對應(yīng)的Session，這樣服務(wù)器就能識別用戶了。

反向代理為什么會導(dǎo)致會話丟失？

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

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

其實(shí)會話保持有很多種解決方案，下面結(jié)合我的實(shí)際經(jīng)驗(yàn)總結(jié)一下供大家參考：

1、Nginx會話保持機(jī)制

Nginx自帶有會話保持機(jī)制，常見的有：

ip_hash：使用源地址哈希算法，這樣同一客戶端的請求都會到達(dá)同一個(gè)后端服務(wù)器；

sticky_cookie_insert：此算法基于Cookie來實(shí)現(xiàn)的，此模塊需要編譯安裝。

2、會話共享機(jī)制

如果我們讓多個(gè)后端節(jié)點(diǎn)服務(wù)器的Session保持一致，不就可以解決落地服務(wù)器的會話保持了么？說得通俗點(diǎn)，我們把Session集中管理，然后各個(gè)節(jié)點(diǎn)服務(wù)器從這里取Session，就能保持會話了。

實(shí)現(xiàn)方案很多，比如說：

Session入庫；

Session存入NoSQL（Memcache、Redis）中。

以上就是我的觀點(diǎn)，對于這個(gè)問題大家是怎么看待的呢？歡迎在下方評論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn)，歡迎關(guān)注我了解更多科技知識！