前面的文章中介紹過session，和cookie一樣也是一種會話技術，但是是存在服務端的，主要作用就是通過服務端記錄使用者的狀態。推薦閱讀：萬字詳解認證授權
只要使用者不重啟瀏覽器，每次http短連線請求，理論上服務端都能定位到session，保持會話。
但是只有一台web伺服器提供服務時，是無法保證服務的高可用的。為了保證高可用，有多台web伺服器時，每次http短連線請求就不一定能路由到正確的session了。
多個web伺服器之間相互同步session，這樣每個web伺服器之間都包含全部的的session。
優點：web伺服器支援的功能，應用程式不需要修改**。
缺點：服務端儲存所有使用者的session，記憶體占用較大，可以將session儲存到瀏覽器cookie中，每個客戶端只要儲存乙個使用者的資料了。
優點：服務端不需要儲存。
缺點：
這種方式不常用。
多個web伺服器為了保證高可用，有多台冗餘，反向**層可以通過一些手段，讓同乙個使用者的請求保證落在一台web伺服器上。
反向**層使用使用者ip來做hash，以保證同乙個ip的請求落在同乙個web伺服器上。
反向**使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同乙個瀏覽器使用者的請求落在同乙個web伺服器上。
優點：
缺點：
session一般是有有效期的，所以不足中的兩點，可以認為等同於部分session失效，一般問題不大。
將session儲存在web-server後端的儲存層，資料庫或者快取。
優點：
缺點：增加了一次網路呼叫，並且需要修改應用**。
對於db儲存還是cache，個人推薦後者：session讀取的頻率會很高，資料庫壓力會比較大。如果有session高可用需求，cache可以做高可用，但大部分情況下session可以丟失，一般也不需要考慮高可用。
保證session一致性的常見方法：
session一致性的解決方案
伺服器為每個使用者建立乙個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同乙個上下文，這個相關資訊就是session。這樣，當使用者在應用程式的web頁之間跳轉時，儲存在session物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。session是對http無狀態協議的補充，達到狀態...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
如何保證Session一致性
session同步法 多台web server互相同步資料，缺點是水平擴充套件受限，因為每台web server都是儲存所有的session 客戶端儲存法 session儲存到瀏覽器cookie中，每個客戶端只要儲存乙個使用者的資料了。缺點是占用外網頻寬 大小受限 因為cookie有大小限制 反向 ...