2009-08-05 112 views
3

您是否应该存储每个请求所需的用户信息 例如。角色,电子邮件,用户名等在会话中存储用户信息?

在会话中,或者可以转到数据库每次请求这些信息?

谢谢

回答

0

我宁愿为此使用加密的cookie。数据库调用在大型繁忙系统中可能会变得昂贵。会话没问题,但是如果你的会话后端是数据库驱动的,那也会变得很昂贵。显然,使用cookie时,您必须合并验证令牌检查。

+0

验证令牌检查?你的意思只是形式auth的东西? – Schotime 2009-08-05 13:06:43

+0

当然,取决于您的需求! – grenade 2009-08-05 13:33:21

0

这取决于你的意思是“应该”。我已经开发了几个使用会话来缓存用户信息的应用程序。该方法运行良好,并减少了每个Web请求所需的数据库往返次数。另一方面,它确实为你的Web服务器引入了状态,所以你必须坚持一个Web服务器,使用“病态会话”(这可以使管理Web服务器变得更复杂一些),或者开始存储会话信息在一个共享的数据存储中(这会消除你使用它的任何性能增益)。

0

会话数据也可以存储在数据库中,如果您的站点在Web Garden og Farm中运行,则该数据非常有用。如果会话正在运行InProc,则用户数据将被保存在内存中,这样做的速度要快得多,但代价是可扩展性。

另一种常见的方法是将其保存为ViewState,然后在每次回发时在客户端和服务器之间回传第四次,这当然会导致带宽命中,但是比InProc会话更好。

我个人喜欢会话状态更好,如果网站很小我运行InProc,如果/当网站增长时,我可以改变它来使用数据库。

3

如果您不打算进行负载均衡,那么会话状态是完全可以接受的。但是,如果会话状态配置为使用数据库持久性,那么请小心,因为那样您不仅会触碰数据库,还会产生对对象序列化的开销。

如果它是用户特定的数据,那么分布式散列表缓存系统可能会工作。诸如Memcached之类的东西对此很有帮助,因为它们是内存中的高速缓存(性能),但分布在多个服务器上(负载平衡),因此您可以获得两全其美的好处。

当然,如果数据定期发生变化,特别是如果其他系统可能在没有Web应用程序知道的情况下修改数据库,那么返回数据库可能是唯一的选择。

+0

如果您使用的是memcache会话存储,并且您知道正在修改的用户数据,那么如果会话密钥以某种方式绑定到用户(f.ex map sessionId - > userId),则始终可以使会话数据无效。这样即使频繁更改也可以使用会话存储。 – Runeborg 2009-08-05 13:33:01

+0

是的,但重点是如果频繁更改,避免(反)序列化开销并转到数据库可能会更好。这需要进行性能测量,以了解哪种方法在负载下性能更好。 – 2009-08-05 22:14:25

0

我在会话中保留用户标识,并将许多应用程序的活动用户记录保存在缓存中,但是我又倾向于将所有下拉列表的内容保留在缓存中,并且必须提供下拉列表的用户。

我已经有很多人惊呼“你在Cache中保留这个!!??”但实际上,它效果很好。好,我有一个确切的高速缓存中的用户列表中的副本不是每个应用实例一份(100个并发用户是指在内存中的用户列表中的潜在100份)。一般情况下,我会将任何在Cache中不经常更改的内容放在缓存中,如果缓存发生更改,则强制缓存,以便在下次访问时重新加载。

0

这取决于您的网站/应用程序。一般的规则是这样的:

会话保存作品好,如果并发用户的数量是相当低,该数据相对较小。

如果同时存在的用户数很多,并且数据的大小相对较低,则保存在cookie中会很有效。很明显,cookies是公开可见的,所以如果它是敏感的,比如电子邮件,那么它应该被加密。

如果数据的大小很大,保存在数据库中效果很好。

注意。正如其他人所说,如果你使用网络农场,那么我会忘记保存在会话中。

Martin Fowler对“企业应用架构模式”中的选项有很好的描述,但我不确定他是否有在线的东西。

如果网站/应用程序需要验证,那么.Net具有良好的内置功能来存储用户角色和唯一用户名。如果在认证过程中保存这些值,则可以通过User.IsInRole()和User.Identity.Name访问这些值。

在会话中存储会导致性能问题吗?如果您的数据量比较小,比如电子邮件,那么我会使用会话或cookie并避开数据库。 运行性能测试并查看哪些性能最适合您。