PHP中最可靠的会话存储是什么：内存缓存，数据库或文件？[关闭]

什么是处理PHP会话的最佳，最安全的方法。是将会话存储在以下位置的最佳方法：

1. 数据库（更可靠，但瓶颈大，速度慢，不利于数据库使用率高的网站）？

2. Memcache（超快，但分布更多的安全问题，服务器重新启动时丢失数据的可能性以及缓存已满时丢失数据的机会）？

3. 文件（默认选项，我猜很慢，因为它从文件I / O读取和写入文件，降低安全性，等等）。

哪种方法最好？每种方法的问题和优点是什么？

最好将其存储在Memcached中，因为我们可以轻松解决其他问题（缓存大小，安全性等）

Facebook是Memcached的第一大消费者。如果有兴趣，请阅读：http : //www.facebook.com/note.php?note_id=39391378919

如何解决其他问题？

• /programming/235470/how-to-effectively-implement-sessions-in-gae
• http://bakery.cakephp.org/articles/rynop/2010/09/10/using-memcached-to-run-your-sessions
• https://groups.google.com/forum/?fromgroups=#!topic/web2py/lDQspjf0RIk

对于绝大多数的日常应用程序，将会话保持在数据库中就可以了。sql服务器可以处理的并发量和并发水平将绰绰有余。关键是使每个条目的大小保持较小，并定期清除不需要的行。当然，还有正确的索引编制。

文件系统-我从未见过这样做的需要。我更喜欢管理表中行的简单性，而不是数千个小文件。另外，如果您想了解会话统计信息，则无法跨文件查询。

请记住，使用PHP，它很容易换出会话处理程序。因此，您可以从一种存储格式开始，然后再轻松地迁移到另一种存储格式。

如何在MySQL中使用MEMORY存储引擎？

它的速度不如Memcache快，但具有可以使用普通SQL的优势，并且在不需要它时也可以使用普通的存储引擎，并在用户/请求数量增加时切换到MEMORY。

我将其用于在经常更改的Web应用程序中存储大量统计数据，因此它不用于处理会话，但我认为它应该非常适合此目的。

这篇博客文章显示了使用Magento对不同会话存储引擎进行性能比较的结果，他们似乎得出的结论是，多达约75个并发用户之间并没有真正的性能差异。

我认为，在这些级别上（它们每秒大约有5个事务，在12小时内大约有430k次命中），其他所有方面的开销都决定了您看到的性能数字，因为文件/ DB / Memcache / Redis都会很高兴地处理如果使用得当，交通不会流汗。

剩下其他因素，例如可伸缩性，可靠性和安全性。

我首先要说的是，任何损害您文件存储的东西也可能会损害其他任何东西，因为攻击者随后可以修改您的应用程序代码，或者至少可以发现密钥和存储访问协议/凭证，即使它们具有只读权限也是如此。访问。文件存储将在低容量站点上正常工作，易于设置且易于推理。就像您说的那样打磁盘，数据库读取也将打磁盘，如果数据库可以缓存它，则您的操作系统也可能缓存了会话文件。此外，仅读取其一个文件，如果您已经知道它的名称，那么您的文件系统就非常擅长使用它。如果您使用的是PHP，您是否知道系统仅需要为服务您的应用程序读取多少文件？缺点是你可以

Memcache相对较快，如果您更广泛地考虑Memcache类解决方案（Redis等），那么有些甚至可以保证持久的内存读取速度，因此您可以充分利用这两个方面。它们的原因也相对简单，并且会话的键值性质正是这些对象设计的目的。您知道要参加一次会议才能填补其中之一吗？无论哪种方式，如果您达到了自己的能力，所有选择都会迫使您做出让步。磁盘填充了文件（此处为数量和大小系数），高速缓存存储填充了容量，数据库的行数有限，并且磁盘容量限制与文件方法相同。此外，仅当您以分布式方式运行它们时，这些系统才是分布式的。多数工作仅需通过单个服务器即可完成。如果分发它们，则可能已经有分布式Web服务器/数据库服务器等，因此在会话存储选择中肯定不会出现分布式系统问题。但是，当您想要流量/容量等的10倍时，使用这种方式比使用文件存储方案自然得多。一些键/值存储还使您可以相对轻松地对会话数据进行简单分析，但是大多数都无法使您接近SQL所能做的事情。

我不确定为什么您提出数据库可能比其他选项更可靠的方法，但是由于您的PHP应用程序可能已经在使用数据库，因此数据库吸引了我。这意味着您无需添加其他服务器依赖项，并且可以重用用于获取会话数据的相同连接来获取用户数据，因此不必为数据建立连接，而为Memcache建立连接，等等。表格运行良好，它也将以相当快的速度执行，并提供您已经熟悉的用于获取旧会话甚至分析会话数据的非常简单的语义（我不确定您为什么要这样做，如果您也不愿意，这可能就不会了）这么重要）。大规模扩展并不像Redis这样简单，

我认为这种选择在一开始并不那么重要。每种方法都有挑战和优势，您必须考虑一些事情。一般来说，仅使用PHP /所用框架的默认值，甚至最简单的方法就可以摆脱困境。如果后来发现选择不好，您的性能分析将告诉您，并且您将获得根据所获得流量的特定性质做出正确选择所需的数据。首先，您可以合理地拥有的只是一般的猜测。

这取决于您的需求。

文件和数据库存储之间存在一些差异。看到这个问题。

但是，您可以默认执行Rails 3中的操作，并且仅在会话中使用加密的cookie。因此，您以所有以后只能对其解密的方式（例如，私钥/公钥）对所有值进行加密，然后让客户端为您保留状态。

一方面，它将您限制为4Kb，这实际上通常就足够了（因为您通常要存储ID，而不是整个对象），但是您获得的真正好处是您无需担心会话清理。您将其留给客户，实际应该在哪里。

对于我的特殊情况，我可以告诉您，数据库中的会话是造成服务器挂起的主要原因之一。我们的会话表经常被破坏，以至于我们不得不先将其截断。

内存缓存听起来很吸引人，但我们有太多的流程可以清除整个内存缓存，因此用户会话将被频繁切断。并且随着内存变满，较旧的会话将被清除...因此不再需要永久登录。

我们将很快尝试默认的基于文件的会话。

如果您担心会话数据的安全性，那么您不应该将该数据放入会话中-并且不要信任会话-在每个请求上验证用户。

您可以尝试将会话保存在Redis上。Redis像Memcached一样快速，但也有几个数据持久性选项。此外，还支持各种PHP客户端。

此外，您可以尝试具有内置复制和存储引擎功能的第三方服务，例如Memcached Cloud

披露，我是Garantia Data的联合创始人兼CTO。