Memcached创建者Dormando非常早就写过两篇文章[1][2]。告诫开发者不要用memcached存储Session。
他在第一篇文章中给出的理由大致是说,假设用memcached存储Session,那么当memcached集群发生问题(比方内存溢出)或者维护(比方升级、添加或降低server)时,用户会无法登录。或者被踢掉线。而在第二篇文章中。他则指出。memcached的回收机制可能会导致用户无缘无故地掉线。
Titas Norkūnas是DevOps咨询服务提供商Bear
Mountain的联合创始人。
因为看到Ruby/Rails社区忽略了Dormando那两篇文章所指出的问题,所以他近日撰文对此进行了进一步的阐述。
他觉得问题的根本在于,memcached是一个设计用于缓存数据而不是存储数据的系统。因此不应该用于存储Session。
对于Dormando的那两篇文章,他觉得第一篇文章给出的原因非常easy理解,而人们常常会对第二篇文章给出的原因认识不足。
因此他对这个原因进行了具体地阐述:
Memcached使用“近期最少使用(LRU)”算法回收缓存。但memcached的LRU算法针对每一个slab类运行,而不是针对总体。
这意味着,假设全部Session的大小大致同样。那么它们会分成两三个slab类。全部其他大小大致同样的数据也会放入同一些slab。与Session争用存储空间。一旦slab满了。即使更大的slab中还有空间,数据也会被回收。而不是放入更大的slab中……在特定的slab中,Session最老的用户将会掉线。
用户将会開始随机掉线。而最糟糕的是,你非常可能甚至都不会注意到它。直至用户開始抱怨……
另外,Norkūnas提到,假设Session中添加了新数据,那么Session变大也可能会导致掉线问题出现。
有人提出将Session和其他数据分别使用单独的memcached缓存。只是,由于memcached的LRU算法是局部的,那种方式不仅导致内存使用率不高,并且也无法消除用户由于Session回收而出现随机掉线的风险。
假设读者很希望借助memcached提高Session读取速度。那么能够借鉴Norkūnas提出的memcached+RDBMS(在有些情况下。NoSQL也能够)的模式:
当用户登录时,将Session “set”到memcached。并写入数据库。
在Session中添加一个字段,标识Session最后写入数据库的时间;
每一个页面载入的时候,优先从memcached读取Session。其次从数据库读取。
每载入N页或者Y分钟后,再次将Session写入数据库。
从数据库中获取过期Session,优先从memcached中获取最新数据。
參考来源:
http://www.lai18.com/content/431361.html