[轉發] 負載均衡的伺服器叢集上如何進行快取和會話資料的管理
阿新 • • 發佈：2019-01-22
會話資料管理方法
1. 不儲存Session
對於一些不需要記錄使用者狀態的Web應用，採用這種Stateless方式是最恰當的方式。
2. 基於Cookie的Session共享
這種策略也被稱為客戶端Session，即不將Session資訊儲存於伺服器端，而是儲存於客戶端。這同時，也會帶來一定的安全問題，因為Cookie是儲存於客戶端中的，也就意味著客戶端可以修改Cookie檔案，來進行Session劫持操作。安全性問題是這種策略最大的問題。
缺點：只能夠儲存字串、數值等基本型別的資料；Cookie大小存在限制；安全性；頻寬及資料解壓縮、網路傳輸效能問題。
優點：節省伺服器記憶體。
3. 集中式Session儲存策略
集中式Session，顧名思義，將叢集中所有使用者機的Session都儲存在同一臺機器上（Session伺服器）。
此時Session儲存有如下集中方式：
1. Key/ValueStorage
一般，大型Web系統會採用Key/ValueStorage的方式儲存Session。在這種儲存方式的選擇中，大多數的大型Web系統會選擇memcached。
這種方式的優點在於:
多數的Key/Value Storage支援Object作為它的Key或者Value
多數的Key/Value Storage提供非常友好的API；
Key/Valuestorage速度一般都遠高於關係型資料庫，非常適合Session這種存取非常頻繁的情況，例如memcached支援全記憶體的工作方式，速度非常快；
多數的Key/Value Storage支援良好的備份與恢復機制；
多數的Key/Value Storage支援叢集工作的方式，此時Session的總量也就不再侷限於單Session伺服器的記憶體大小。
這種方式的缺點在於：
Key/ValueStorage部署有一定的複雜；
多數Key/Value Storage對於CPU與記憶體的消耗較多；
在使用這種方式時，需要注意以下幾點：
Key/ValueStorage對Object（物件）大小的限制。很多Key/ValueStorage會對所儲存的物件的大小有所限制，比如memcached中，預設配置下單個物件的最大大小為 1MB；
當與Session伺服器的連線斷開或者Session伺服器宕機時的異常處理。
2. 基於資料庫的Session共享，實現分散式應用間Session共享
優點：實現簡單
缺點：由於資料庫伺服器相對於應用伺服器更難擴充套件且資源更為寶貴，在高併發的Web應用中，最大的效能瓶頸通常在於資料庫伺服器。因此如果將 Session儲存到資料庫表，頻繁的增加、刪除、查詢操作很容易造成資料庫表爭用及加鎖，最終影響業務。
3. 基於記憶體的Session儲存
在使用這種方式時，可以直接使用HashTable。至於為什麼使用HashTable而非HashMap，原因非常簡單HashTable是執行緒安全的，而且HashTable不支援null作為key或者value。HashTable中key可以使用者名稱/使用者ID，value為這個使用者的Session。
這種方式的優點在於:
實現簡單；
速度快。這種方式無疑是這三種方式中最為快速的；
這種方式的缺點在於：
備份困難；
所有的資料都在同一臺機器上，這臺機器容易成為單點故障；
Session集合的總容量受到Session伺服器的記憶體大小限制；
難以以叢集的方式進行工作；
4. StickySession
採用這種策略時，某一個使用者所有的請求都會對映到某一臺應用伺服器。無論這臺伺服器是否是非常空閒，還是非常繁忙，這臺機器上的使用者請求仍然會再次對映到這臺機器上。
為了達到Session Sticky，有多種負載的策略：
1. IP Hash
IP Hash策略下，將所有的應用伺服器列成一個Hash表，這個表中的每一個元素即是一臺應用伺服器。負載均衡器的負載策略是根據使用者的IP，將使用者的IP Hash到以上所談及到Hash表中。一般而言，使用者的IP不會有變化，Hash值也是不會變化的，因而使用者的請求會一直對映到某一臺應用伺服器上。當用戶的數量非常龐大的時候，一般使用者的IP也比較分散，這種策略的效果也比較好。而且，這種方式的實現也非常簡單，只需要對負載均衡器進行一定的配置便可，而不需要對業務系統做出任何的修改。
2. 使用者名稱Hash
在現在Web系統中，一般都會有註冊使用者，而且只有註冊使用者才可以使用其釋出的服務。使用者名稱Hash，其原理、優缺點與IP Hash基本上是相同的，只是Hash函式的輸入不再是使用者的IP地址，而是使用者的使用者名稱。而使用者名稱的提供主要有兩種方式，一種是每一個請求URL都會帶上自己的使用者名稱，第二種是將使用者名稱放在客戶端的Cookie中。在第二種方法中，如果客戶端不提供Cookie，那這種策略將會無法執行。
3. 首次登陸時間Hash
這種Hash策略的原理也非常容易想象，不再是使用者的IP地址或者使用者名稱，而根據使用者登陸系統的時間來進行Hash。同樣，首次登陸時間的提供主要有兩種方式，一種是每一個請求URL都會帶上自己的登陸時間，第二種是將登陸時間放在客戶端的Cookie中。在第二種方法中，如果客戶端不提供Cookie，那這種策略將會無法執行。
快取管理
1. 採用服務的方式
這是一種最直接的方式。當然服務的方式可以多種多樣，比較簡單的方式是提供一個ClearCache.aspx的頁面，當實體資料發生變更之後呼叫N多臺Web應該的這個頁面。
2. 採用File Dependency的策略
這種策略讓快取依賴於一個指定的檔案，通過改變檔案的更新日期來清除快取。這種方式的缺點是，如果快取的資料比較多，相關的依賴檔案比較鬆散，對管理這些依賴檔案有一定的麻煩。對於負載均衡環境下，還需要同時更新多臺Web伺服器下的快取檔案，如果多個Web應用中的快取依賴於同一個共享的檔案，可能會省掉這個麻煩，但是對Web應用中執行帳號的許可權所限，終歸不是那麼簡潔。
3. 採用SqlCacheDependency的策略
1. 不儲存Session
對於一些不需要記錄使用者狀態的Web應用，採用這種Stateless方式是最恰當的方式。
2. 基於Cookie的Session共享
這種策略也被稱為客戶端Session，即不將Session資訊儲存於伺服器端，而是儲存於客戶端。這同時，也會帶來一定的安全問題，因為Cookie是儲存於客戶端中的，也就意味著客戶端可以修改Cookie檔案，來進行Session劫持操作。安全性問題是這種策略最大的問題。
缺點：只能夠儲存字串、數值等基本型別的資料；Cookie大小存在限制；安全性；頻寬及資料解壓縮、網路傳輸效能問題。
優點：節省伺服器記憶體。
3. 集中式Session儲存策略
集中式Session，顧名思義，將叢集中所有使用者機的Session都儲存在同一臺機器上（Session伺服器）。
此時Session儲存有如下集中方式：
1. Key/ValueStorage
一般，大型Web系統會採用Key/ValueStorage的方式儲存Session。在這種儲存方式的選擇中，大多數的大型Web系統會選擇memcached。
這種方式的優點在於:
多數的Key/Value Storage支援Object作為它的Key或者Value
多數的Key/Value Storage提供非常友好的API；
Key/Valuestorage速度一般都遠高於關係型資料庫，非常適合Session這種存取非常頻繁的情況，例如memcached支援全記憶體的工作方式，速度非常快；
多數的Key/Value Storage支援良好的備份與恢復機制；
多數的Key/Value Storage支援叢集工作的方式，此時Session的總量也就不再侷限於單Session伺服器的記憶體大小。
這種方式的缺點在於：
Key/ValueStorage部署有一定的複雜；
多數Key/Value Storage對於CPU與記憶體的消耗較多；
在使用這種方式時，需要注意以下幾點：
Key/ValueStorage對Object（物件）大小的限制。很多Key/ValueStorage會對所儲存的物件的大小有所限制，比如memcached中，預設配置下單個物件的最大大小為 1MB；
當與Session伺服器的連線斷開或者Session伺服器宕機時的異常處理。
2. 基於資料庫的Session共享，實現分散式應用間Session共享
優點：實現簡單
缺點：由於資料庫伺服器相對於應用伺服器更難擴充套件且資源更為寶貴，在高併發的Web應用中，最大的效能瓶頸通常在於資料庫伺服器。因此如果將 Session儲存到資料庫表，頻繁的增加、刪除、查詢操作很容易造成資料庫表爭用及加鎖，最終影響業務。
3. 基於記憶體的Session儲存
在使用這種方式時，可以直接使用HashTable。至於為什麼使用HashTable而非HashMap，原因非常簡單HashTable是執行緒安全的，而且HashTable不支援null作為key或者value。HashTable中key可以使用者名稱/使用者ID，value為這個使用者的Session。
這種方式的優點在於:
實現簡單；
速度快。這種方式無疑是這三種方式中最為快速的；
這種方式的缺點在於：
備份困難；
所有的資料都在同一臺機器上，這臺機器容易成為單點故障；
Session集合的總容量受到Session伺服器的記憶體大小限制；
難以以叢集的方式進行工作；
4. StickySession
採用這種策略時，某一個使用者所有的請求都會對映到某一臺應用伺服器。無論這臺伺服器是否是非常空閒，還是非常繁忙，這臺機器上的使用者請求仍然會再次對映到這臺機器上。
為了達到Session Sticky，有多種負載的策略：
1. IP Hash
IP Hash策略下，將所有的應用伺服器列成一個Hash表，這個表中的每一個元素即是一臺應用伺服器。負載均衡器的負載策略是根據使用者的IP，將使用者的IP Hash到以上所談及到Hash表中。一般而言，使用者的IP不會有變化，Hash值也是不會變化的，因而使用者的請求會一直對映到某一臺應用伺服器上。當用戶的數量非常龐大的時候，一般使用者的IP也比較分散，這種策略的效果也比較好。而且，這種方式的實現也非常簡單，只需要對負載均衡器進行一定的配置便可，而不需要對業務系統做出任何的修改。
2. 使用者名稱Hash
在現在Web系統中，一般都會有註冊使用者，而且只有註冊使用者才可以使用其釋出的服務。使用者名稱Hash，其原理、優缺點與IP Hash基本上是相同的，只是Hash函式的輸入不再是使用者的IP地址，而是使用者的使用者名稱。而使用者名稱的提供主要有兩種方式，一種是每一個請求URL都會帶上自己的使用者名稱，第二種是將使用者名稱放在客戶端的Cookie中。在第二種方法中，如果客戶端不提供Cookie，那這種策略將會無法執行。
3. 首次登陸時間Hash
這種Hash策略的原理也非常容易想象，不再是使用者的IP地址或者使用者名稱，而根據使用者登陸系統的時間來進行Hash。同樣，首次登陸時間的提供主要有兩種方式，一種是每一個請求URL都會帶上自己的登陸時間，第二種是將登陸時間放在客戶端的Cookie中。在第二種方法中，如果客戶端不提供Cookie，那這種策略將會無法執行。
快取管理
1. 採用服務的方式
這是一種最直接的方式。當然服務的方式可以多種多樣，比較簡單的方式是提供一個ClearCache.aspx的頁面，當實體資料發生變更之後呼叫N多臺Web應該的這個頁面。
2. 採用File Dependency的策略
這種策略讓快取依賴於一個指定的檔案，通過改變檔案的更新日期來清除快取。這種方式的缺點是，如果快取的資料比較多，相關的依賴檔案比較鬆散，對管理這些依賴檔案有一定的麻煩。對於負載均衡環境下，還需要同時更新多臺Web伺服器下的快取檔案，如果多個Web應用中的快取依賴於同一個共享的檔案，可能會省掉這個麻煩，但是對Web應用中執行帳號的許可權所限，終歸不是那麼簡潔。
3. 採用SqlCacheDependency的策略
這種策略讓快取依賴與資料庫中指定的資料（查詢結果）。可以用Poll的方式主動呼叫，設定一個週期，迴圈呼叫查詢語句，如果查詢結果發生變化，就會清除快取。也可以配合Sql Server 2005，採用Push的方式被動的被通知什麼時候會清楚快取。這種Push的方式是基於Sql Server 2005中Broker Service的訂閱服務，SqlCacheDependency需要配合SqlDependency來實現這種方式。
文章原地址：http://www.douban.com/note/269093631/