摘要:我們已經實現了黏滯會話,但是如此一來,黏滯會話可能或多或少地破壞了均衡策略,至少像權重分配這樣的動態策略已經無法工作,我們對此不能視而不見,否則前面的努力即將付諸東流。
負載均衡調度器最大程度地讓用戶不必關心后端服務器,我們知道,當采用RR調度策略時,即便是同一用戶對同一內容的多次請求,也可能被轉發到了不同的后端服務器,這聽起來似乎沒什么大礙,但有時候,或許會帶來一些問題。
當某臺后端服務器啟用了Session來本地化保存用戶的一些數據后,下次用戶的請求如果轉發給了其他后端服務器,將導致之前的Session數據無法訪問;
后端服務器實現了一定的動態內容緩存,而毫無規律的轉發使得這些緩存的利用率下降。
如何解決這些問題呢?從表面上看,我們需要做的就是調整調度策略,讓用戶在一次會話周期內的所有請求始終轉發到一臺特定的后端服務器上,這種機制也稱為黏滯會話(Sticky Sessions),要實現它的關鍵在于如何設計持續性調度算法。
既然要讓調度器可以識別用戶,那么將用戶的IP地址作為識別標志最為合適,一些反向代理服務器對此都有支持,比如Nginx和HAProxy,它們可以將用戶的IP地址進行Hash計算并散列到不同的后端服務器上。
對于Nginx,只需要在upstream中聲明ip_hash即可,如下所示:
upstream backend {
ip_hash; server 10.0.1.200:80; server 10.0.1.201:80;
}
除此之外,你還可以利用Cookies機制來設計持久性算法,比如調度器將某個后端服務器的編號追加到寫給用戶的Cookies中,這樣調度器便可以在該用戶隨后的請求中知道應該轉發給哪臺后端服務器。這樣做可以更加細粒度地追蹤到每一個用戶,試想一下,當有很多用戶隱藏在一個公開IP地址后面時,利用Cookies的持久性算法將顯得更加有效。
我們已經實現了黏滯會話,但是如此一來,黏滯會話可能或多或少地破壞了均衡策略,至少像權重分配這樣的動態策略已經無法工作,我們對此不能視而不見,否則前面的努力即將付諸東流。
當然,問題的關鍵在于,我們究竟是否要通過實現黏滯會話來遷就系統的特殊需要呢?在權衡代價之后你認為是否值得呢?最為關鍵的問題是前面提到的兩個問題是否能從根本上避免呢?如果可以,這很值得去考慮。
事實上,在后端服務器上保存Session數據和本地化緩存,的確是一件不明智的事情,它使得后端服務器顯得過于個性化,以至于和整個系統格格不入,如果允許的話,我們應該盡量避免這樣的設計,比如采用分布式Session或者分布式緩存等,讓后端服務器的應用盡量與本地無關,也可更好地適應環境。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/39397.html
摘要:現有的服務器和應用程序服務器相結合并在一個冒泡中運行,無法直接接觸網絡流量,由反向代理服務器提出填鴨式請求。賦予高可用性讓你的反向代理服務器鏡像到在線備份,同時擁有備用的應用程序服務器,讓你的站點高度可用。 【編者按】本文主要介紹 NGINX 的主要功能以及如何通過 Nginx 優化 Python 應用性能。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。 本文上一篇系: 利用...
摘要:現有的服務器和應用程序服務器相結合并在一個冒泡中運行,無法直接接觸網絡流量,由反向代理服務器提出填鴨式請求。賦予高可用性讓你的反向代理服務器鏡像到在線備份,同時擁有備用的應用程序服務器,讓你的站點高度可用。 【編者按】本文主要介紹 NGINX 的主要功能以及如何通過 Nginx 優化 Python 應用性能。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。 本文上一篇系: 利用...
摘要:負載調度器雙負載及會話復制后端數據庫環境作用一共享之前配置步驟關閉防火墻或者開放端口,,,關閉安裝從官網下載最新版不啟動兩臺主機進行安裝從官網下載需要許可,允許之后下載至本地,導入主機從官網找到或者 Nginx負載調度器+雙Tomcat負載及會話復制+MySQL后端數據庫 環境: IP 作用 192.168.2.5 nginx 192.168.2.6 tomcat1 ...
閱讀 1995·2021-11-15 18:09
閱讀 889·2021-09-06 15:13
閱讀 2636·2021-08-23 09:43
閱讀 2016·2019-08-30 15:54
閱讀 2209·2019-08-30 13:56
閱讀 2476·2019-08-26 11:31
閱讀 3070·2019-08-26 10:56
閱讀 685·2019-08-26 10:28