mysql - 用于 session 存储的 Memcached 或 MySQL - PHP

Question

将 Memcached 用于 PHP session 存储是个好主意吗？我们将有很多服务器，我们必须从任何地方访问 session 数据，因此我们被迫使用数据库(在我们的例子中是 MySQL)作为 session 存储或 Memcached。你怎么看？

Answer 1

我认识一些为此使用 Memcached 的人——它非常快，肯定比数据库快很多，而且是为处理更多的并发而构建的。

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

如果是这种情况，显而易见的解决方案是转到许多基于磁盘的 NoSQL/哈希表数据库之一，例如 MemcacheDB ，它基于 Memcached。或查看:CouchDB , MongoDB等等。在性能调整方面，这些守护进程(包括 Memcached)中的每一个都比 MySQL 复杂得多(在 MySQL 中，诸如键和排序缓冲区、查询缓存等各种东西都必须根据安装/用例进行调整) -- 我的意思是，对于 Memcached，除了分配内存和启动它之外没有什么可做的。

就个人而言，我喜欢使用更快、更合适的(非 SQL)存储来存储 session key 等临时内容，但是如果您的数据库没有负载并且您没有预料到它，那么您唯一需要做的就是将 session 存储在数据库中的缺点是速度稍慢，因此用户会看到更多的延迟。

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

我提到 MemcacheDB 是因为它使用 Memcache 协议(protocol)，因此在 Memcached 中交换 MemcacheDB 非常容易，反之亦然。