伺服器為每個使用者建立乙個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同乙個上下文，這個相關資訊就是session。這樣，當使用者在應用程式的web頁之間跳轉時，儲存在session物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。
session是對http無狀態協議的補充，達到狀態保持的目的
假設使用者包含登入資訊的session都記錄在第一台server上，反向**如果將請求路由到另一台server上，可能就找不到相關資訊，而導致使用者需要重新登入。
服務端不需要儲存
每次http請求都攜帶session，佔網路頻寬
資料儲存在客戶端上，並在網路傳輸，存在洩漏、篡改等安全隱患
session儲存的資料大小受cookie限制
由於技術不斷演進，客戶端儲存cookie出現了資訊全量cookie，cookie儲存sessionid和jwt三種方式，他們優缺點各異，可以點選筆者的另一篇部落格檢視相關介紹快速了解會話管理三劍客cookie、session和jwt
只需要設定配置，應用程式不需要修改**
session的同步需要資料傳輸，佔內網頻寬，有延時
所有server都包含所有session資料，資料量受最小記憶體的sever限制，水平拓展能力差
沒有安全隱患
可以水平擴充套件，支援快取集群或橫向拓展
增加了一次網路呼叫
需要修改應用**
session會話粘連：英文原詞為"sticky sessions"只需要改nginx配置，不需要修改應用**
可以支援server水平擴充套件
server水平擴充套件，rehash後session重新分布，會有一部分使用者路由不到正確的session
即使hash雜湊均勻，也不能保證server的負載均勻
分布式session一致性解決方案
在早期的時候，很多 由於使用者規模較小，都是採取的單機部署的模式，只用一台伺服器來承載使用者的請求，這時候session是存在同一臺伺服器上，所以能夠很容易實現會話跟蹤和保持。然而隨著使用者規模的擴大，單機部署模式已經無法承載所有使用者的請求了，這時候人們自然而然想到用多台伺服器來處理使用者的請求，...
快取一致性解決方案
通常為了提公升使用者體驗，專案裡面一些熱點資料我們會把它放入快取裡面，以商品庫存為例我們就可以把商品對應的庫存資料放入redis，查詢資料時先去redis裡面找，沒有找到再訪問資料庫，如果庫存資料有更新就同時去更新redis的快取資料，以此達到減輕資料庫壓力。這種對快取資料的處理看似沒有問題，實際上...
Session一致性的四種解決方案
前面的文章中介紹過session，和cookie一樣也是一種會話技術，但是是存在服務端的，主要作用就是通過服務端記錄使用者的狀態。推薦閱讀 萬字詳解認證授權 只要使用者不重啟瀏覽器，每次http短連線請求，理論上服務端都能定位到session，保持會話。但是只有一台web伺服器提供服務時，是無法保證...