当用户第一次到达某站点，他/她被给予一个HTTP cookie格式的SessionID （是一个只读属性， 为每个用户返回session 识别号）。然后服务器可以在session 集合中跟踪一整群的变量，通过 与用户的session cookie相匹配来保持每个用户有一个特定变量。只要用户在服务器上保持活跃， session 变量就维持它的状态。一个session 变量的默认有效时间是20分钟，或者是每当用户关闭 浏览器，这时无论session_OnEnd 部分是什么内容，global.asa 文件都运行。 以上陈述的关键是“在服务器上保持激活状态”。每个session变量都在网络服务器上设置，并保持在 本地内存中。所以，如果你在一个web 范围内使用负载平衡怎么办？（负载平衡的介绍请见 msdn 文章 ‘ASP and Web Session Management’）。对真正的负载平衡来说，每当居住于服务器 上的用户点击一个连接时，它就改变服务器的状态，每当浏览一个新页面时都潜在地丢失他们的 session 信息。 如果你发现自己是在这样的环境下编写代码--或者你怀疑你的站点最终是负载平衡的--你有4种方法 来解决这个问题。 ○ 完全不使用session 。 ○ 使用临时cookies 。 ○ 购买第三方组件来处理session 管理。 ○ 仅对web 范围内的第一次点击进行负载平衡。 本文将讨论这四种选择，并解释它们分别在何时何地最适用。 根本不使用sessions 显然，饶过sessions 管理这个问题的一个途径就是根本不使用sessions 变量。但是你仍然受困于 状态保持的问题。你可以使用最简单的方法跟踪用户，而不用写客户机。 一种不安全的方法是使用浏览器查询字符串，或用隐藏值进行表单置入，以使用户保持活跃状态。 这将允许你给他们一个用户id，并将变量存储在一个所有的web服务器都能到达的地方。比如说 我保持了变量 ShipToZipCode、 TypeOfCustomer和 CustomerEmail。可以这样写： < form action="/nextpage.ASP" method="post" > Item Number: < input type=text name="ItemNumber" >< br > Quantity: < input type=text name="Quantity" >< br > Unit Cost:< input type=text name="UnitCost" >< br > < input type=hidden value="ABXXXKJR8JSDFI12KJIL2H75CX45X2" name="sessionid" > < input type=submit value="post form" > < /form > 然后，在 nextpage.ASP上, 可以做以下工作: Set conn=Server.CreateObject(ADODB.Connection) Set SessionRS = conn.execute("Select ShipToZipCode, TypeOfCustomer, _ CustomerEmail from TblSession where SessionID =" & request.form("sessionid")) ShipToZipCode = SesssionRs("ShipToZipCode") TypeOfCustomer = SesssionRs("TypeOfCustomer") CustomerEmail = SesssionRs("CustomerEmail") 这样通过将所有的"session" 信息存储在数据库中，可以使这三个变量在每一页上都保持活跃。确保 用户id的值很难猜到，这很重要。当访问第一页时，将分配给用户的sessionID 存储为用户名。当用户 离开这一页时可以考虑清除这个数据，有效地重新生成ASP session 对象。这可以手工完成，或者用 一个限时程序将数周以上的记录删除。 使用临时Cookies 对于特别的非敏感数据，直接向客户机中写入信息是有意义的。比如说，如果我的站点只使用了一个 变量来跟踪用户的ZIP 码来得到用户在当地的交通记录，那么以HTTP cookie的形式将用户的ZIP码 写入他们的机器应该不会产生什么危害。因为你可以将cookie写成浏览器关闭时失效，就可以使它们 模仿一个session 变量的功能，也可以使他们是持久的，好在用户下一次访问时记住他。 用Request 对象Cookie 的值可以为服务器所用。请求Cookie 的值，然后将值带进来。所以在我们上面 的例子中，可以这样做： ShipToZipCode = Request.Cookies("SessionCookie")("ShipToZipCode") TypeOfCustomer = Request.Cookies("SessionCookie")("TypeOfCustomer") CustomerEmail = Request.Cookies("SessionCookie")("CustomerEmail") 你不得不把这些放置在每个页面的顶部，但是如果用户把三个cookies 都设置了，那么每一页都可以 存取和使用这些用户特定的变量。你还可以在一个cookie中设置三个变量，请看Ken Baumbach的文章 Cookie Basics with ASP，里面有设置变量的更多信息。 如果你认为用户可能在浏览器上使Cookie 无效，这种方法就不适用。但是越来越多的站点要求使用 cookies，web 用户也越来越熟练了。有可能相对很少的用户会使cookies无效，但是这要在执行 这一方法之前进行考虑。 虽然上面的方法肯定能奏效，但是它们削弱了ASP的功能，因为它限制了其中一个关键组件--Session 对象的使用。要避免由负载平衡导致的这种限制，继续使用sessions的一种方法是购买一个第三方 组件，可以比IIS更好地处理Session。 在本文中，我不想比较各种第三方组件的优缺点。但是我听说有一个组件工作得挺好，是SoftArtisans 提供的,叫做 SA-Session Pro。它使用NT文件系统存储用户的信息，整个网络范围内的服务器都可以 使用。其它第三方组件创建“session 引擎”把网络服务器和session 管理器分离。这样，每次用户 都可以被重定向到相同的session 引擎，同时也对服务器本身的点击进行负载平衡。 另一个可选择的第三方组件是Microsoft的成员服务器。它与Microsoft的站点服务器，它允许一个 站点处理状态维护以外的问题。在Bill Pitzer的文章‘Moving your "Anonymous" visitors to registered status using Site Server and Membership Directory Authentication’中有更多的 信息。 由于ASP已经越来越成为企业级网络应用程序的选择，而负载平衡也成为这些应用程序成功的最大威胁， 在市场上会出现越来越多的第三方组件。ASP本身就是服务器对象或ActiveX组件，就是可以处理这些 插件的。 仅当web 范围内的第一次点击进行负载平衡 这种方法也称为前端负载平衡，它易于描述，但是有可能不适于执行。为了实现真正的负载平衡，每次 请求都要重新平衡用户。但是在大多数情况下，前端负载平衡就已经足够满足大部分这类服务器维护的 支持者了。 要实现这个目的，就只允许在范围内的第一次点击通过负载平衡器。每个增加的页面负载都将用户保持 在同一个服务器上。这就如同在代码中使用相对路径而不是绝对路径一样简单。 < Form action="http://www.myserver.com/mypage.ASP" method=post > 变成 < Form action="/mypage.ASP" method=post > 在action 标记中使用相对路径，用户在访问你的站点的整个过程中，都停留在同一个网络服务器上。 这样他们的session集合在同样时间内与他们在一起。毫无疑问，这样会使你的负载平衡计划受到 一定的损失，因为你只有一次机会决定在哪儿处理用户的负载，并且在知道他们将产生多少通信量 之前就要作出决定。但是在大多数情况下，因为允许使用sessions，这种方法已经接近于实现完全的 性能了。 但是，这不是唯一的问题：在某些情况下，这不是一个合适的方法。例如，你的应用程序要求用户离开 当前的服务器，到一个专门用途的服务器上，如email、搜索或安全服务器的话，这种方法就不行了。 另外，如果用户把一个页面设置为书签，或者试图把这个URL 发送给朋友，他们可能要得到特定机器 的地址，进一步削弱你的负载平衡计划。最后，如果机器坏了，所有的用户信息都不可恢复地丢失了， 它没有失败恢复功能。 哪种方法最好？ 这个问题的答案可想而知：“看情况”。其它需要考虑的因素包括： ○ 你的站点点击率有多高； ○ 你希望保存多少状态信息； ○ 如果你有专门用途的服务器； ○ 如果你想用第三方组件处理你的站点的宝贵部分。 如果你的站点通信量太大，那么精确的负载平衡对于站点的成功来说就非常重要，那么不用sessions 编程，或使用Session Pro或 Microsoft的站点服务器等第三方组件，是可行的。如果通信量小，或者 只需要保存较少的状态信息，那么使用cookies 或仅仅前端负载平衡就比较可行。 总的来说，在建立站点之前你要充分考虑这些问题。决定采用什么方法要把需要与站点的每个页面相结合， 任何延迟都会导致主要部分的重做，也许会导致整个站点的完全重新构造。确定站点当前和将来会有什么 需要，然后决定如何处理sessions的问题。