總結
在展開話題之前，先看看乙個普通的分布式站點是咋樣的？
[1] 發生位置：使用者側（例如：瀏覽器）
[2] 實現方式：將使用者資訊（會話資訊）儲存在cookie中，在每次請求時，將這些資訊傳送到server進行解析；一般來說，cookie儲存的會話內容都會進行加密（例如：md5/sha等）；這種方式主要依賴於cookie的存在，cookie本身是儲存在使用者側，因此安全性不能得到保證，容易被串改和劫持；還有乙個點就是cookie儲存的內容是有限的，只能存在小資料；
互動流程:
總結：
1、cookie 本身問題（儲存有限、安全性不高）；
2、實現簡單；
如果出現cookie禁用情況，可以通過明文url傳遞引數可以解決，但是同樣是安全性問題；
[1] 發生位置：負載均衡（lvs）部分；
[2] 實現方式：負責均衡來記錄使用者方式伺服器的關係，例如：使用者1 訪問了 伺服器1，那麼每次確保使用者1路由到伺服器1，這樣就能確保和單機session的情況一樣，但是缺點就是：
1、lvs儲存了使用者側和伺服器的關係，變成了有狀態；
2、如果伺服器1掛了，那麼使用者1要麼無法訪問，要麼就需要進行重新登陸；
互動方式：
總結：通過中間負載裝置，每次使用者訪問時，會儲存使用者與伺服器之間的關係，確保每次該使用者都路由到同乙個伺服器，從而和單機情況基本一致，就不會出現重複登陸情況，那麼這種情況會導致兩個不好的點：
1、負載裝置：從無狀態變成有狀態，並且儲存了使用者和伺服器關係資訊，儲存容量也需要進行考慮；
2、單機場景：這種方式其實就是避免的分布式集群情況的session不一致問題，但是卻同樣引來了單點伺服器的問題，如果伺服器掛了：
a、負載均衡不做處理：那麼使用者是無法繼續訪問站點；
b、路由到其他可用伺服器，那麼需要使用者重新登陸；
[1] 發生位置：服務端集群側；
[2] 實現方式：後台伺服器之間進行session資料複製，這種方式僅僅適用於伺服器數量少的情況，如果多的話，伺服器之間的資料複製，會越來越到，這只是一種實現方式，正常情況不會這麼做的。
互動方式：
總結：
如果要在伺服器這一層來解決session問題，那麼只要確保伺服器之間session資料是一致的就可以，換句話說，1
-n號機儲存的session保持一致，那麼無論那一台伺服器掛了，都不需要重新登陸，這是實現的原理。那麼就需要提供乙個保證伺服器session一致的工具；如果說集群數量比較大，那麼複製的動作非常之大，假設1號機session變化（刪除、更新、增加）都需要同步到2
-n號機，負擔是非常之大的；一般只適用於小集群數量和使用者量少的情況，不是很推薦使用；
[1] 發生位置：儲存側（例如：db）
[2] 實現方式：將會話資料儲存在諸如：資料庫、redis等儲存裝置中；實現原理很簡單，就是集中session儲存，不會存在某個伺服器掛了，需要使用者重新登陸的情況，如果訪問量比較大的話，資料庫的壓力會比較大，這個可以通過做session
cache來提高效率（一般採用redis、memcache等）；
互動方式：總結：session複製是依據session資料一致的問題來解決的，那麼還有乙個思路就是：將session資料共享處理，集中化儲存。因此我們需要選擇乙個集中儲存session的儲存媒介（一般是資料庫，例如：mysql），這樣的化會建立三層關係：
第一層：伺服器session快取；
第二層：快取中介軟體（redis）；
第三層：儲存媒介（mysql）；
如果使用者進行訪問時，會先看訪問的伺服器session嚴重是否ok，如果不ok，那麼查詢redis，最後再查詢mysql，最終mysql不存在才需要使用者重新登陸。這裡需要注意的是：快取一致性的問題，本文不針對展開。
這種方式使用比較常見。
解決分布式session問題，我們針對比較常見的分布式站點的結構布局，在不同層通過不同的方法來解決session問題。可以分為：
1、使用者側：例如：瀏覽器，可以通過cookie儲存使用者密文驗證資訊，優點就是處理很簡單，缺點就是安全性問題；
2、負載側：單機環境下是不存在session問題，那麼我們可以通過負載路由策略來保證使用者的訪問到固定的機器上，這樣就構造了乙個單機環境，那麼單點環境存在的問題，在這裡依舊存在，例如：伺服器掛了，使用者訪問不了；雖然可以通過路由策略轉到其他可用伺服器，但是還是需要使用者重新登陸；
3、服務側：分布式環境下由於使用者流量匯入到不同的機器上，會導致每台機器儲存的session不盡相同，那麼使用者一會訪問伺服器，一會訪問伺服器2，就會導致使用者重新登陸，因此我們可以通過考慮伺服器間的session資料是一致的，這樣就需要乙個工具來保證session在變化時伺服器之間的session資料同步，這種方式很少使用，因為當使用者資料（session）多時，伺服器多時，會導致session的同步很多很頻繁，效率不好。但是也不失為一種解決方式；
4、儲存側：思路就是session資料共享，那麼就需要儲存session資料的媒介，一般會是資料庫；這樣就不會出現伺服器之間的session複製，同時也可以集中管理和維護session資訊，但是問題也有，就是當訪問量大的時候，資料庫可能成為瓶頸，這個可以通過加入cache層來解決問題，這種方式，比較常用；
Session以及模擬會話機制
初學者對session總是不明白咋回事，這篇文章將闡述這個問題，並且實操模擬會話機制。1，session實質是啥？存貯在伺服器端硬碟中的session檔案，乙個session乙個檔案。檔名 32位隨機編碼字串如伺服器 tmp目錄下 tmp sess 01aab840166fd1dc253e3b4a3...
聊聊Zookeeper之會話機制Session
我們在伺服器啟動zookeeper的時候能得知，zk服務端對外預設埠是2181。而客戶端連線到服務端上，其本質其實就是乙個tcp連線 長連線 當連線正式建立起來的時候，就開起來該次會話的生命週期了。有了會話之後，後續的請求傳送，回應，心跳檢測等機制都是基於會話來實現的。那對於zk的服務端來說，如何維...
SESSION會話技術
以下對session會話技術詳解 要了解點http協議理解更佳 http請求頭和http相應頭 在session start的時候，瀏覽器會向伺服器發出請求 在請求的同時，如果是第一次apache會給瀏覽器分配乙個session id便識別，到瀏覽器下次請求時就會攜帶 apache分配的sessio...