Session 嘛，占一点儿服务器资源，但是总归比 ViewState 和 Cookie 安全点儿，所以还是要用的。

Windows Azure 环境中的 Web 服务器经由负载均衡调度，根本无法保证下一次处理请求的还是不是上一次的那台服务器，所以，直接使用内存的 In-PRocess Session 就不能用了。

那么怎么办呢？

备选方案

ASP.NET State Service

专门用一台服务器来管理 Session。这个方案 On-Premis 方案里面可以用，Azure 的环境中还没有任何可用的迹象，跳过。

Table Storage

直接用 Azure 里面的存储服务来给你保存 Session。存储服务好便宜，最高级的“读取访问地域冗余存储 (RA-GRS)”对表和队列的报价是 $0.12 1T/月。但是，问题就是慢。所以，跳过。

Azure Caching

内存的缓存服务，速度最快、也最贵。最大的问题是，中国的 Azure 目前还不支持（但云服务提供 In Role Caching）。无奈跳过。

SQL Azure

速度介于 Table Storage 和 Azure Caching 之间，木有官方支持，但是可用。无奈咬牙就用这个了。

操作步骤

其实挺简单的，分三个步骤：

1. 建立一个 SQL Azure 数据库
2. 在这个新的空数据库上面跑一个脚本，把所需的表和存储过程都建立起来
3. 配置 ASP.NET Web 应用的 Web.Config 文件

首先，登录 Windows Azure 控制台，创建一个空的数据库。这里给它起名 ASPState。如果你检索过英文资料，那么你发现有人（文章）会让你运行一段 SQL 脚本创建这个数据库。从应用的角度看，效果是一样的，但是，这个脚本创建的数据库，是不会出现在 Azure 控制台的数据库列表里面的。所以，还是应该直接在 Azure 控制台里面建立这个数据库。

然后，下载本文末尾提供的文件链接，解压后得到 SQL 文件，用 SQL Server Management Studio 打开 Azure 数据库 ASPState 后，运行此脚本即可完成第二步。这个脚本不是我写的，是从 这个地址 下载的。但是原始的下载包是包含创建数据库脚本的，基于上面的原因，我给去掉了，以免引起混乱；同时，也起到异地备份的作用。

打开 ASPState 数据库以及配置 Web.Config 需要连接字符串的参数，可以在 Azure 的数据库面板上面找到，点击“查看 ADO .NET …. 连接字符串”就是：

用 SQL Server Management Studio 连接 Azure 数据库的过程中，你可能会收到一个“ip 地址被防火墙拦截”的错误消息。没关系，切换到 Azure 控制台的数据库管理界面，打开上面的连接字符串对话框，你会看到 Azure 会提示你是否需要允许这个 IP 地址访问数据库，只需要点击提示，将 IP 地址加入允许的访问列表中保存即可。

最后，在你的 Web.Config 的 System.Web 节中添加下面的内容即可（用 % 引用的内容需要按照你的实际情况替换）：

好了，下面就可以开始用 Session 了。

附件：下载 配置 ASPState 数据库的脚本文件 （zip 格式）。

特别说明：SQLServer 的 Session 需要手动调用 DeleteExpiredSessions 存储过程（如果你运行上面的 SQL 脚本，这个存储过程是会给你创建好的），因为 SQL Azure 不提供 Agent 服务，所以要手动调用或者用 Azure 提供的“计划调用”服务等手段。这个调用的时机见仁见智，要结合自己应用的实际来安排，这篇短文中就不展开讲太多了。

■