系统缓存实现

支持的缓存类型

框架目前支持如下两种类型的缓存：

• 基于内存的缓存，如：Map、Caffeine、Ehcache 等
• 独立缓存，如：Redis

对于单机使用，且同时在线用户量不大的情况下，推荐使用Caffeine缓存

对于需要分布式使用、有登录状态共享需求，且同时在线用户量比较大的情况，推荐使用 Redis 缓存。

认证相关缓存

  用户进行认证授权操作，成功之后，框架会将相关信息进行缓存，比如：认证凭据、session 等。   用户成功认证后，系统会产生 Session，记录用户详情信息(UserDetails)、认证时间、Session 时长、最后访问时间、是否过期等，并以此来对后续访问进行校验，判断是否已经认证。 Session 以 Key-Value 形式直接存储在缓存中;

• Key: SessionId
• Value: SessionValue (详情+ 用户详情UserDetails)

Session 在用户认证成功后生成并写入缓存，在用户主动注销或者超期后删除。

对于 Redis 缓存，框架额外的使用了如下缓存

• 认证用户列表 认证用户列表记录了在线用户 principal 与 SessionId 的对应关系。 主要用作实现相同用户重复登录的判定功能。采用 Hash 结构存储。其中：

• Key : principal 用户唯一标识

• Value: SessionId

• 在线用户列表 在线用户列表记录了所有在线的 SessionId，用来实现分页获取在线用户列表功能。采用 ZSet 结构存储。其中：

  • Value: SessionId
  • Score: 年月日 利用 Zset 的 Range 方法，可实现在线用户的分页获取。

这两个缓存中的数据，当 Session 过期删除后，通过 Redis 的过期和删除时间，同步进行清理。 同时，系统有 Session 清理定时任务，定时任务也会同时清理这两个缓存数据。

授权缓存

系统权限缓存

系统权限标识了系统内哪些资源需要什么权限，可分为：

• 按照权限标识符授权，一个资源对应一个权限标识符；
• 按角色授权，一个角色拥有多个资源，一个资源对应多个角色；
• Restful 授权，Method+url 唯一确定一个资源，method 与 url 匹配。 分析可知，资源，也就是 url,是权限拦截的入口规则，一个，且可能重复。 权限标识是用来判定授权的依据，一个或者多个。

所以，系统权限的缓存采取如下数据结构：

Map<String, Collection<String>> perms;

  系统权限缓存在用户首次访问受限资源的时候初始化加载，如果开启了系统权限缓存，则框架会首先从缓存中获取，如果没有获取到，则通过数据提供服务(如数据库)获取，获取到后载入缓存中。如果未开启系统权限缓存，则每次授权都会从数据提供服务获取。   如果系统权限资源发生变动，可直接通过缓存Dao 清除缓存数据，下次访问受限资源，会自动加载，从而实现动态权限管理。

• 首次访问系统受限资源的时候，初始化缓存。
• 对于内存缓存，系统权限缓存需要手动清除
• 对于 Redis 缓存，系统权限缓存超期后，会自动清理。

用户权限缓存

  用户登录系统后，用户基本信息会以 Session 形式进行缓存，直到用户访问受限资源之前，不会去加载用户权限。在用户首次访问受限资源的时候，如果开启了用户权限缓存，则会首先从缓存中获取，如果缓存中没有，再通过用户权限数据服务(数据库)获取，获取到后载入缓存。 用户缓存采取如下格式:

List<? extends GrantedAuthority> authorities;

  当用户授权发生变更后，可通过 SessionDao 直接清除对应用户的权限缓存。下次用户访问受限资源的时候，会自动重新从权限服务获取。从而实现动态用户授权。

• 用户权限在用户首次访问受限资源的时候初始化
• 用户主动注销(Session 删除)，用户权限一并删除
• 对于内存缓存，用户权限由定时任务在清理过期 Session 的同时同步清理
• 对于 redis 缓存，Session 过期被自动清理后，会通过 Redis 时间通知同步清理用户权限缓存。