c#后端 文章

架构反思：引入 Redis 统计在线人数后，JWT 是否还有存在的意义？

在构建 .NET Web API 后台时，为了实现在线人数统计，我们通常会引入 Redis 来存储用户的活跃状态。 这时，一个非常敏锐且直击架构本质的问题往往会浮出水面： “既然为了统计在线人数，每次请求都要去 Redis 读写一次，那 JWT ‘无状态、不查库’ 的核心优势不就没了吗？干脆用一个短小的随机字符串（普通 Token），既能节省流量，又能节省计算资源，岂不更好？” 这是一个极好的问题。它触及了软件架构的核心——权衡 (Trade-off)。 答案是：在特定场景下，普通 Token 确实更好；但在大多数现代架构中，JWT + Redis 的组合依然具有不可替代的优势。 本文将从依赖性、性能、架构扩展性三个维度，深入剖析为什么我们依然推荐保留 JWT。 1. 核心区别：强依赖 vs. 弱依赖 这是两者最根本的区别，决定了系统的可用性 (Availability) 上限。 🔵 方案 A：普通 Token (Reference Token) + Redis 在这个方案中，Token 只是一个无意义的随机字符串（一把钥匙）。 流程： 请求到达 -> 解析 Token -> 必须请求 Redis 查找对应的 UserID -> 拿到身份 -> 执行业务。 风险： 这里 Redis 是强依赖。 如果 Redis 宕机、网络抖动或连接数耗尽，整个系统的认证模块瞬间瘫痪。