权限缓存失效核心是主动通知旧数据作废而非等待过期；典型做法为权限变更后立即触发广播（如Redis Pub/Sub），各节点监听并删除对应本地缓存项，辅以版本号key、双删兜底和分布式锁防击穿，确保秒级一致且精准可控。
权限缓存失效，核心是“让旧的权限判断结果及时作废”，而不是等它自然过期。Invalidation（失效法）正是为此设计：数据一变，立刻通知所有相关缓存条目“你已过期，请丢弃”，不等 TTL 到时，也不依赖后台扫描。
为什么权限场景特别适合用 Invalidation
权限数据变更频次低但影响大——比如用户被移出管理员组、角色权限被批量调整、某接口访问策略突然收紧。这类操作不是高频写入，但一旦发生，必须确保所有服务节点在几秒内看到最新状态，否则会出现越权访问或误拒请求。
相比固定 TTL，Invalidation 能做到：
• 精准控制：只删与该用户、角色或资源相关的缓存项，不波及其他
• 实时性强：配合消息队列或 Pub/Sub，可实现亚秒级全集群同步
• 资源友好：避免为防过期而设置极短 TTL 导致缓存命中率骤降
典型实现方式
常见组合是“主动触发 + 广播通知 + 本地清理”：
- 后端在权限更新成功后，调用 cache.evict("perm:user:1001") 或发送失效消息到 Redis Channel（如 channel:perm:invalidate）
- 各业务服务订阅该 channel，收到 {"key": "perm:user:1001"} 后立即执行本地缓存删除
- 若使用 Spring Cache，推荐 @CacheEvict(key = "#userId", condition = "#result != null")，配合数据库事务确保原子性
- 对跨服务权限校验（如网关层鉴权），建议缓存 key 命名带版本号，如 perm:v2:user:1001，升级策略时直接切版本，旧 key 自然失效
要注意的几个关键点
Invalidation 不是万能的，容易踩坑的地方有：
- 消息丢失风险：异步广播可能失败，需搭配补偿机制（如定时扫描未更新的权限缓存项）
- 本地缓存不同步：若服务同时用了 Redis 缓存 + Caffeine 本地缓存，仅删 Redis 不够，必须双删或统一走分布式缓存
- 击穿问题：权限校验是高频入口，单个用户权限失效后并发请求可能打穿缓存直击数据库，建议加分布式锁控制重建，或预热常用权限集
- 粒度失衡：不要一改角色权限就 evictAll()，应按“用户-资源-操作”三元组构造 key，例如 perm:u1001:r/order:a/edit
真正管用的权限缓存失效，靠的不是指令多酷，而是通知必达、清理干净、兜底可靠。
