用于会话存储的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交换非常容易，反之亦然。

Answer 2

根据情况，使用任一选项可能更好。 使用memcached为您提供速度但受RAM限制。 MySQL或其他数据库引擎的优点在于它提供了更大的存储容量，最重要的是，当我们将多个服务器用于特定的Web应用程序时，集中会话。