用于会话存储的Memcached或MySQL - PHP

Question

使用Memcached与PHP进行会话存储是个好主意吗？我们将拥有大量服务器,我们必须从任何地方访问会话数据,因此我们被迫使用数据库(在我们的情况下将是MySQL)作为会话存储或Memcached.你怎么看？

Answer 1

我知道那些曾经使用过Memcached的人 - 它非常快,当然比数据库快得多,而且是为了处理更多的并发而构建的.

纯内存存储的主要缺点是,如果/当您重新启动守护程序时,将擦除所有会话数据.根据我的经验,memcached是坚如磐石的,我从来没有因为失败而重新启动它,但如果您的系统管理员不习惯以这种方式工作,或者您的系统经常更新,那么这是一个考虑因素.它还取决于是否每月或每年丢失所有用户会话是否可接受(即在电子商务中,管理层可能不会喜欢这样).

显而易见的解决方案,如果是这样的话,是去许多基于磁盘的NoSQL /哈希表的数据库,如一个MemcacheDB,这是基于关闭的Memcached的.或者看看:CouchDB,MongoDB等等.每个守护进程(包括Memcached)在性能调优方面都比MySQL要复杂得多(其中包括密钥和排序缓冲区,查询缓存等等各种事情都需要调整每个安装/用例) - 我的意思是,使用Memcached除了分配内存并启动它之外别无他法.

就个人而言,我喜欢使用更快,更合适(非SQL)的存储来处理会话密钥之类的临时事务,但如果您的数据库没有负载并且您没有预料到它,那么您唯一丢失的就是存储数据库中的会话是慢一点,所以用户看到更多的延迟.

无论你采用哪种方式,我建议你以一种存储引擎只是一层的方式编写会话管理代码,并且可以相对轻松地交换不同的存储引擎.如果您发现memcached或您选择的任何内容都不正常,并且您想尝试其他内容,则不希望重新编码您的应用程序.例如,我曾经为集群CMS应用程序编写了一个缓存系统,该应用程序使用memcached来缓存各种页面和对象,但是当守护程序无法访问时,它会故障转移到备用后端,后端将缓存到共享内存或磁盘上.个人网络服务器.(在您的情况下,您不一定需要自动故障转移,只需改变您对后端的想法.)

我提到了MemcacheDB因为它使用了Memcache协议,因此在Memcached中为MemcacheDB交换非常容易,反之亦然.