本文目录导读：
- 使用位运算
- 引入多级缓存
- 权限数据脱库与预加载
- 空间换时间：构建权限矩阵
- 使用布隆过滤器（Bloom Filter）做拦截
- 减少嵌套循环：构建Hash Set或字典
- 表达式引擎预编译
- 读写分离与异步刷新
- 避免 “神级” 查询
- 分布式环境下的本地缓存加速
- 优化的优先级
针对权限判断的优化和提速，核心思路是将频繁的、耗时的计算逻辑前置，转化为纯粹的、可缓存的查表操作。
以下是针对不同场景（微服务、单体应用、数据库）的十大优化策略,按推荐程度排序：
使用位运算
这是最快的权限判断方式，适用于权限数量有限（如小于64个）且相对固定的场景（如Linux文件权限、功能开关）。
- 原理：将每个权限映射到一个二进制位（1<<0, 1<<1, 1<<2）,用户的权限集用一个整数表示。
- 判断：
if (userPermission & PermissionEnum.DELETE) == PermissionEnum.DELETE。 - 优化点：一次CPU指令即可完成，无需数据库查询,无需字符串比较。
引入多级缓存
这是最通用、效果最明显的优化手段，权限数据具有 “读多写少” 的特点。
- 一级缓存（本地内存/进程内）：
- 使用 Guava Cache、Caffeine 或 Go 的
sync.Map。 - 最佳实践：缓存在用户登录时加载,或按需懒加载。
- 失效策略：监听权限变更事件（如Redis Pub/Sub或消息队列）,实时失效本地缓存。
- 使用 Guava Cache、Caffeine 或 Go 的
- 二级缓存（分布式）：
- 使用 Redis，以
user:{userId}:permissions为 Key，存储权限集合（如 Set 或 String）。 - 优化点：使用 Redis Pipeline 或 Lua 脚本在一次网络往返中完成多条权限判断。
- 使用 Redis，以
权限数据脱库与预加载
不要在请求处理过程中频繁查询数据库,而是将权限数据加载到缓存或内存中。
- 登录时全量加载：用户登录成功后，一次性将该用户的所有角色、权限列表（去重后）写入缓存。
- 定时全量同步：对于通用权限（如功能菜单权限），可以每分钟/每5秒从DB同步到Redis或本地内存，请求时直接读内存,杜绝数据库查询。
空间换时间：构建权限矩阵
如果你有N个用户、M个权限点,并且需要频繁批量判断：
- 实现：用一个 Bitmap（例如Redis的 Bitmap）来表示。
Setbit permission:action_delete userId 1。
- 判断：
Getbit permission:action_delete userId。 - 优化点：极小的存储空间（1个用户占1bit），极高的查询速度（O(1)复杂度），且支持位运算（AND, OR）进行批量判断。
使用布隆过滤器（Bloom Filter）做拦截
适用于 “绝大多数用户没有某个高危权限” 的场景（如管理员后台权限）。
- 原理：如果一个用户确实有权限，布隆过滤器可能会漏判（但概率极低，可结合回源修正），如果用户没有权限，布隆过滤器一定能判断出来。
- 优化点：在权限判断的最上游设置一个布隆过滤器，快速拒绝99.9%的无权限请求，只有“可能”有权限的请求才进入后续精确判断流程。
减少嵌套循环：构建Hash Set或字典
如果你在代码中这样写：for role in roles: for perm in role.perms: if perm == target,需要优化。
- 优化方法：将用户的权限字符串列表转化为一个
HashSet<String>（如Go的map[string]struct{}，Java的HashSet）。 - 判断：
userPermissionSet.contains("order:delete")。 - 复杂度：从
O(n*m)降为O(1)。
表达式引擎预编译
如果使用了规则引擎（如Spring Security的表达式 hasRole('ADMIN') 或自定义SPEL）。
- 优化点：预编译表达式，不要每次请求都去解析字符串
hasPermission('order', 'delete')，将表达式编译成可执行对象（如Expression对象）并缓存起来,相同的权限点只需要编译一次。
读写分离与异步刷新
- 写操作：修改权限时（如管理员给用户加角色），只修改数据库，发送一条异步消息（MQ）。
- 读操作：直接读缓存,由MQ的消费者负责更新Redis或本地缓存。
- 优化点：写操作不阻塞读操作，后端可以接受秒级延迟（最终一致性）。
避免 “神级” 查询
如果必须在数据库层面判断（如报表系统、数据权限行级过滤）：
- 避免物理视图：避免使用
CREATE VIEW或复杂的相关子查询。 - 使用反范式：在用户表中冗余存储“角色类别”字段（如
is_admin），避免每次都JOIN角色表。 - 索引优化：
(user_id, permission_code)联合索引,且类型要保持一致。
分布式环境下的本地缓存加速
微服务架构中,权限判断请求可能转发的另一个服务。
- 优化：将权限判断下沉到网关层或公共SDK，在每个服务实例的内存中维护一份权限数据的副本（通过监听配置中心或消息队列更新）。
- 过程：请求 <-> 网关（本地缓存判断） <-> 服务实例，如果网关判断失败,请求甚至不会到达业务服务。
优化的优先级
- 第一优先级：位运算（适合开关型权限）+ Hash Set（适合权限码列表），这是零成本、收益最高的。
- 第二优先级：本地缓存（Caffeine/Guava） + 预加载,解决绝大多数性能瓶颈。
- 第三优先级：Redis Bitmap 或 Bloom Filter,解决超高并发下的批量判断或拦截。
面试/设计建议： 如果你在设计系统,可以先问自己：
- 读写比例：读多写少（99%场景）,无脑上缓存。
- 权限粒度：粗粒度（角色级别）用 Set；细粒度（功能级别且<64）用 Bitmask；数据行级别（如只能看自己部门）用 Presto/Elasticsearch 或 SQL拼接 + 缓存。
- 一致性要求：能否接受“修改权限后5秒内依然使用旧数据”？能则使用本地缓存 + 异步刷新；不能则必须穿透到 Redis 或 DB。
标签： 规则压缩