分布式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存儲
詳見http://my.oschina.net/u/699015/blog/159654
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<sessionkey_time的節點，再進行c中的取模計算，由於即使這期間進行了擴容，由於進行了時 間匹配，redisHost_count也不會發生變化，所以取模結果和存儲此session時一樣，還會落到當時存儲這個session的節點上，在那 個節點能夠得到此session的值。
但是對於這種部署結果如何能夠保障高可用性，如何應對單點故障，后續會在redis高可用方案中介紹。