php memcached存储对象,用于会话存储的Memcached或MySQL – PHP

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

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

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

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

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

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