SQLite 作为会话存储

Posted 2023-03-08

【中文标题】SQLite 作为会话存储

【英文标题】：SQLite as a Session Storage

【发布时间】：2012-11-12 16:57:25

【问题描述】：

我想知道将 SQLite 用作主会话存储或至少用作主 memcached 的备份会话存储是一种好习惯吗？

你能告诉我一些优点和缺点吗？

（我正在构建一个用于教育目的的 MVC 框架，并且正在考虑不同的可能性和实现方式）

【参考方案1】：

SQLite 专业人士

比基于文件的会话更快 可以分布在基于文件的会话比较尴尬的地方

SQLite 缺点

需要 SQLite 来创建依赖项和其他要监控的内容 更难实现基于本机文件的会话 大型应用程序可以通过如此多的读写请求、碎片、索引更新等快速杀死 sql 表，尤其是几乎每个页面都命中该特定表时

更好的解决方案 - 内存缓存

由于会话通常在每个页面点击时被访问，因此使用尽可能快的机制而不需要数据库层的所有开销同时仍然允许它在分布式系统中工作（例如多个 php 服务器）是有意义的。

使用经过 PHP 良好测试的 Memcache，您甚至可以通过修改一些 php.ini 设置或更细粒度的控制（或使用其他软件，如 redis）来集成 memcache 会话，您可以创建自己的自定义会话处理程序.

这有不同的优点和缺点

Memcache 专业人士

非常非常快 很好地扩展 通过 PHP.INI 轻松实现

Memcache 缺点

另一个有可能崩溃并需要监控的服务 使用 RAM，与 HDD 空间相比，它通常是有限的资源，还需要监控

虽然您应该使用其他软件来监控这两种情况，或者编写一个 cron 作业脚本来检查 memcache 服务是否仍在运行 - 但那是另一天的另一个问题和答案。关键是，这些缺点可以在一定程度上减少。

进一步阅读所涵盖的主题

Memcache sessions using PHP.INI Redis Custom PHP Session Handler

【讨论】：

OK 如果我可以同时使用它们，如果可以访问的话，那该怎么办.. 假设主要是 memcache/d 并且当创建一个新的以添加到 SQLite 和 SQLite 时，仅在以下情况下使用memcache/d 宕机了？

初级和次级会话？啊！？不，只使用 memcache - 你不会相信它与 SQLite 或基于文件的会话相比有多快。如果内存缓存已关闭，请重新启动它！在流量很大的站点下，如果 memcache 的使用率为 50%，那么当它回退到 SQLite 时，它​​很可能会崩溃！！！您将从 memcache 中获得比 sqlite 更高的性能，这意味着您不能依赖它。如果你想依赖某些东西，它至少必须是基于内存的（例如 APC，但是它不会分发，因为它只是一个本地缓存）。

拥有一个故障安全替代方案不是更好吗？

对于重启 memcache 所需的时间以及您可以将 memcache 分布到多台服务器这一事实 - 它具有内置冗余，因此即使一个崩溃，另一个仍然可以接管。

所以内存缓存实例/服务器必须像镜像，否则我错了？

【参考方案2】：

基于文件的会话是个坏主意，因为如果您不关闭对会话的写访问（ session_write_close(); ），文件将被锁定。但是当你不得不使用 sqlite 来避免这个问题时，你为什么要限制自己/theServer？

所以 sqlite专业版： - 易于使用（更改 php.ini 配置）：

session.save_handler = sqlite
session.save_path = "/path/sessions.db"

加载页面更快（会话现在可以并行工作） 使用 ajax 更快 内置功能

sqlite 配置

写入会话较慢

我想使用 apc，但我需要实施，我担心它可能会导致安全问题......

【讨论】：

如果你使用 APC，你可以加密会话中的数据，但它会消耗你更多的执行时间。

感谢您也提供示例配置并提及 blocking 文件问题。

【参考方案3】：

PHP 的基于文件的会话非常好而且速度很快，使用 SQLite 存储会话只会增加会话管理的开销。