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

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