“会话”存储比较和失效与清理

比较“会话”存储选项
对于这么多“会话”选项，我应该为应用程序选择哪一个呢？回答是“依赖”。
如果排除过于单纯的内存存储，太多约束的文件存储，和过于复杂的memcached 的话，
就剩下在PStore，ActiveRecordStore 和DRb 存储之间选择了。我们可以交叉比较这些选项
的性能和功能。
Scott Barron 对这些存储选项有着完美的分析。它的朋友有些惊讶。对于少量的“会话”，
PStore 和DRb 几乎一样。当“会话”数量急剧上升时，PStore 性能开始下降。这或许是因为
主机操作系统在努力维护有数十万个“会话”文件的目录引起的。DRb 的性能还很正常。
ActiveRecordStore 开始时性能不好，但在“会话”量急剧上升时则表现正常。
对于你意味着什么呢？Bill Katz 的总结如下：
对于性能来说，这不是绝对的，每个人的情况不同。你的硬件，网络时间，数据库的选
择，甚至是天气都有影响到它们。我们最好建议是用最简单的，能工作的解决方案。
如果你应用程序只运行在一个服务器上，你为“会话”存储的最简单选择是Pstore。它
对一定数量的活动“会话”性能还不错，并且它的配置最小。
如果你的应用程序同时会有超过10，000 的“会话”，或者它运行在多个服务器上，我
们建议你使用ActiveRecordStore 解决方案。如果你的应用程序增长很快，你发现这变成瓶颈，你可以迁移到Drb。
“会话”失效与清理
所有解决方案的共同问题是“会话”数据被存储在服务端。每个新“会话”添加一些“会
话”存储。你终将需要一些家务式的管理，或者你将在服务器外寻找资源。
其它原因是清理“会话”。许多应用程序不要一个“会话”永存。一旦来自一个特定浏
览器的用户被日志，应用程序可能会想强迫这样的规则给用户，在它们活动期间被日志；在
它们登出时，或在使用应用程序一个固定时间之后，它们的“会话”应该被中止。
有时候你可以通过失效cookie 持有的“会话”id 来达到这一目的。但是，这会被最终
用户滥用，更坏的是，它很难在浏览器上通过清理服务端内的“会话”数据来同步cookie 的
失效期。
因此我们建议通过简单地移除服务端“会话”数据来失效你的“会话”。浏览器随后到
达的的请求应该包含已经被删除数据的“会话”id，应用程序将不会重新收到“会话”数据；
“会话”将不再有效。
实现这种失效方式依赖于使用的存储机制。
对于PStore“会话”，通过周期性地运行一个清理任务很容易地达到。这个任务应该检
查“会话”目录内文件被最后修改的时间，删除比给定时间晚的文件。
对于基于“活动目录”的“会话”存储，我们建议在session 表内定义created_at，
updated_at 列。你可以删除在最后一小时内所有没被修改的“会话”，通过使用SQL 的清理
任何如：
delete from sessions
where now() - updated_at > 3600;
基于DRb 的解决方案，失效被放在DRb 服务端处理。你或许想在“会话”数据哈希表内
记录时间戳。你可以运行一个单独的线程(或是单独的进程)，它周期性地删除这个哈希表内
条目。
在所有情况下，你的应用程序可以在它们不再被需要时(例如，当一用户登出时)，通过
调用reset_session()来删除“会话”帮助这种处理。