Memcached存Session數據、訪問安全性、使用場景總結（3）

最近作了一個單點登陸SSO，登錄後的憑證放到Memcached令牌放到Cookies；可是用戶常常掉線，開發環境和測試卻沒有這個問題，最後從Memcached找到緣由。

Memcached概念、做用、運行原理、特性、不足簡單梳理（1）

Memcached下載安裝、NET對Memcached進行CRUD操做（2）

Memcached存Session數據、訪問安全性、使用場景總結（3）

1、Session數據放入到Memcached？

Memcached建立者Dormando寫過兩篇文章：

Sessions in Memcached

Cache your sessions. Don't piss off your users

第一篇文章中指出：若是用memcached存儲Session，那麼當memcached集羣發生故障（好比內存溢出）或者維護（好比升級、增長或減小服務器）時，用戶會沒法登陸，或者被踢掉線。

第二篇文章中指出：Memcached的回收機制可能會致使用戶平白無故地掉線。

對於Dormando的那兩篇文章，他認爲第一篇文章給出的緣由很容易理解，而人們常常會對第二篇文章給出的緣由認識不足。所以他對這個緣由進行了詳細地闡述：

Memcached for Dummies

Memcached使用「最近最少使用（LRU）」算法回收緩存。但memcached的LRU算法針對每一個slab類執行，而不是針對總體。這意味着，若是全部Session的大小大體相同，那麼它們會分紅兩三個slab類。全部其它大小大體相同的數據也會放入同一些slab，與Session爭用存儲空間。一旦slab滿了，即便更大的slab中還有空間，數據也會被回收， 而不是放入更大的slab中……在特定的slab中，Session最老的用戶將會掉線。用戶將會開始隨機掉線，而最糟糕的是，你極可能甚至都不會注意到它，直至用戶開始抱怨……

能夠看來Memcached是一個設計用於緩存數據而不是存儲數據的系統，所以不該該用於存儲Session。

建議開發人員不要用memcached存儲Session。

 

2、什麼樣的數據適合放Memcached

不適合的狀況：

1.若是是一個小網站，pv值不大，不考慮Memcached

2.變化頻繁, 一變化就要入庫（股票，金融),不考慮Memcached

3.過大的數據不能放入到Memcached

4.緩存對象的大小大於1MB 

5.key的長度大於250字符

 

適合的狀況：

1.變化頻繁，查詢頻繁，可是不必定寫入數據庫(好比用戶在線狀態、在線人數..適合Memcached)

2.變化不頻繁，查詢頻繁,無論入不入庫,都比較適合Memcached。

 

3、Memcached訪問安全性

Memcache服務器端都是直接經過客戶端鏈接後直接操做，沒有任何的驗證過程，這樣若是服務器是直接暴露在互聯網上的話是比較危險，輕則數據泄露被其餘無關人員查看，重則服務器被入侵，由於Mecache是以root權限運 行的，何況裏面可能存在一些咱們未知的bug或者是緩衝區溢出的狀況，這些都是咱們未知的，因此危險性是能夠預見的。

內網訪問：最好把兩臺服務器之間的訪問是內網形態的，通常是Web服務器跟Memcache服務器之間。廣泛的服務器都是有兩塊網卡，一塊指向互聯網，一塊指向內網，那麼就讓Web服務器經過內網的網卡來訪問Memcache服務器，咱們 Memcache的服務器上啓動的時候就監聽內網的IP地址和端口，內網間的訪問可以有效阻止其餘非法的訪問。

防火牆是簡單有效的方式，若是倒是兩臺服務器都是掛在網的，而且須要經過外網IP來訪問Memcache的話，那麼能夠考慮使用防火牆或者代理程序來過濾非法訪問。

 

4、總結

到這裏我想你對memcached也有了些瞭解。

Memcached不是一個數據庫，不是存儲數據的系統，他只是內存緩存數據系統。

Memcached不是信息的惟一來源，是來輔助數據庫操做的，來提高信息的查詢速度。

Memcached是key-value存儲，因此key約定和命名規範很重要，方便之後進行維護。