一、为什么无状态应用需要分布式Session
1.1 传统Session的尴尬
你有没有遇到过这种情况：公司网站用了两台服务器，用户第一次登录在A服务器，过几分钟请求到B服务器，居然要重新登录？这就是传统Session的坑——早期的Session是存在单台服务器的内存或本地文件里，就像每个服务员自己记客人的消费，客人换桌了肯定拿不到账单。分布式部署的无状态应用，最忌讳“绑定”某一台服务器的资源，不然加服务器不仅不能提速，反而出bug。
1.2 分布式Session的核心逻辑
要解决这个问题，就得把Session存在所有服务器都能访问的“公共储物柜”里，这个储物柜就是分布式缓存（常用的有Redis、Memcached）。不管用户的请求落到哪台服务器，都能去公共储物柜里拿到自己的Session，真正实现“一处登录，处处可用”。
二、ASP.NET Core里实现分布式Session的准备
2.1 搭好基础环境
首先得准备两个东西：一个是ASP.NET Core 6的项目（最新的跨平台版本，用起来简单），还有一个是Redis服务。本地快速启动Redis最简单的方式是用Docker，一条命令搞定：
# 用Docker启动本地Redis，端口6379，适合本地测试
docker run -d -p 6379:6379 --name local-redis redis:alpine
如果不会Docker，也可以直接装Redis客户端，本地默认端口都是6379，不影响后续配置。
2.2 安装必要的包
打开你的ASP.NET Core项目，在NuGet包里搜并安装Microsoft.Extensions.Caching.StackExchangeRedis，这是官方推荐的Redis缓存包，专门用来和Redis交互。
三、完整示例：分布式Session的实现
本示例使用技术栈：ASP.NET Core 6 + Redis，代码都已注释，可直接复制运行。
3.1 Program.cs核心配置
ASP.NET Core 6用顶级语句，配置代码都放在这个文件里，重点注意中间件的顺序：
var builder = WebApplication.CreateBuilder(args);
// --------------------------配置Session服务--------------------------
builder.Services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30); // Session自动过期时间30分钟，适合多数场景
options.Cookie.HttpOnly = true; // 关键：防止JS脚本偷取Cookie，避免XSS攻击
options.Cookie.IsEssential = true; // 标记为必要Cookie，用户无需同意也能使用，合规
});
// --------------------------配置分布式缓存（Redis）--------------------------
builder.Services.AddStackExchangeRedisCache(options =>
{
options.Configuration = "localhost:6379"; // 连接本地Redis的地址，Docker启动的话就是这个
options.InstanceName = "MyApp_Session_"; // 给Session Key加前缀，避免和其他应用的缓存冲突
});
// 添加MVC服务（用控制器的话必须加，要是用 minimal API 可以调整）
builder.Services.AddControllersWithViews();
// --------------------------启动应用--------------------------
var app = builder.Build();
// 中间件顺序千万不能乱！UseSession必须在UseRouting之后，UseAuthorization之前
app.UseRouting();
app.UseAuthorization();
app.UseSession(); // 启用Session中间件，没有这行就不能读写Session
// 路由映射
app.MapControllers();
app.Run();
3.2 控制器里的会话操作
新建一个HomeController，用来测试存、读、清除Session：
using Microsoft.AspNetCore.Mvc;
namespace SessionDemo.Controllers
{
public class HomeController : Controller
{
// 首页：读取Session数据，显示用户状态
public IActionResult Index()
{
// 从Session里读用户ID，不存在就返回0（空值处理）
var userId = HttpContext.Session.GetInt32("UserId") ?? 0;
// 读用户名，不存在就显示“未登录用户”
var userName = HttpContext.Session.GetString("UserName") ?? "未登录用户";
// 把数据传给视图
ViewData["UserId"] = userId;
ViewData["UserName"] = userName;
return View();
}
// 登录接口：把用户信息存入Session
[HttpPost]
public IActionResult Login(string userId, string userName)
{
// 把用户ID和用户名存到Redis里的Session，过期时间是30分钟
HttpContext.Session.SetInt32("UserId", int.Parse(userId));
HttpContext.Session.SetString("UserName", userName);
// 登录后跳回首页
return RedirectToAction("Index");
}
// 登出接口：清除当前用户的Session
public IActionResult Logout()
{
// 清除当前Session，下次请求就相当于新用户
HttpContext.Session.Clear();
return RedirectToAction("Index");
}
}
}
最后在Views/Home/Index.cshtml里加几句简单的展示代码，就能看到效果了。
四、应用场景和技术优缺点
4.1 适合的场景
- 微服务架构：多个服务实例部署，每个实例共享Session；
- 容器化应用：K8s里的Pod自动扩缩容，换Pod不用重新登录；
- 无状态应用：不管是云原生还是本地部署，不绑定单台服务器；
- 需要记住用户状态的场景，比如购物车、用户登录态、浏览记录。
4.2 技术优缺点
- 优点：会话一致性（所有实例共享）、扩展性好（加实例不用改配置）、可靠性高（Redis持久化防止数据丢失）、自动清理过期Session，节省缓存空间；
- 缺点：依赖第三方缓存服务，增加运维成本；比本地Session多一点点网络延迟；敏感数据要加密存储，增加开发工作量；Session数据不能太大，避免占满缓存。
五、注意事项（踩过的坑总结）
5.1 中间件顺序不能乱
很多人把UseSession放在UseAuthorization后面，结果Session完全用不了，一定要记住顺序：UseRouting → UseAuthorization → UseSession，这是ASP.NET Core的硬性要求。
5.2 合理设置过期时间
别设太长（比如几小时甚至几天，会占满Redis空间）也别太短（比如5分钟，用户刚登录就过期），一般30分钟到1小时比较合适，根据业务调整。
5.3 敏感数据别裸存
比如用户密码、手机号等敏感信息，别直接存在Session里，就算存也要用ASP.NET Core的IDataProtector加密后再存，防止数据泄露。
5.4 Session别存大对象
Session里只放必要的ID和短字符串就行，别存整个用户对象或者大图，大的资源放Redis的其他Key里，Session只存引用，不然会拖慢性能。
六、总结
用分布式缓存（Redis）做ASP.NET Core的Session，是无状态应用的标准解决方案，不管是微服务、容器化还是云原生环境，都能轻松搞定会话共享。整个流程不算复杂，只要注意中间件顺序、配置合理，就能避开大部分坑。相比传统Session，扩展性和可靠性提升了不止一个档次，是每个进阶开发者都要掌握的技能。
Comments