最近做了一個單點登錄SSO，登陸后的憑證放到Memcached令牌放到Cookies；但是用戶經常掉線，開發環境和測試卻沒有這個問題，最后從Memcached找到原因。
Memcached概念、作用、運行原理、特性、不足簡單梳理（1）
Memcached下載安裝、NET對Memcached進行CRUD操作（2）
Memcached存Session數據、訪問安全性、使用場景總結（3）
Memcached創建者Dormando寫過兩篇文章：
Cache your sessions. Don't piss off your users
第一篇文章中指出：如果用memcached存儲Session，那么當memcached集群發生故障（比如內存溢出）或者維護（比如升級、增加或減少服務器）時，用戶會無法登錄，或者被踢掉線。
第二篇文章中指出：Memcached的回收機制可能會導致用戶無緣無故地掉線。
對於Dormando的那兩篇文章，他認為第一篇文章給出的原因很容易理解，而人們經常會對第二篇文章給出的原因認識不足。因此他對這個原因進行了詳細地闡述：
Memcached使用“最近最少使用（LRU）”算法回收緩存。但memcached的LRU算法針對每個slab類執行，而不是針對整體。這意味着，如果所有Session的大小大致相同，那么它們會分成兩三個slab類。所有其它大小大致相同的數據也會放入同一些slab，與Session爭用存儲空間。一旦slab滿了，即使更大的slab中還有空間，數據也會被回收， 而不是放入更大的slab中……在特定的slab中，Session最老的用戶將會掉線。用戶將會開始隨機掉線，而最糟糕的是，你很可能甚至都不會注意到它，直至用戶開始抱怨……
可以看來Memcached是一個設計用於緩存數據而不是存儲數據的系統，因此不應該用於存儲Session。
建議開發人員不要用memcached存儲Session。
不適合的情況：
1.如果是一個小網站，pv值不大，不考慮Memcached
2.變化頻繁, 一變化就要入庫（股票，金融),不考慮Memcached
3.過大的數據不能放入到Memcached
4.緩存對象的大小大於1MB
5.key的長度大於250字符
適合的情況：
1.變化頻繁，查詢頻繁，但是不一定寫入數據庫(比如用戶在線狀態、在線人數..適合Memcached)
2.變化不頻繁，查詢頻繁,不管入不入庫,都比較適合Memcached。
Memcache服務器端都是直接通過客戶端連接后直接操作，沒有任何的驗證過程，這樣如果服務器是直接暴露在互聯網上的話是比較危險，輕則數據泄露被其他無關人員查看，重則服務器被入侵，因為Mecache是以root權限運 行的，況且里面可能存在一些我們未知的bug或者是緩沖區溢出的情況，這些都是我們未知的，所以危險性是可以預見的。
內網訪問：最好把兩台服務器之間的訪問是內網形態的，一般是Web服務器跟Memcache服務器之間。普遍的服務器都是有兩塊網卡，一塊指向互聯網，一塊指向內網，那么就讓Web服務器通過內網的網卡來訪問Memcache服務器，我們 Memcache的服務器上啟動的時候就監聽內網的IP地址和端口，內網間的訪問能夠有效阻止其他非法的訪問。
防火牆是簡單有效的方式，如果卻是兩台服務器都是掛在網的，並且需要通過外網IP來訪問Memcache的話，那么可以考慮使用防火牆或者代理程序來過濾非法訪問。
到這里我想你對memcached也有了些了解。
Memcached不是一個數據庫，不是存儲數據的系統，他只是內存緩存數據系統。
Memcached不是信息的唯一來源，是來輔助數據庫操作的，來提升信息的查詢速度。
Memcached是key-value存儲，所以key約定和命名規范很重要，方便以后進行維護。