Memcached存Session数据、访问安全性、使用场景总结（3）
最近做了一个单点登录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约定和命名规范很重要，方便以后进行维护。
