會話保持是什麼？

會話保持概述 會話保持是負載均衡最多見的問題之一，也是一個相對比較複雜的問題。會話保持有時候又叫作粘滯會話(Sticky Sessions) 在介紹會話保持技術以前，咱們必須先花點時間弄清楚一些概念：什麼是鏈接（Connection）、什麼是會話（Session），以及這兩者之間的區別。須要特別強調的是，若是咱們僅僅是談論負載均衡，會話和鏈接每每具備相同的含義 從簡單的角度來看，若是用戶須要登陸，那麼就能夠簡單的理解爲會話；若是不須要登陸，那麼就是鏈接。 實際上，會話保持機制與負載均衡的基本功能是徹底矛盾的。負載均衡但願未來自客戶端的鏈接、請求均衡的轉發至後端的多臺服務器，以免單臺服務器負載太高；而會話保持機制卻要求將某些請求轉發至同一臺服務器進行處理。所以，在實際的部署環境中，咱們要根據應用環境的特色，選擇適當的會話保持機制   原始負載均衡的基本原理 對於同一個鏈接中的數據包，負載均衡會將其進行NAT轉換後，轉發至後端固定的服務器進行處理，這是負載均衡最基本、最原始的功能。負載均衡系統內部會專門有一張表來記錄這些鏈接的情況，包括：[源IP：端口]、[目的IP：端口]、[服務器IP：端口]、空閒超時時間（Idle Timeout）等等 因爲負載均衡內部記錄鏈接狀態的這張表須要消耗系統的內存資源，所以這張表不可能無限大，全部傳統廠商都會有必定的限制。這張表的大小通常稱之爲最大併發鏈接數，也就是系統同時可以容納的鏈接數量。考慮到創建這些鏈接的客戶端或服務器會發生一些異常情況，致使這些鏈接不能被正常終結掉，所以，負載均衡的當前鏈接狀態表項中，設計了一個空閒超時時間的參數。這個參數定義爲，當該鏈接在必定時間內無流量經過時，負載均衡會自動刪除該鏈接條目，釋放系統資源 有了會話以後，使用原始的負載均衡就會有問題，常見的異常場景包括：   所以，會話保持機制的意義就在於，確保未來自相同客戶端的請求，轉發至後端相同的服務器進行處理。換句話說，就是將客戶端與服務器之間創建的多個鏈接，都發送到相同的服務器進行處理。若是在客戶端和服務器之間部署了負載均衡設備，頗有可能，這多個鏈接會被轉發至不一樣的服務器進行處理。若是服務器之間沒有會話信息的同步機制，會致使其餘服務器沒法識別用戶身份，形成用戶在和應用系統發生交互時出現異常。 在大多數電子商務的應用系統或者須要進行用戶身份認證的在線系統中,一個客戶與服務器常常通過好幾回的交互過程才能完成一筆交易或者是一個請求的完成因爲這幾回交互過程是密切相關的,服務器在進行這些交互過程的某一個交互步驟時,每每須要瞭解上一次交互過程的處理結果,或者上幾步的交互過程結果,服務器進行下一步操做時須要這就要求全部這些相關的交互過程都由一臺服務器完成,而不能被負載均衡器分散到不一樣的服務器上 而這一系列的相關的交互過程多是由客戶到服務器的一個鏈接的屢次會話完成,也多是在客戶與服務器之間的多個不一樣鏈接裏的屢次會話完成不一樣鏈接的屢次會話,最典型的例子就是基於http的訪問,一個客戶完成一筆交易可能需屢次點擊,而一個新的點擊產生的請求,可能會重用上一次點擊創建起來的鏈接,也多是一個新建的鏈接 會話保持就是指在負載均衡器上有這麼一種機制,能夠識別作客戶與服務器之間交互過程的關連性,在做負載均衡的同時,還保證一系列相關連的訪問請求會保持分配到一臺服務器上   客戶端輸入了正確的用戶名和口令，但卻反覆跳到登陸頁面； 用戶輸入了正確的驗證碼，可是總提示驗證碼錯誤； 客戶端放入購物籃的物品丟失 …                                           1、簡單會話保持-基於ip 簡單會話保持也被稱爲基於源地址的會話保持，也叫基於IP的會話保持,是指負載均衡器在做負載均衡時是根據訪問請求的源地址做爲判斷關連會話的依據對來自同一IP地址的全部訪問請求在做負載均時都會被保持到一臺服務器上去負載均衡器能夠爲「同一IP地址」經過網絡掩碼進行區分,好比能夠經過對IP地址 192.168.1.1進行255.255.255.0的網絡掩碼,這樣只要是來自於192.168.1.0/24這個網段的流量BIGIP均可以認爲他們是來自於同一個用戶,這樣就將把來自於192.168.1.0/24網段的流量會話保持到特定的一臺服務器上 簡單會話保持裏另一個很重要的參數就是鏈接超時值,負載均衡器會爲每個進行會話保持的會話設定一個時間值,當一個會話上一次完成到這個會話下次再來以前的間隔若是小於這個超時值,負載均衡器將會將新的鏈接進行會話保持,但若是這個間隔大於該超時值,負載均衡器將會將新來的鏈接認爲是新的會話而後進行負載平衡簡單會話保持實現起來簡單,只須要根據數據包三四層的信息就能夠實現,效率也比較高 簡單會話保持存在的問題就在於當多個客戶是經過代理或地址轉換的方式來訪問服務器時,因爲都分配到同一臺服務器上,會致使服務器之間的負載嚴重失衡另一種狀況上客戶機數量不多,但每一個客戶機都會產生多個併發訪問,對這些必發訪問也要求經過負載均衡器分配到多個服器上,這時基於客戶端源地址的會話保持方法也會致使負載均衡失效這個時候，就必需要考慮使用其餘的會話保持方式，好比session等 F5 BigIP支持多種的會話保持方法,其中包括:簡單會話保持(源地址會話保持)HTTP Header的會話保持,基於SSL Session ID的會話保持,I-Rules會話保持以及基於 HTTP Cookie的會話保持,此外還有基於SIP ID以及Cache設備的會話保持等,但經常使用的是簡單會話保持,HTTP Header的會話保持以及 HTTP Cookie會話保持以及基於I-Rules的會話保持    NginX對簡單會話保持的支持   ip_hash    每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session 的問題。   例如：            upstream **nd {            ip_hash;            server 192.168.0.14:88;            server 192.168.0.15:80;                                     } 2、存session的會話保持方式 一、使用數據庫存放session，Session信息存儲到數據庫表，這樣實現不一樣應用服務器間Session信息的共享 適合數據庫訪問量不大的網站。優勢：實現簡單； 缺點：因爲數據庫服務器相對於應用服務器更難擴展且資源更爲寶貴，在高併發的Web應用中，最大的性能瓶頸一般在於數據庫服務器。所以若是將 Session存儲到數據庫表，頻繁的數據庫操做會影響業務。 二、使用文件系統存放session 經過文件系統（好比NFS方式）來實現各臺服務器間的Session共享，各臺服務器只須要mount共享服務器的存儲Session的磁盤便可，實現較爲簡單。但NFS 對高併發讀寫的性能並不高，在硬盤I/O性能和網絡帶寬上存在較大瓶頸，尤爲是對於Session這樣的小文件的頻繁讀寫操做，適合併發量不大的網站 三、基於Memcached 存儲Session 利用Memcached來保存Session數據，直接經過內存的方式，效率天然可以提升很多。 在讀寫速度上會比 files 時快不少，並且在多個服務器須要共用 session 時會比較方便，將這些服務器都配置成使用同一組 memcached 服務器就能夠，減小了額外的工做量。缺點： session 數據都保存在 memory 中，一旦宕機，數據將會丟失。但對 session 數據來講並非嚴重的問題。若是網站訪問量太大，session太多的時候，memcached會將不經常使用的部分刪除，可是若是用戶隔離了一段時間以後繼續使用，已經所有亂套了。   3、基於Cookie的會話保持 在Cookie插入模式下，CLB將負責插入cookie，後端服務器無需做出任何修改.當客戶進行第一次請求時，客戶HTTP請求（不帶cookie）進入CLB， CLB根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器，後端服務器進行HTTP回覆（不帶cookie）被髮回CLB，而後CLB插入cookie，將HTTP回覆返回到客戶端。 當客戶請求再次發生時，客戶HTTP請求（帶有上次CLB插入的cookie）進入CLB，而後CLB讀出cookie裏的會話保持數值，將HTTP請求（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆，因爲服務器並不寫入cookie，HTTP回覆將不帶有cookie，恢復流量再次通過進入CLB時，CLB再次寫入更新後的會話保持cookie。

 

本文出自 「火星男-神自不凡」 博客，請務必保留此出處http://marsman.blog.51cto.com/6410055/1912040