session會(huì)話基礎(chǔ)理論

本節(jié)大綱

何為會(huì)話保持

何時(shí)需要會(huì)話保持

會(huì)會(huì)話保持的分類

何為會(huì)話保持

會(huì)話保持是負(fù)載均衡最常見的問題之一，也是一個(gè)相對(duì)比較復(fù)雜的問題。會(huì)話保持有時(shí)候又叫做粘滯會(huì)話(Sticky Sessions)。會(huì)話保持是指在負(fù)載均衡器上的一種機(jī)制，可以識(shí)別客戶端與服務(wù)器之間交互過程的關(guān)連性，在作負(fù)載均衡的同時(shí)還保證一系列相關(guān)連的訪問請(qǐng)求會(huì)保持分配到一臺(tái)服務(wù)器上

何時(shí)需要會(huì)話保持

在討論這個(gè)問題前，我們必須先花點(diǎn)時(shí)間弄清楚一些概念：什么是連接（Connection）、什么是會(huì)話（Session），以及這二者之間的區(qū)別。需要特別強(qiáng)調(diào)的是，如果我們僅僅是談?wù)撠?fù)載均衡，會(huì)話和連接往往具有相同的含義。

從簡(jiǎn)單的角度來看，如果用戶需要登錄，那么就可以簡(jiǎn)單的理解為會(huì)話；如果不需要登錄，那么就是連接。

對(duì)于同一個(gè)連接中的數(shù)據(jù)包，負(fù)載均衡會(huì)將其進(jìn)行NAT轉(zhuǎn)換后，轉(zhuǎn)發(fā)至后端固定的服務(wù)器進(jìn)行處理。負(fù)載均衡系統(tǒng)內(nèi)部會(huì)專門有一張表來記錄這些連接的狀況，包括：[源IP：端口]、[目的IP：端口]、[服務(wù)器IP：端口]、空閑超時(shí)時(shí)間（Idle Timeout）等等。由于負(fù)載均衡內(nèi)部記錄連接狀態(tài)的這張表需要消耗系統(tǒng)的內(nèi)存資源，因此這張表不可能無限大，所有傳統(tǒng)廠商都會(huì)有一定的限制。這張表的大小一般稱之為最大并發(fā)連接數(shù)，也就是系統(tǒng)同時(shí)能夠容納的連接數(shù)量。負(fù)載均衡的當(dāng)前連接狀態(tài)表項(xiàng)中，設(shè)計(jì)了一個(gè)空閑超時(shí)時(shí)間（Idle Timeout）的參數(shù)。當(dāng)該連接在Idle Timeout內(nèi)無流量通過時(shí)，負(fù)載均衡會(huì)自動(dòng)刪除該連接條目，釋放系統(tǒng)資源。

刪除連接后，客戶端的請(qǐng)求將無法保證繼續(xù)發(fā)往同一個(gè)后端服務(wù)器，需要遵循負(fù)載均衡器的流量分發(fā)策略。

在某些要求登錄狀態(tài)的情境下，要求客戶端和服務(wù)器之間保持一個(gè)會(huì)話（session）以記錄客戶端的各種信息。比如在大多數(shù)電子商務(wù)的應(yīng)用系統(tǒng)或者需要進(jìn)行用戶身份認(rèn)證的在線系統(tǒng)中，一個(gè)客戶與服務(wù)器經(jīng)常經(jīng)過好幾次的交互過程才能完成一筆交易或者是一個(gè)請(qǐng)求的完成。由于這幾次交互過程是密切相關(guān)的，服務(wù)器在進(jìn)行這些交互過程的某一個(gè)交互步驟時(shí)往往需要了解上一次或上幾次的交互過程處理結(jié)果，這就要求所有這些相關(guān)的交互過程都由一臺(tái)服務(wù)器完成，而不能被負(fù)載均衡器分散到不同的服務(wù)器上否則可能出現(xiàn)異常情景：

• 客戶端輸入了正確的用戶名和口令，但卻反復(fù)跳到登錄頁面；

• 用戶輸入了正確的驗(yàn)證碼，但是總提示驗(yàn)證碼錯(cuò)誤；

• 客戶端放入購(gòu)物車的物品丟失

• …

因此會(huì)話保持機(jī)制的意義就在于，確保在合適的情境下，將來自相同客戶端的請(qǐng)求轉(zhuǎn)發(fā)至后端相同的服務(wù)器進(jìn)行處理。換句話說，就是將客戶端與服務(wù)器之間建立的多個(gè)連接，都發(fā)送到相同的服務(wù)器進(jìn)行處理。如果在客戶端和服務(wù)器之間部署了負(fù)載均衡設(shè)備，很有可能這多個(gè)連接會(huì)被轉(zhuǎn)發(fā)至不同的服務(wù)器進(jìn)行處理。如果服務(wù)器之間沒有會(huì)話信息的同步機(jī)制，會(huì)導(dǎo)致其他服務(wù)器無法識(shí)別用戶身份，造成用戶在和應(yīng)用系統(tǒng)發(fā)生交互時(shí)出現(xiàn)異常。

負(fù)載均衡希望將來自客戶端的連接、請(qǐng)求均衡的轉(zhuǎn)發(fā)至后端的多臺(tái)服務(wù)器，以避免單臺(tái)服務(wù)器負(fù)載過高；而會(huì)話保持機(jī)制卻要求將某些請(qǐng)求轉(zhuǎn)發(fā)至同一臺(tái)服務(wù)器進(jìn)行處理。因此，在實(shí)際的部署環(huán)境中，我們要根據(jù)應(yīng)用環(huán)境的特點(diǎn)，選擇適當(dāng)?shù)臅?huì)話保持機(jī)制。

會(huì)話保持類型

會(huì)話保持大體可以分為三大類，session sticky，session LBcluster和session server，而這三種會(huì)話綁定方式又各有優(yōu)缺點(diǎn)，適應(yīng)不同的場(chǎng)景；

1 session sticky

Session sticky，即會(huì)話綁定，即將客戶端的訪問通過某種算法將它調(diào)度至固定的服務(wù)器上，而這種實(shí)現(xiàn)方式主要是由調(diào)度器的調(diào)度算法來實(shí)現(xiàn)的，像在Nginx反向代理功能中就提供了ip_hash（每個(gè)請(qǐng)求按訪問ip結(jié)果分配。這樣來自同一個(gè)ip的訪問將被調(diào)度到同一臺(tái)服務(wù)器上，有效解決的動(dòng)態(tài)網(wǎng)頁存在的session共享問題。），url_hash（此方法是按照訪問url的hash結(jié)果來分配請(qǐng)求，使每一個(gè)url定向到同一個(gè)后端服務(wù)器，可以進(jìn)一步提高后端緩存服務(wù)器的效率。Nginx本身是不支持url_hash算法的）以及更加強(qiáng)大的一致性hash算法。這種調(diào)度方式是基于四層的會(huì)話調(diào)度，這種調(diào)度粒度很粗。

會(huì)話綁定中一個(gè)很重要的參數(shù)就是連接超時(shí)值，負(fù)載均衡器會(huì)為每一個(gè)處于保持狀態(tài)中的會(huì)話設(shè)定一個(gè)時(shí)間值。若一個(gè)會(huì)話從上一次完成到下次再來之間的間隔時(shí)間小于超時(shí)值時(shí)，負(fù)載均衡器將會(huì)將新的連接進(jìn)行會(huì)話保持；但如果這個(gè)間隔大于該超時(shí)值，負(fù)載均衡器會(huì)將新來的連接認(rèn)為是新的會(huì)話然后進(jìn)行負(fù)載平衡。這種會(huì)話話保持實(shí)現(xiàn)簡(jiǎn)單，只需要根據(jù)數(shù)據(jù)包三四層的信息就可以實(shí)現(xiàn)，效率比較高。

但此種方式存在的問題就在于，當(dāng)多個(gè)客戶端通過代理或地址轉(zhuǎn)換的方式訪問服務(wù)器時(shí)，由于來源地址一樣，請(qǐng)求都被分配到同一臺(tái)服務(wù)器上，會(huì)導(dǎo)致服務(wù)器之間的負(fù)載嚴(yán)重失衡。另外一種情況是，同一個(gè)客戶端產(chǎn)生大量并發(fā)，要求分配到多個(gè)服務(wù)器上處理的同時(shí)進(jìn)行會(huì)話保持。這時(shí)基于客戶端源地址的會(huì)話保持方法也會(huì)導(dǎo)致負(fù)載均衡失效。以上情況出現(xiàn)時(shí)，就必須要考慮使用其他的會(huì)話保持方式。

2 Session Lbcluster

由于session sticky在調(diào)度中不能夠很好的實(shí)現(xiàn)會(huì)話的保持與高可用性，只要其中一臺(tái)主機(jī)宕機(jī)，就意味著這臺(tái)主機(jī)維持的所有會(huì)話都將丟失，這不僅對(duì)用戶是一種不好的體驗(yàn)，更是一個(gè)站點(diǎn)的損失，于是人們開始思考能否讓后端的每個(gè)服務(wù)器都能夠攜帶所有服務(wù)器的會(huì)話呢？漸漸的找到了解決方案，那就是實(shí)現(xiàn)會(huì)話集群，會(huì)話集群，顧名思義，那就是將所有維持會(huì)話的服務(wù)組合成一個(gè)集群，維護(hù)該站點(diǎn)所有的會(huì)話信息，這樣一來，我們就不用在擔(dān)心因?yàn)槟撑_(tái)主機(jī)而使得用戶的信息丟失。

這種方式解決了用戶會(huì)話丟失的問題，用戶再也不會(huì)出現(xiàn)什么”客戶端放入購(gòu)物車的物品丟失”這類問題了。但是解決了A類問題也會(huì)帶來B類問題，每個(gè)會(huì)話服務(wù)器既要處理前端的用戶請(qǐng)求又要會(huì)話同步至其他的主機(jī)，如果這是一個(gè)量很大的服務(wù)站點(diǎn)，那么每一臺(tái)主機(jī)在同步其他主機(jī)的會(huì)話信息，以及將自己維持的會(huì)話發(fā)送給其他服務(wù)器時(shí)將會(huì)產(chǎn)生大量IO操作，這就使得每個(gè)服務(wù)器的壓力變得異常大，處理前端的請(qǐng)求的性能大大降低。并且，同步使用的是組播的方式來實(shí)現(xiàn)的，大量服務(wù)器同時(shí)同步各自的會(huì)話給其他的主機(jī)，這將消耗大量的帶寬。

3 Session Server

鑒于會(huì)話集群帶來的新問題，我們選擇一組服務(wù)器來專門用戶進(jìn)行會(huì)話的管理，后端服務(wù)器只需要將自己的會(huì)話寫入到后端的會(huì)話服務(wù)器即可，等到用戶的請(qǐng)求到來是，只需要與session server中的會(huì)話值做比較即可。那么session Server怎樣存儲(chǔ)這些會(huì)話信息呢，于是有了以下幾種存儲(chǔ)方式：

1) 數(shù)據(jù)庫(kù)存放

Session信息存儲(chǔ)到數(shù)據(jù)庫(kù)表以實(shí)現(xiàn)不同應(yīng)用服務(wù)器間Session信息的共享。此種方式適合數(shù)據(jù)庫(kù)訪問量不大的網(wǎng)站。

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單

缺點(diǎn)：由于數(shù)據(jù)庫(kù)服務(wù)器相對(duì)于應(yīng)用服務(wù)器更難擴(kuò)展且資源更為寶貴，在高并發(fā)的Web應(yīng)用中，最大的性能瓶頸通常出現(xiàn)在數(shù)據(jù)庫(kù)服務(wù)器。因此如果將 Session存儲(chǔ)到數(shù)據(jù)庫(kù)表，頻繁的數(shù)據(jù)庫(kù)操作會(huì)影響業(yè)務(wù)。

2) 文件系統(tǒng)存放

通過文件系統(tǒng)（比如NFS）來實(shí)現(xiàn)各臺(tái)服務(wù)器間的Session共享。此種方式適合并發(fā)量不大的網(wǎng)站。

優(yōu)點(diǎn)：各臺(tái)服務(wù)器只需要mount存儲(chǔ)Session的磁盤即可，實(shí)現(xiàn)較為簡(jiǎn)單。

缺點(diǎn)：NFS對(duì)高并發(fā)讀寫的性能并不高，在硬盤I/O性能和網(wǎng)絡(luò)帶寬上存在較大瓶頸，尤其是對(duì)于Session這樣的小文件的頻繁讀寫操作。

3) Memcached存放

利用Memcached來保存Session數(shù)據(jù)，直接通過內(nèi)存的方式讀取。

優(yōu)點(diǎn)：效率高，在讀寫速度上會(huì)比存放在文件系統(tǒng)時(shí)快很多，而且多個(gè)服務(wù)器共用Session也更加方便，將這些服務(wù)器都配置成使用同一組memcached服務(wù)器就可以，減少了額外的工作量。

缺點(diǎn)：一旦宕機(jī)內(nèi)存中的數(shù)據(jù)將會(huì)丟失，但對(duì)Session數(shù)據(jù)來說并不是嚴(yán)重的問題。如果網(wǎng)站訪問量太大、Session太多的時(shí)候memcached會(huì)將不常用的部分刪除，但是如果用戶隔離了一段時(shí)間之后繼續(xù)使用，將會(huì)發(fā)生讀取失敗的問題。