服务端 rbac 权限验证，是否有必要进行增加性能优化？

[tctc4869]

我不想用服务端里基于注解的权限验证框架，比如 Shiro 。所有的服务端 action 接口的权限配置都在后台管理界面进行配置

最简单的 rbac 权限验证，放在 sql 数据库就是 5 个表，用户表，用户角色关联表，角色表，角色菜单关联表，菜单表。而验证就是凭借用户 id 从用户角色表查到关联的 role，在从 role，查到关联的 menu 。一个 sql 语句经过 4 个表。

那么，服务端 rbac 权限验证，是否有必要进行增加性能优化？比如减少权限验证的时间。

我目前就想到一个方式，利用面向对象语言的引用特性，当项目启动时，载入角色与权限的关联数据永驻到服务端内存中，用户登录之后，创建一个集合，然后往集合内添加永驻在内存里的用户所含的角色权限关联引用，并且集合与用户绑定在 session 里。每次权限验证，都将请求 path 和用户的权限引用集合与服务端永驻内存的权限缓存进行对比。不在查询数据库。唯一看得出的缺陷是实时更新角色与 role 对应的维护有点麻烦。除了这个还有其他的方式么？

现在增加了 app 端，app 端用认证的不是 session，还是 token 。这个情况下，app 端的权限验证如果要进行性能优化，那是用什么方式呢，把角色关联数据加密，并到 token 令牌里安全么？还是性能优化没有必要的，直接根据 userid 去调 jdbc，用各 sql 语句一梭子查到菜单表进行对比就行了？

各位搭建编写 web 服务端的时候，权限验证有没有想过性能优化？有的话，一般都是怎样的？

[cruii]

把用户菜单存到 redis 不行么

[rockyou12]

首先权限设计不要针对菜单，而要针对资源。不然你多个端(web 、app 等)无法用一套统一的接口与统一的权限框架。

你要是用 jpa，直接都是对象关联，就相当于缓存一个大对象（用户->角色->权限）。我给公司写的框架其实就是这样缓存的。如果要进行更新，不是只更新权限或者角色这层，而是整个大对象全部删掉后重新整个更新。

不过说实话，用户量不大这个缓存作用也不是很大。

而且 app 端哪用优化什么，你登陆了就该拿用户所有权限，然后前端自己比对校验。要是访问到无权限的接口你后端就该直接报错。

[hsluoyz]

不要自己搞五张表了，Casbin 直接帮你 handle 三张表：用户角色关联表，角色表，角色菜单关联表，并且性能都是优化好的，支持各种语言、数据库。用户表、菜单表如果字段多，可以自己维护下。你不是专业做权限的，没必要入这个坑，直接用 Casbin 即可： https://casbin.org/

[tctc4869]

@rockyou12 前端自己对比校验？什么意思？校验权限，一般不都是在后端么

[rockyou12]

@tctc4869 前端的菜单、按钮显不显示还是只能前端自己做啊

[wshcdr]

权限一般都结合缓存的

[esolve]

@hsluoyz

有缓存支持吗？
感觉缓存和数据库一致性很难设计啊