后端认证鉴权高并发，从Session到JWT再到Redis，如何选？

更新于

2026-09-12 03:15:13

13阅读来源：SEO资讯

内容介绍
文章标签
相关问答

在技术面试中，认证、鉴权与并发这三个话题的出现频率远高于任何八股文。面试官往往会直接问：“你们的认证程序怎么设计？老实说，”如果你只会说“JWT、Session、Redis”。却连一条完整的链路说不出来答案就显得空洞。

从痛点一来看。HTTP 本身是无状态的

HTTP 每一次请求都是独立的，服务器不会“记住”上一次是谁发的。这本是协议优点，但当你需要登录时却变成了大麻烦。你不想让使用者每一次请求都输入密码吧？

说到痛点二，多使用者、多角色、多并发需求

任何一个成熟后端程序都有：

注册/登录功能
不同角色权限区分
随业务而升高的并发压力

再看示例，最简单的 Session+Redis 场景

┌─────────┐ ┌──────────┐
│ 浏览器 │ │ 服务器 │
└────┬────┘ └────┬─────┘
│ POST /login {user,password} │
│───────────────────────────────────►│
│ │ 验证密码
│ │ 存入 Redis：session_abc123 = {uid:。role:"admin"}
▼ ▼ Set-Cookie: session_id=abc123
POST /api/user/info GET /api/user/info
再看Cookie，session_id=abc123 Cookie: session_id=abc123
◄─────────────────────────────────── ◄───────────────────────────────────
│ 拿到 abc123 │ 去 Redis 查出使用者信息 {name:"张三",role:"admin"}
│ 返回数据

主要流程：

签发: 服务端生成唯一 session ID 并存储关联数据。
验证: 客户端携带 cookie，服务端通过 session ID 在 Redis 查询对应数据。老实说，

Session 的优缺点

优点：

缺点：

生产环境常用方案：Redis+Session 分布式共享缓存

内存仅适合开发调试；数据库做 Session 存储就太慢。多数公司采用 Redis 或 Memcached。将所有实例统一读写同一个键空间，以实现水平扩容。

JWT——无状态但不是完美解法

Acronym Meaning:

JWT Structure
`{ "alg":"HS256"。"typ":"JWT" }`	`{ "sub":"10086","role":"admin","exp":1718123400 }`	`Lk7wZx9...`	Header + Payload 加密后得到 Signature；客户端携带整个字符串进行验证。只要 Secret Key 不泄露，就能保证完整性与真实性。-->

Coding 验证流程：

// 解码 Header & Payload
const = token.split;// 用 Secret Key 重新计算签名
const expectedSignature = HMAC_SHA256;其实，// 校验签名是否一致且未过期
if

JWT 的主要魅力——无状态验证

* 服务端不需要持久化任何会话信息。只需一次哈希运算就可以完成身份校验。* 前后端可以完全解耦：前端可直接使用 Bearer Token 与任何微服务交互。* 高并发下无需访问数据库或缓存，大幅降低延迟。

但 JWT 有致命缺陷：

不可撤销性：一旦签发。即使使用者被禁用也无法即时失效，除非使用黑名单或短期有效期再配合刷新机制。
敏感信息泄露风险： Payload 是 Base64URL 编码，不是加密；任何人都能解码阅读其中内容。不要在其中放置密码、密钥等敏感字段。
HTTPS 必须： Token 必须在安全通道传输，否则中间人可以截获 Token 并冒充合法使用者。

综合比较这方面，什么时候选 Session？什么时候选 JWT，何时混合使用？

说到**痛点**，• **高并发** 下每个请求都访问缓存/DB 极大影响吞吐量。• **权限即时变更** 时需要快速失效旧凭证。• **前后端解耦** 与微服务架构兼容。

🚀 如何在面试中自信回答？

先描述需求痛点 “需要支持数百万级别的并发登录，同时保证管理员能即时吊销账号。”
挑选最合适方案 “我通常会选择 JWT+Refresh‑Token 搭配双 Token+Redis 黑名单来满足既有高性能又具可撤销性的需求。按理说，”
阐述关键技术细节 • JWT 验证过程与其无状态优势 • Refresh‑Token 生命周期管理 • 双 Token 与 Redis 黑名单实现即时撤销
补充落地经验 “在我们的生产环境里我们把 Access‑Token 设置为 15 min。有效减少暴力风险，将 Refresh‑Token 放进 HttpOnly Cookie 并绑定 IP/UA 防止 CSRF。”

🎯 小结

场景需求	推荐方法	说明
User 数量有限且业务单体或者初创项目快速迭代需要立即撤销权限	* Session + Redis * 或者纯 Cookie 会话	Server 保存真实身份。可随时清除对应 key，无需额外 revocation logic。怎么说呢，
User 数量大业务需水平扩容且对性能极致要求允许一定时间内凭 Token 自动认证	* JWT+ Refresh Token * 或者双 Token + Redis 黑名单策略	Stateless 可放弃每次请求访问缓存/DB 的开销；Refresh Token 可在短期失效后自动获取新 Token，保持安全性。若必须强制失效，则把旧 token 写入 Redis 黑名单。并设 TTL 与原来相同。
Nginx API Gateway 与微服务协作需要统一鉴权层	* JWT。微服务只关心业务	Gateway 对 token 做一次全局校验后转发给内部服务，内部服务无需去 DB 验证，从而减轻负载并保持一致性。
注意事项 & 常见坑洞	方法	备注
"Token 被篡改但未过期"	"使用 HS256/HMAC 密钥强度足够，并检查 exp 时间"	"即使 exp 后仍有机会被恶意使用。请务必设置合理生命周期"
"刷新 Token 泄漏"	"Refresh Token 单独存储至 HttpOnly Cookie 且加 IP/设备绑定"	"防止跨站请求伪造" />

场景	推荐方法	主要理由
单体小规模	Session + Redis	简单易实现。可随时失效
大规模分布式	JWT + Refresh Token	高并发无状态 + 即时撤销
微服务网关	Gateway 执行 JWT 校验，再转交业务层	减轻内部负载

只要记住「痛点 → 需求 → 技术匹配」，面试官就能听见你真正懂得背后的原理，而不是机械背诵概念。

祝你下次面试顺利拿到那份理想工作！

标签：再到

从痛点一来看。HTTP 本身是无状态的

说到痛点二，多使用者、多角色、多并发需求

任何一个成熟后端程序都有：

注册/登录功能
不同角色权限区分
随业务而升高的并发压力

再看示例，最简单的 Session+Redis 场景

┌─────────┐ ┌──────────┐
│ 浏览器 │ │ 服务器 │
└────┬────┘ └────┬─────┘
│ POST /login {user,password} │
│───────────────────────────────────►│
│ │ 验证密码
│ │ 存入 Redis：session_abc123 = {uid:。role:"admin"}
▼ ▼ Set-Cookie: session_id=abc123
POST /api/user/info GET /api/user/info
再看Cookie，session_id=abc123 Cookie: session_id=abc123
◄─────────────────────────────────── ◄───────────────────────────────────
│ 拿到 abc123 │ 去 Redis 查出使用者信息 {name:"张三",role:"admin"}
│ 返回数据

主要流程：

签发: 服务端生成唯一 session ID 并存储关联数据。
验证: 客户端携带 cookie，服务端通过 session ID 在 Redis 查询对应数据。老实说，

Session 的优缺点

优点：

缺点：

生产环境常用方案：Redis+Session 分布式共享缓存

内存仅适合开发调试；数据库做 Session 存储就太慢。多数公司采用 Redis 或 Memcached。将所有实例统一读写同一个键空间，以实现水平扩容。

JWT——无状态但不是完美解法

Acronym Meaning:

JWT Structure
`{ "alg":"HS256"。"typ":"JWT" }`	`{ "sub":"10086","role":"admin","exp":1718123400 }`	`Lk7wZx9...`	Header + Payload 加密后得到 Signature；客户端携带整个字符串进行验证。只要 Secret Key 不泄露，就能保证完整性与真实性。-->

Coding 验证流程：

// 解码 Header & Payload
const = token.split;// 用 Secret Key 重新计算签名
const expectedSignature = HMAC_SHA256;其实，// 校验签名是否一致且未过期
if

JWT 的主要魅力——无状态验证

但 JWT 有致命缺陷：

不可撤销性：一旦签发。即使使用者被禁用也无法即时失效，除非使用黑名单或短期有效期再配合刷新机制。
敏感信息泄露风险： Payload 是 Base64URL 编码，不是加密；任何人都能解码阅读其中内容。不要在其中放置密码、密钥等敏感字段。
HTTPS 必须： Token 必须在安全通道传输，否则中间人可以截获 Token 并冒充合法使用者。

综合比较这方面，什么时候选 Session？什么时候选 JWT，何时混合使用？

🚀 如何在面试中自信回答？

先描述需求痛点 “需要支持数百万级别的并发登录，同时保证管理员能即时吊销账号。”
挑选最合适方案 “我通常会选择 JWT+Refresh‑Token 搭配双 Token+Redis 黑名单来满足既有高性能又具可撤销性的需求。按理说，”
阐述关键技术细节 • JWT 验证过程与其无状态优势 • Refresh‑Token 生命周期管理 • 双 Token 与 Redis 黑名单实现即时撤销
补充落地经验 “在我们的生产环境里我们把 Access‑Token 设置为 15 min。有效减少暴力风险，将 Refresh‑Token 放进 HttpOnly Cookie 并绑定 IP/UA 防止 CSRF。”

🎯 小结

场景需求	推荐方法	说明
User 数量有限且业务单体或者初创项目快速迭代需要立即撤销权限	* Session + Redis * 或者纯 Cookie 会话	Server 保存真实身份。可随时清除对应 key，无需额外 revocation logic。怎么说呢，
User 数量大业务需水平扩容且对性能极致要求允许一定时间内凭 Token 自动认证	* JWT+ Refresh Token * 或者双 Token + Redis 黑名单策略	Stateless 可放弃每次请求访问缓存/DB 的开销；Refresh Token 可在短期失效后自动获取新 Token，保持安全性。若必须强制失效，则把旧 token 写入 Redis 黑名单。并设 TTL 与原来相同。
Nginx API Gateway 与微服务协作需要统一鉴权层	* JWT。微服务只关心业务	Gateway 对 token 做一次全局校验后转发给内部服务，内部服务无需去 DB 验证，从而减轻负载并保持一致性。
注意事项 & 常见坑洞	方法	备注
"Token 被篡改但未过期"	"使用 HS256/HMAC 密钥强度足够，并检查 exp 时间"	"即使 exp 后仍有机会被恶意使用。请务必设置合理生命周期"
"刷新 Token 泄漏"	"Refresh Token 单独存储至 HttpOnly Cookie 且加 IP/设备绑定"	"防止跨站请求伪造" />

场景	推荐方法	主要理由
单体小规模	Session + Redis	简单易实现。可随时失效
大规模分布式	JWT + Refresh Token	高并发无状态 + 即时撤销
微服务网关	Gateway 执行 JWT 校验，再转交业务层	减轻内部负载

只要记住「痛点 → 需求 → 技术匹配」，面试官就能听见你真正懂得背后的原理，而不是机械背诵概念。

祝你下次面试顺利拿到那份理想工作！

标签：再到

从痛点一来看。HTTP 本身是无状态的

说到痛点二，多使用者、多角色、多并发需求

再看示例，最简单的 Session+Redis 场景

Session 的优缺点

生产环境常用方案：Redis+Session 分布式共享缓存

JWT——无状态但不是完美解法

JWT 的主要魅力——无状态验证

但 JWT 有致命缺陷：

综合比较这方面，什么时候选 Session？什么时候选 JWT，何时混合使用？

🚀 如何在面试中自信回答？

🎯 小结

相关问答

从痛点一来看。HTTP 本身是无状态的

说到痛点二，多使用者、多角色、多并发需求

再看示例，最简单的 Session+Redis 场景

Session 的优缺点

生产环境常用方案：Redis+Session 分布式共享缓存

JWT——无状态但不是完美解法

JWT 的主要魅力——无状态验证

但 JWT 有致命缺陷：

综合比较这方面，什么时候选 Session？什么时候选 JWT，何时混合使用？

🚀 如何在面试中自信回答？

🎯 小结

相关问答