负载均衡器后面的 Session_End 事件答案

【问题标题】：Session_End event behind load balancer负载均衡器后面的 Session_End 事件
【发布时间】：2011-01-10 11:03:57
【问题描述】：

我正在负载均衡器后面创建 Web 应用程序。到目前为止，我将其配置为将会话存储在数据库中，但我不确定应该如何处理会话过期。问题不是会话没有从数据库中删除，而是 Session_End 事件，因为我必须在其中调用一些 Web 服务方法。

假设 Session_End 在过期时被调用，我担心的是会话在一台服务器上创建但在另一台服务器上完成的情况。在这种情况下，我担心第一台服务器上的 Session_End 会过早执行，我会过早调用 Web 服务。在这种情况下，您有什么建议？

编辑：

我记得前段时间阅读了有关 Sql Agent 对会话结束事件做出反应然后执行自定义代码的内容。任何人都可以确认这个解决方案是可能的吗？

【问题讨论】：

标签： .net asp.net load-balancing

【解决方案1】：

除非您使用进程内会话状态，否则不支持会话结束事件。你可以看看ScaleOut SoftwareStateServer。我正在为我自己的环境考虑这个。它实现了分布式会话状态并支持会话结束事件。

编辑以添加更多信息：

他们的网站解释得更好（details page），但这里有一个简短的总结。 ScaleOut（或类似的小工具）使用分布式缓存来管理会话状态。这意味着每个服务器上的进程都保存会话数据。进程在服务器之间进行通信，以便所有数据在所有服务器之间共享 - 无论哪个服务器恰好正在处理用户请求，都可以使用相同的会话数据。如果其中一台服务器出现故障，所有会话数据都会保留，因为它分布在所有服务器上。相比之下，asp.net 提供只在单个服务器上工作的进程内会话状态、将会话数据保存在单独的单个服务器中的会话状态服务器（单点故障）或 sql server 会话状态，这健壮，但会损害性能。

【讨论】：

当项目接近尾声时，我怀疑我能否将其推给管理层。目前我只有一个选择，那就是使用 Sql Server。
如果问题是部署延迟，我相信这个产品很容易安装和配置，并且需要对您的代码进行少量更改（但是，由于我自己还没有安装它，我可以远离）。如果问题是成本，那么……
任何对此答案感兴趣的人都可以解释 ScaleOut 的好处吗？

【解决方案2】：

这不正是您将会话信息存储在数据库中的原因吗？

这样就解决了“会话在哪台服务器上”的问题。

如下所述，Session_End 仅在 inProc 会话中调用，您不会使用它。

【讨论】：

是的，但我担心的是......例如（超时 = 10min）：用户在服务器 A 上打开页面，然后在 9 分钟后负载均衡器切换到服务器 B。从阅读文档和博客我知道 Session_End 将在服务器 A 上的会话创建 10 分钟后和服务器 B 上的 19 分钟后调用，因为超时计时器不知道其他服务器并且该会话已延长。如果我错了，请纠正我。