會話保持(Session Affinity),有時又稱粘滯會話(Sticky Sessions), 是負載均衡領域設計需要著力解決的重要問題之一，也是一個相對比較複雜的問題。
會話保持是指在負載均衡器上的一種機制，在完成負載均衡任務的同時，還負責一系列相關連的訪問請求會分配到一臺服務器上｡
當用戶向服務器發起請求，服務器創建一個session，並把session id以cookie的形式寫回給客戶。
看一個例子：當我訪問SAP UI5應用時，
在http請求的頭部觀察到客戶端要求服務器返回以cookie的形式返回session id的請求字段：
在服務器響應的頭部字段果然返回了session id：
這些cookie信息能夠在Chrome開發者工具的Application標籤頁裡的Cookies區域查看：
如此一來，只要客戶的瀏覽器不關，再去訪問服務器時，訪問請求會自動附上session id去，服務器端檢測到這個session id後，就會使用內存中維持的與這個id對應的session為客戶端服務。
再回到我們討論的會話保持這個話題。什麼時候需要會話保持？舉個大家每天都會遇到的例子，大家在淘寶或者京東上購物時，從完成用戶身份認證到瀏覽店鋪，選擇心儀商品加入購物車，一直到最後下單完成支付，需要經過很多次和服務器的交互過程才能完成整個交易。由於這幾次交互過程從順序上和邏輯上是密切相關的，服務器在進行這些交互過程的某一個交互步驟時需要一個上下文(Context)，即上一次交互過程的輸出，因此要求這些相關的交互過程都由一臺服務器完成。
在這種情況下，假設負載均衡器仍然把這些相關交互session分散到不同的服務器實例上，就會帶來很糟糕的用戶體驗，比如客戶在瀏覽器上每點擊一次，都會彈出登錄頁面。或者即使用戶輸入了正確的驗證碼，卻仍然提示驗證碼錯誤。由於服務器處理實例不一樣，也有可能造成客戶放入購物車的物品丟失。
這就是會話保持機制引入的原因：確保把來自同一客戶的一個完整會話的請求轉發至後臺同一臺服務器進行處理。
那麼Cloud Foundry的Session Affinity是怎麼實現的呢？
官方文檔有介紹：
https://docs.cloudfoundry.org/concepts/http-routing.html#sessions
(1) To support sticky sessions, configure your app to return a JSESSIONID cookie in responses. The app generates a JSESSIONID as a long hash in the following format:
您的應用在響應結果裡需要加上一個JSESSIONID字段，長度如下：
1A530637289A03B07199A44E8D531427
(2) If an app returns a JSESSIONID cookie to a client request, the CF routing tier generates a unique VCAP_ID for the app instance based on its GUID in the following format:
CF routing tier基於app生成的JSESSIONID生成一個VCAP_ID: 323f211e-fea3-4161-9bd1-615392327913
(3) 接下來客戶每次發起請求，必須同時提供JSESSIONID和VCAP_ID。JSESSION_ID交給應用，用於實現session粘連。而VCAP_ID用於標識服務的應用實例，如果應用掛了，gorouter會把請求路由到另一個應用實例上。
閱讀更多 汪子熙SAP 的文章
