分布式session有以下幾種方案：
1. 基於nfs(net filesystem)的session共享
將共享伺服器目錄mount各伺服器的本地session目錄，session讀寫受共享伺服器io限制，不能滿足高併發。
2. 基於關聯式資料庫的session共享
這種方案普遍使用。使用關聯式資料庫儲存session資料，對於mysql資料庫，建議使用heap引擎。 這種方案效能取決於資料庫的效能，在高併發下容易造成表鎖（雖然可以採用行鎖的儲存引擎，效能會下降），並且需要自己實現session過期淘汰機制。
3. 基於cookie的session共享
這種方案也在大型網際網路中普遍使用，將使用者的session加密序列化後以cookie的方式儲存在**根網域名稱下（比如taobao.com），當 使用者訪問所有二級網域名稱站點式，瀏覽器會傳遞所有匹配的根網域名稱的cookie資訊，這樣實現了使用者cookie化session的多服務共享。 此方案能夠節省大量伺服器資源，缺點是儲存的首席資訊官度受到http協議限制；cookie的資訊還需要做加密解密； 請求任何資源時都會將cookie附加到http頭上傳到伺服器，占用了一定頻寬。
4. 基於resin/tomcat/iis等web容器的session機制
利用容器機制，通過配置即可實現。
5. 基於zookeeper的分布session儲存
詳見6. 基於redis/memcached的session共享儲存
這些key/value非關係儲存有較高的效能，輕鬆達到2000左右的qps，內建的過期機制正好滿足session的自動實效特性。
以上方案各有優缺點，本文主要介紹第六種基於redis儲存session時，如何實現動態擴容。 redis目前並沒有內建高可用集群，很多客戶端**基於一致性hash演算法能夠實現分布式儲存，但是擴容並不方便（需要成倍擴容），目前我們採用了** fourinone中session方案的思想：
a. 用於儲存session的redis集群有多個redis節點
b. proxy記錄了每個節點加入到集群的時間，並按照時間順序對節點進行了編號(0—n)
c. session key的生成演算法方面，需要在session key中包含生成時的當前日期（可考慮細化到小時還是分秒），在session key生成後，再進行取模運算 hash(sesionkey)%redishost_count, 根據取模結果決定當前session值儲存到落到哪個節點上儲存。
d. 再通過sessionkey獲取session資訊時，根據當前sessionkey取出時間部分，再根據取出的時間與redis集群中所有的節點的新增 時間進行比較，篩選出所有addtime
但是對於這種部署結果如何能夠保障高可用性，如何應對單點故障，後續會在redis高可用方案中介紹。
分類:
架構標籤:
session,
分布式session
分布式session的方案
1 如何實現分布式session，保證在分布式的條件下讓使用者只登陸一次就可以？方案 一 使用cookie tair的方式實現 cookie存放sessionid給服務端，服務端根據sessionid獲取tair中具體的session資訊 二 使用spring session的方式實現 這種方式，更...
分布式Session解決方案
在分布式環境中，瀏覽器端傳送的請求經負載均衡後分配到不同的伺服器，因此存在session無法共享的問題。解決方案有如下幾種 即將資訊儲存在cookie中。由於cookie是儲存在客戶端瀏覽器中的，存在一些安全隱患，而且cookie的儲存大小和型別存在限制，只能儲存少量資料。session複製是小型企...
解決方案 分布式session
多個伺服器之間同步session，使每台伺服器上都儲存所有的session資訊。優點 缺點 通過在負載均衡器上進行配置，根據session的一些特有標誌，如ip位址，sessionid等，分配後端應用伺服器，氣候該使用者的所有請求都會 到第一次分配到的伺服器上。優點 缺點 客戶端利用cookie記錄...