引子：一般對session的分布式管理常用的有以下3中方式，當然必須是當訪問使用者達到一定的量級以後才有分布式session的概念
1）集群分組
2）一致性雜湊
3）放置前端cookie中
首先說說集群分組：
容災備份：重要的東西可以在memcached攢夠了乙個閥值，統一備份一次放到檔案中或者資料庫中，這樣在一台伺服器死掉後可以去資料庫拿資料放在另外一台伺服器上（這個有點耗時）
對於這個備份有比較成熟的解決方案，比如靠sina的開源外掛程式，memcachedb這個 可以把 memcached資料快取到 伯克利db裡面 ）
一致性雜湊：
這個比較普遍了，我以前的公司採用的就是這個辦法。具體演算法如下：
解釋：其實是這樣的，我們把所有的sessionid從前端使用者請求cookie中拿到 做gethashcode（sessionid）=key1，多個sessionid就是keyn。。。。，在用一直的雜湊演算法後得到的key永遠在乙個0~2的32次方內的定值，sessionid不同，這個key也就不同，這樣在0到2的32次方的數可以組成乙個閉環，在把我們的memcached伺服器也採用統一的hash演算法一般是gethashcode（memcached id位址）這樣是不是伺服器的key也落到這個閉環裡面了，呵呵，從0開始向右，或者向左都行，一般是向右開始找key找到乙個key就放到離他最近的乙個伺服器的key中，這樣在2個node之間的key就可以放在右側的node伺服器中。怎麼知道key是sessionid算出來的，還是memcached ip位址算出來的呢，哈哈，大家自己想想，別想的太複雜啊。
放置前端cookie中：
這個也比較簡單，就是將使用者的登陸成功資訊放在cookie中，並設定乙個失效時間，當使用者請求web伺服器時，這個請求會經過乙個策略，這個策略會看cookie裡面的資訊，
如果發現已經登陸了，則將cookie裡面的資訊提出來使用者使用者基本資訊展示，並給出已登入介面。
如果發現未登陸，直接給出登入介面。
這個方法就是有些瀏覽器對cookie的大小是有限制的，所有要將你放入cookie盡可能的小，bool型的用0,1表示，字串編碼成數字最好。
好了，說了這麼多，我的手都打累了。
今天就到這裡吧。
C redis 分布式session儲存
乙個基於redis的session儲存擴充套件方案，解決asp.net中session的侷限性和跨應用程式使用的侷限性 1 branch 0 releases 1 contributor c 99.3 asp 0.7 c asp branch master sessionextentionstore...
C redis 分布式session儲存
乙個基於redis的session儲存擴充套件方案，解決asp.net中session的侷限性和跨應用程式使用的侷限性 1 branch 0 releases 1 contributor c 99.3 asp 0.7 c asp branch master sessionextentionstore...
分布式session共享
為什麼會出現session共享問題？客戶端與伺服器互動時會產生唯一的sessionid用於標記使用者，但是在分布式架構中，如果還是採用 session 的方式，使用者發起請求，通過 nginx 做請求 時，並不知道是 到伺服器1還是伺服器2，所以就會出現session共享問題。今天主要記錄使用 sp...