如果之前有人问我，我很抱歉，但我还没有找到我头脑中的具体问题。
对于我正在构建的网站（使用ASP.NET MVC） - 性能是一项重要功能。此外，该站点有可能托管在应用程序池每20分钟回收一次的环境中（或者如果达到内存阈值则更快）。我希望完全独立于依赖会话变量，而是在cookie中存储类似GUID的值。我的理由是 - 由于AppPool的回收，我不知道会话将持续多长时间，并且不希望他们的会话过早超时并导致他们不得不重复登录。
cookie中的GUID值将充当表的查找键，其中我存储类似会话的信息（用户ID值等）。所以如果我需要那些数据，我可以从数据库中检索它。我仍然会利用Session_OnEnd事件清除那个“最后活动”值超过20分钟（或者长会话配置为持续时间）的行的会话表。所以我想我仍然会使用会话状态，而不是会话变量。
然而，我的担忧是关于表现。因此，我很好奇是否有更好的方法可以避免使用会话变量，同时仍然能够知道用户是谁，并以“类似会话”的方式管理他们对网站的访问。我仍然是MVC的新手，但多年来在ASP.NET中有很多经验，所以我希望我的问题有道理！
编辑：我有点害怕想要使用SQL Session State，因为我可能会在共享的sql server托管环境中，并且我认为我没有能够创建/运行作业的登录删除过期的sql会话数据等是必要的。在AppPool回收方案中，依赖于Session_OnEnd和cookie有任何真正的缺点吗？对于AppPool回收时当前的会话，Session_OnEnd是否可以执行？答案 0 :(得分：5)
您假设会话只存储在工作流程中，您可以拥有SQL状态会话，check this link before going any further
答案 1 :(得分：1)
使用数据库在Web场/花园中提供“持久”持久性是一种常见技术。还有distributed caching systems可用于在服务器和重新启动之间提供会话状态数据。
例如，我见过的一个分布式系统使用UDP在多个服务器之间共享会话数据。我希望分布式缓存有一些性能优势，因为数据存储在服务器的内存中，因此没有数据库查找。
答案 2 :(得分：1)
如果您不能使用进程内状态，则必须恢复到外部存储库，这可能是数据库。
那么为什么不将会话状态存储在DB中呢？有内置的支持，它可以有效地解决回收问题，同时在会话状态保持较小的情况下保持可接受的性能。
答案 3 :(得分：0)
查看自定义缓存机制。就像你说你不能使用会话变量，因为它听起来像你的网站将负载平衡？由于应用程序池的回收，会话可能会发生变化。您也不希望View State处于领先地位（您可以使用它，但它会影响性能）。
缓存和其他提到的模型之间有三个主要区别：