Azure横向扩展WebApp连接频繁切换服务器的会话相关技术咨询

一、如何让用户固定连接到同一服务器实例？ #

你可以开启Azure Web App的**会话亲和性（Affinity Cookie）**功能，它会在用户第一次请求时生成专属Cookie，后续用户的所有请求都会被路由到最初连接的那台实例上，这样就能避免刷新时IP随机切换的问题。

开启方式很简单：在Azure门户找到你的Web App，进入「配置」→「常规设置」，找到「会话亲和性」选项设置为「开启」即可。不过要注意，这个方案只是临时缓解——如果当前实例故障被自动替换，用户还是会被路由到新实例，而且它会削弱负载均衡的效果，更适合作为过渡方案而非长期完美解法。

二、横向扩展下使用Session对象是否可行？ #

默认的InProc模式Session（会话数据存在实例内存中）在横向扩展场景下完全不可行，因为每个实例的Session都是独立的，跨实例访问必然丢失数据。想要在横向扩展时正常使用Session，必须改用分布式会话存储，这里给你几个可选方案：

• Azure Redis Cache：虽然你担心成本，但Azure提供了免费的Basic C0层（适合小流量场景），而且Redis性能优异，支持存储较大的Session数据，还能设置过期时间自动清理闲置会话。如果流量增长，再按需升级付费层，成本其实可控。
• Azure SQL Database存储Session：ASP.NET原生支持把Session数据存储到SQL Server中，如果你已经在用Azure SQL作为业务数据库，可以直接复用，无需额外新增太多成本。只需运行ASP.NET提供的Session初始化脚本，再修改Web.config配置即可。
• 自定义分布式存储：比如用Azure Blob Storage或Table Storage实现Session存储提供者，这种方式适合有特殊存储需求的场景，但需要自己编写更多代码处理会话的序列化、读取和过期逻辑。
• 减少Session依赖：如果可以，尽量把非敏感的小数据存在客户端Cookie里（注意压缩数据，控制在浏览器4KB限制内）；对于大数据，只在Cookie里存唯一标识，实际数据存在服务器端的Blob或数据库中，通过标识关联读取。

总结 #

如果只是临时需要用户固定实例，开启会话亲和性可以快速解决；但长期来看，改用分布式会话存储才是横向扩展场景下的正确选择。Redis是最推荐的方案，成本和性能平衡得很好，而SQL存储适合已有SQL环境的团队。

备注：内容来源于stack exchange，提问作者StronglyTyped