缓存

在统一认证鉴权平台中,基于如下的考虑, 我们建立了一套缓存体系:

1. 当修改权限实体时,为避免权限校验的计算影响整体性能. 比如对于用户应该拥有哪些菜单,是需要拿每个菜单来和用户拥有的权限进行校验, 这个过程是个计算耗时的过程.
2. 为了让权限实体对象修改及时生效. 比如用户删除了某个权限, 能及时的看到某个对应的菜单不可见, 而不是需要再次登录才可以看到变化的发生.

模型

整个缓存模型见下:

后端之所以采用二级缓存管理, 是基于如下的考虑:

1. 需要有个集中式缓存,便于缓存的管理,维护和去除不必要的重复缓存分配
2. 考虑到将来client的不断增多,以及并发请求的不断增大, 担心对redis的访问会影响性能
3. 设计时, 认为redis应该是对client透明的, client应该不需要知道一级缓存的存在,以及建立和redis的连接

同步

当DB数据发生变更时, 应该需要同步修改一级和二级缓存中的数据. 目前的实现是通过实体对象UPDATE_TIME的变更来获知需要同步的对象并进行缓存同步的.

应用启动增量同步

应用启动增量同步发生在: 当有新的版本上线时, 新的sql语句会插入数据到DB中,这样在应用重新发布时需要增量同步变更的权限实体对象到缓存中

全量同步

缓存全量同步针对于缓存(一级或二级)和DB中数据不一致的情况, 是在异常情况下保证数据一致的一种手段. 其流程和上述增量同步类型. 需要注意两个地方:

• DB数据加载时不依据UPDATE_TIME,而是全量加载
• 一级和二级缓存同步前均需要先情况缓存

操作同步

操作同步发生在用户在统一认证鉴权平台中进行权限分配和修改时, 比如变更用户角色, 变更角色权限, 添加修改用户等. 我们通过自定义的@SyncCache注解以及请求拦截注解处理器来实现操作同步

WebSocket

WebSocket用于后端数据变更及时推送给前端, 便于前端及时页面刷新 (TBD...)