高并发下身份认证子系统需限流、熔断、降级三层联动：登录接口全局QPS限流，Token刷新按用户限流，扫码/短信接口IP+手机号双维度滑动窗口限流；数据库、短信、OAuth等依赖须独立熔断；Redis不可用时直连DB，JWT验签失败启用白名单，高负载时关闭图形验证码并异步化用户信息组装。
系统身份验证子系统是高并发场景下的关键薄弱点，它常因频繁校验、数据库查询、第三方调用（如微信/支付宝OAuth）而成为雪崩起点。防范不是靠“扛”，而是通过限流前置、熔断隔离、降级兜底三层联动，让认证服务在流量洪峰中保持可用，同时不拖垮下游。
身份认证层必须做分级限流
认证请求不能一视同仁。要按风险与资源消耗分三级控制：
-
用户登录接口：最敏感、最耗资源（查库+密码校验+生成token），必须全局QPS限流。例如用Sentinel配置每秒500次，超限直接返回
429 Too Many Requests，不进业务逻辑 - Token刷新接口：轻量但高频，适合按用户ID或设备指纹做单点限流（如每个用户每10分钟最多2次），防恶意轮询
- 免密扫码/短信验证码接口：极易被刷，必须叠加IP+手机号双维度限流，并启用滑动窗口算法（非固定窗口），避免0.9秒到1.1秒之间被绕过
对下游依赖强制熔断保护
身份认证往往依赖多个外部环节：用户中心DB、Redis缓存、短信平台、OAuth网关。任一环节抖动都会卡住整个认证链路。必须为每个依赖单独配置熔断器：
- 数据库查询：错误率＞20% 或 平均RT＞800ms，持续30秒后熔断，半开探测间隔设为60秒，每次只放行3个请求
- 短信发送：调用失败即触发熔断（因属强依赖且不可重试），Open状态时自动切换至“邮箱验证码”降级通道
- 微信OAuth回调：使用gobreaker或Resilience4j，设置
failureThreshold=5，timeout=2s，避免等待微信响应阻塞线程池
认证失败与超时必须有明确降级策略
降级不是“返回错误”，而是保障主流程不中断：
- 当Redis缓存不可用时，跳过token有效性本地校验，转为直连用户中心DB（牺牲性能保可用）
- 当JWT签名验签失败率突增，启动“白名单模式”：仅允许已知可信App ID的请求继续通行，其余全部拦截并告警
- 在系统负载＞0.9时，关闭图形验证码（仅保留短信/邮件），减少CPU和IO压力；同时将登录成功后的用户信息组装逻辑异步化，前端先返回token再拉取详情
关键配置要点与避坑提醒
实战中容易忽略但致命的细节：
- 限流拒绝必须快速失败，严禁加锁、日志刷盘或远程调用，否则限流本身变成瓶颈
- 熔断状态不能存在单机内存，必须用Redis共享（如Resilience4j的
CacheBackend），否则集群节点状态不一致，故障会漏判 - 所有限流/熔断指标（如拒绝数、熔断次数、降级开关状态）必须接入Prometheus+Grafana，配置
5分钟内认证失败率＞15%自动告警 - 不要在Filter或Interceptor里写复杂逻辑做限流——Spring MVC的DispatcherServlet前就该由网关（如Spring Cloud Gateway + Sentinel）完成，避免认证服务自己先被压垮
