【发布时间】：2013-05-22 19:23:35
【问题描述】：
您是否应该存储每个请求所需的用户信息 例如。角色、电子邮件、用户名等
在 Session 中，或者每次请求该信息都可以转到数据库吗？？
谢谢
【问题讨论】：
标签： c# asp.net-mvc database session
【发布时间】：2013-05-22 19:23:35
【问题描述】：
如果您不打算进行负载平衡，那么会话状态是完全可以接受的。如果会话状态配置为使用数据库持久性，请小心，因为那样您不仅会访问数据库，还会产生对象序列化的开销。
如果它是用户特定的数据，那么分布式哈希表缓存系统可能会起作用。像 Memcached 这样的东西对此很有好处，因为它们是内存缓存（性能），但分布在多个服务器上（负载平衡），因此您可以两全其美。
当然，如果是定期更改的数据，特别是如果您的其他系统可能会在 Web 应用程序不知道的情况下修改数据库，那么返回数据库可能是唯一的选择。
【讨论】：
-
如果您使用的是 memcache 会话存储并且您知道您正在修改哪些用户数据，如果会话密钥以某种方式绑定到用户（例如映射会话 ID -> 用户 ID）。这样即使更改频繁，您也可以使用会话存储。
-
是的，但关键是如果有频繁的更改，最好避免（反）序列化开销并直接访问数据库。这将需要性能测量来查看哪种方法在负载下表现更好。
我更喜欢为此使用加密的 cookie。在大型、繁忙的系统中，db 调用可能会变得昂贵。会话很好，但是如果您的会话后端是数据库驱动的，那也会变得昂贵。显然，在使用 cookie 时，您必须结合身份验证令牌检查。
【讨论】：
-
验证令牌检查？你的意思是表单验证的东西？
这取决于您所说的“应该”是什么意思。我开发了一些使用会话缓存用户信息的应用程序。该方法效果很好，并且减少了每个 Web 请求所需的数据库往返次数。
另一方面，它确实为您的网络服务器引入了状态，因此您要么必须坚持使用一个网络服务器，要么使用“病态会话”（这会使管理网络服务器变得更加复杂），或者开始将会话信息存储在一个共享的数据存储（这会消除您最初使用它可能获得的任何性能提升）。
【讨论】：
我将用户 ID 保存在 Session 中，并将活动用户记录保存在我的许多应用程序的缓存中，但是我又倾向于将所有下拉列表的内容保存在缓存中，并且我必须提供一个下拉列表时不时的用户。
很多人惊呼“天哪，你把它保存在缓存中！？！？”但实际上，它工作得很好。更好的是，我在缓存中只有一份用户列表副本，而不是每个应用程序实例一份副本（100 个并发用户意味着内存中可能有 100 个用户列表副本）。一般来说，我将不经常更改的任何内容放入缓存中，如果确实发生更改，则将其强制退出缓存，以便下次访问时重新加载。
【讨论】：
这取决于您的网站/应用程序。一般规则是这样的：
在会话中保存如果同时用户的数量相当少并且数据相对较小，则效果很好。
保存在 cookie 中适用于同时用户数量较多且数据量相对较小的情况。显然 cookie 是公开可见的，所以如果它是敏感的，例如电子邮件，那么它应该被加密。
保存在数据库中如果数据量很大，效果很好。
注意。正如其他人所说，如果您使用网络农场，那么我会忘记保存会话。
Martin Fowler 对“企业应用程序架构模式”中的选项有很好的描述，但我不确定他是否有在线资料。
如果站点/应用程序需要身份验证，那么 .Net 具有良好的内置功能，用于存储用户角色和唯一用户名。如果您在身份验证期间保存此值，则可以通过 User.IsInRole() 和 User.Identity.Name 访问这些值。
在会话中存储是否会导致性能问题？如果您的数据大小相对较小，例如电子邮件，那么我会使用会话或 cookie 并避免使用数据库。 运行性能测试，看看什么最适合你。
【讨论】：
会话数据也可以存储在数据库中，如果您的站点在 Web Garden og Farm 中运行，这将非常有用。如果会话在 InProc 中运行，则用户数据将保存在内存中，这会更快，但会以可伸缩性为代价。
另一种常见的方法是将其保存为 ViewState，然后在每次回发时在客户端和服务器之间将其发回第四次，这当然会导致带宽损失，但比 InProc 会话的扩展性要好得多。
我个人更喜欢会话状态，如果站点很小，我会在 InProc 中运行它，如果/当站点增长时，我可以将其更改为使用数据库。
【讨论】：